-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
You only mentioned the 100TB plan limit, this is why I suggested AccountingMax. I couldn't have guessed you are talking about some other policy limits.
The consensus weight is your bandwidth measured by the bandwidth authorities. This is used by clients to calculate your relay's probability from being chosen in a circuit. If it's big, yes of course it will attract more clients. If you rate-limit it in torrc, the bandwidth authorities won't be able to measure more than what you are offering. Maybe use this:
MaxAdvertisedBandwidth N bytes|KBytes|MBytes|GBytes|KBits|MBits|GBits
If set, we will not advertise more than this amount of bandwidth for our BandwidthRate. Server operators who want to reduce the number of clients who ask to build circuits through them (since this is proportional to advertised bandwidth rate) can thus reduce the CPU demands on their server without impacting network performance.
On 10/1/2015 4:22 PM, Dhalgren Tor wrote:
On Thu, Oct 1, 2015 at 1:10 PM, Tim Wilson-Brown - teor teor2345@gmail.com wrote:
Can you help me understand what you think the bug is?
Relay is assigned a consensus weight that is too high w/r/t rate limit. Excess weight appears to be due to high quality of TCP/IP connectivity and low latency of relay. Result is overloaded relay and poor end-use latency.
Is Tor using more bandwidth that the BandwidthRate?
No, but relay is loaded to flat-line maximum and clearly is attracting too many circuits.
If so, this is a bug, and should be reported on the Tor Trac.
Not interested in doing that. Looking for a way to get it work.
If the relay stays overloaded I'll try a packet-dropping IPTABLES rule to "dirty-up" the connection.