[tor-relays] Bandwidth Authority PID Feedback Experiment #2 Starting

[Mike Perry]

Thus spake Tim Wilde (twilde at cymru.com):

> We're not seeing source port exhaustion, but we are seeing two warns,
> one of which I haven't been able to nail down:
> 
> 2011 Dec 13 20:22:07.000|[notice] We stalled too much while trying to
> write 8542 bytes to address "[scrubbed]".  If this happens a lot,
> either something is wrong with your network connection, or something
> is wrong with theirs. (fd 409, type Directory, state 2, marked at
> main.c:990).

Hrm.. Haven't seen this one before...

> 2011 Dec 13 22:26:45.000|[warn] Your computer is too slow to handle
> this many circuit creation requests! Please consider using the
> MaxAdvertisedBandwidth config option or choosing a more restricted
> exit policy. [18 similar message(s) suppressed in last 60 seconds]

Ah, we should be handling this issue with the fix for #1984:
https://trac.torproject.org/projects/tor/ticket/1984

> The second warn I figure I should be tuning myself with
> MaxAdvertisedBandwidth, and it's happening on BigBoy, the relay on
> this box that's doing the majority of its bandwidth.  So I'm not sure
> if it's anything that your feedback loop should be involved in or not.

It's a shame this log message makes such a crazy recommendation wrt
MaxAdvertisedBandwidth. But I guess some tweak is better than no
tweak. Hopefully we can make this go away without you needing to lower
it, though. Can you ping me on IRC if you keep getting these warns
after leaving MaxAdvertisedBandwidth alone?

> One other data point, I have seen (also sporadically) some indications
> in my system logs of hardware hangs on the ethernet interface all of
> this is running through, so I'm slightly suspicious that it's to blame
> for the *Dragon problems.  It doesn't really explain why BigBoy isn't
> affected though, and I haven't been able to definitively prove
> anything yet, so I'm just not sure.

This sounds incredibly familiar. What ethernet card + driver version
do you have? Some combos of are pretty abysmal about IRQ load
balancing and interrupt optimizations, or at least they were on old
kernels (which may still apply if you are CentOS).
 

-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20111213/676aa816/attachment.pgp>