Observed bandwidth doubled?

Peter Lebbing peter at digitalbrains.com
Thu May 21 15:38:22 UTC 2009


Hello,

This is my first message to this list. I've tried searching for the 
answer to my question in the archives, but I couldn't find it.

I run a Tor non-exit relay, named DigitalBrains. Bandwidth is shaped and 
prioritized by Linux, with the HTB scheduler in the 2.6 kernel. The 
maximum token rate is 750,000 bits/s. To be completely exact, the 
iproute2 command that shapes my TOR traffic is:

# tc class add dev eth0 parent 1:1 classid 1:12 htb rate 80Kbit quantum 
1600 ceil 750Kbit

It will borrow tokens when there is no higher-priority traffic. This is 
the upstream traffic, i.e., away from the server. Downstream traffic is 
not shaped.

Now, if I don't enter any shaping configuration in my torrc, the 
observed bandwidth in the server descriptor happily doubles that rate:

-- from descriptor --
bandwidth 5242880 10485760 151973
-- end --

I've seen this more often than not. Checking the torstatus pages (f.e. 
[1],[2]), the actual rate in the graphs is limited to what the token 
bucket dictates (obviously, I'd almost say).

Can anybody explain why the observed rate is so much higher than the 
actual rate?

And more importantly: am I hurting the performance of the network when I 
let this situation continue? Should I enter a MaxAdvertisedBandwidth of, 
say:
MaxAdvertisedBandWidth 91 KBytes

In that figure, I assumed that KBytes means kibibytes; it almost 
corresponds to 750,000 bits/s.

For completeness' sake, the machine is a Debian Squeeze i686 running Tor 
0.2.0.34-1. It's behind an ADSL connection. If you need more info, I'll 
gladly supply it.

Thanks in advance,

Peter Lebbing.

PS: I accidentally pulled the power cord of the TOR machine today while 
working on it, so the current stats might be a bit different from what 
they usually are.

[1]<http://torstatus.blutmagie.de/router_detail.php?FP=b41e3847499234874688b2f354c6764b8589eaf8>
[2]<http://torstatus.kgprog.com/router_detail.php?FP=b41e3847499234874688b2f354c6764b8589eaf8>



More information about the tor-talk mailing list