On Thu, Oct 1, 2015 at 11:41 PM, Tim Wilson-Brown - teor teor2345@gmail.com wrote:
We could modify the *Bandwidth* options to take TCP overhead into account.
Not practical. TCP/IP overhead varies greatly. I have a guard that averages 5% while the exit does 10% when saturated and more when running in good balance. Depends on the TCP packet payload sizes and header options, which can differ from connection to connection.
Alternately, we could modify the documentation to explicitly state that TCP overhead and name resolution on exits (and perhaps other overheads?) *isn’t* taken into account by those options. This would inform relay operators to take the TCP and DNS overheads for their particular setup into account when configuring the *Bandwidth* options, if the overhead is significant for them.
A good idea. Easy to overlook even for the experienced and a simple reminder goes a long way.
You suggested TCP overhead was 5%-13%, I can include that in the manual. Do we know what fraction of exit traffic is DNS requests?
Seems relatively miniscule though I haven't dug into it. Some resolver queries go over TCP while most are UDP. 'unbound' works so well I haven't spent much time with it. Have 'unbound' writing statistics to syslogd and if I see anything useful will append it to this thread. Some relay operators configure ISP DNS where the cache resides on another machine.
Are there any other overheads/additional traffic we should note while updating the manual?
Think that covers it. Operator 'ssh' is nothing, relay traffic the 1000 lb Gorilla.
(Or would would you suggest that we update the code? I’m not sure how much this actually helps, as, once deployed to all relays, the consensus weights for all relays that set a *Bandwidth* options would come out slightly lower, and other relays without *Bandwidth* options set would take up the load.)
Per above, impossible to figure. Better to remind folks when they refer to the documentation.
What I do is have a script that writes 'ifconfig ethX' to a file once a day, in sync with the service-provider accounting time- zone. Have an 'awk' script that calculates bytes for each day --is very precise including all traffic and overheads. The script subtracts-out MAC headers (using packet counts) since the 14 bytes does not hit the WAN and is not billable.
Perhaps passing mention of 'ifconfig' statistics in the manual is worthwhile. 'ip -s link show eth0X' truncates byte counters (on some distros anyway) and is useless.