After some examination I find the tor daemon hogging the bandwidth to the detriment of local users, including semi-real-time uses as VoIP connections. While there is no surprise here it is clearly not the intended use or desirable. The solution of lowering the bandwidth usage by specifying the proper parameters in the config file is available; it obviously is not ideal. It does a brute force reduction and as such doe not make all _unused_ bandwidth available to the tor network. A better solution would be the introduction of a QoS provision to tor itself. While this can not be done in tor by itself it is my feeling that a complimentary set of program/scripts should be part of a tor server installation that, in the end, provides for a lower priority processing of tor network request vs. other ones. This can be done with the appropriate marking of the tor packages and the appropriate iptables (in Linux) filter. I asked for a possible script for this and got a possible example from Martin Balvers. It turns out that the problem is a little more serious as it involves setting up the correct queues in the kernel (tc el al). All a bit above my skill and pay grade. I would suggest that the tor experiment is expected to fail or suffer in its future implementations if these are not provided as part of a standard installation. Any solutions? Regards, _manuel
Attachment:
smime.p7s
Description: S/MIME cryptographic signature