On Wed, 18 Sep 2013 16:43:25 -0400, Roger Dingledine arma@mit.edu wrote:
On Wed, Sep 18, 2013 at 06:50:46AM -0700, Gordon Morehouse wrote:
The replay has settled into a fairly steady state (after losing its flags except Named) of sending 5-10KB more per sec than it gets. I have a feeling this is literally due to the TAP replies being bigger than the TAP requests.
TAP replies and requests are both packaged in normal 512-byte Tor cells.
Typically extra write bytes happen because of people fetching directory information from your relay. That trend has increased over the past month, with five million more Tor clients online (and updating their directory info) than before.
You can compare by turning your dirport to 0. Unless you did that already?
Nope, but that sounds about right - I definitely am running the directory service.
Sep 18 05:30:43.000 [warn] Your system clock just jumped 101 seconds forward; assuming established circuits no longer work.
Shouldn't Tor be shedding memory if it closes all its circuits, not acquiring more?
Ah -- that log message about established circuits is talking about client circuits. It doesn't close circuits that it's relaying for other people.
(In fact, it doesn't even close all the circuits which it had created. It leaves open the ones that have streams on them, in hope that the streams will still work.)
Thanks, Roger. I'm still not sure what finally caused the OOM-killer crash this morning after almost a couple weeks (?) of uptime. I was also seeing additional clock jump messages but didn't have time to diagnose it. The Pi does not have a battery-backed RTC so it requires a clock set at each start, accomplished by 'ntpdate' and kept in time with, in my case, 'openntpd'. But, 'openntpd' wasn't complaining at the time of the clock jumps that were reported by Tor, and AFAIK 'ntpdate' is not scheduled to run periodically, so I don't know what's causing it yet.
I'll continue to work on the Pi relay tuning, watch it closely, and report back. It is working better than ever with the latest 0.2.4.x but starting to hit CPU limits around 2Mbps (with little to no intensive optimization, I might add).
Best, -Gordon M.