[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-relays] excessive bandwidth assigned bandwidth-limited exit relay



On Thu, Oct 1, 2015 at 10:17 PM, Yawning Angel <yawning@xxxxxxxxxxxxxxx> wrote:
>
> Using IP tables to drop packets also is going to add queuing delays
> since cwnd will get decreased in response to the loss (CUBIC uses beta
> of 0.2 IIRC).

Unfortunately true.  Empirical arrival to a better result is the idea.

When saturated and rate-limiting, the relay sometimes
is so bad  connections time-out.  Consistent though
less-than-amazing performance is better than erratic
sometimes-failing performance IMO.  Tried a few
exit relays that appear to be limited by 100MB physical links
and have consensus weights around 60k (i.e. TCP congestion
control is at work though the load is not excessive) and
they function much better.

> It may be less queuing delay (note: write() completes the moment data
> is in the outgoing buffer kernel side, so it may not be as apparent,
> and is somewhat harder to measure), and it's your relay so I don't care
> what you do, so do whatever you think works.
>
> That said, placing an emphasis on unit-less quantities generated by a
> measurement system that is currently held together by duct tape,
> string, and chewing gum seems rather pointless and counter
>productive.

Really?

The consensus weight has a precise and predictable
effect on the amount of traffic directed to the relay.  So gaming
the measuring system for a weight that yields the best-possible
user experience is not "pointless."  I am paying for this.

Does seem the system generating the measurements has
problem and if someone can look at this issue that would
seem "productive."

Still interested in hearing "a better idea."
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays