On 10/2/15, jensm1 jensm1@bbjh.de wrote:
You're saying that you're on a 1Gbit/s link, but you are only allowed to use 100Mbit/s. Is this averaged over some timescale?
More than 100MB which is 60 TB/month total for both directions. Is 100 TB/month, a common usage tier. Has a FUP (fair usage policy) attached, which means that the bandwidth should be evenly consumed over accounting interval rather than in in bursts.
If so, you could try and play around with the 'RelayBandwidthBurst' setting. Increasing the Burst might help reduce the queue delay when you're near saturation, assuming the traffic is not constant
Would make it worse, not better. A higher burst rate will allow the measurement to increase; the average limit must stay the same regardless. Best to set burst-max == average max. Tor relays allow some bursting regardless of the BandwidthRate setting anyway.
and you're not over-saturated most of the time.
This is the problem and the assumption is not correct. The link is saturated MOST of the time due to the overrating.
I don't know the measuring system, but I doubt that random packet dropping with iptables will have a noticeable effect on the measured bandwidth, as long as you don't drop enough packets to horribly degrade user experience.
NOT RANDOM. iptables will drop packets above the configured rate--exactly the same as a switch port dropping egress packets in excess of 100 MBit, a common lower-speed attachment type.
At present the bandwidth measurement system assesses bandwidth-constrained links that drop above-rate packets more correctly than unconstrained links where the relay daemon rate-limits via queuing and protocol flow-control.
To have the relay in question rated properly the best idea so far is to add an iptables rate limit to the mix. Will test keeping the BandwidthRate setting set slightly below the iptables limit in case that works better than an iptables limit alone.