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

Re: advice on using accounting...

On Thu, Feb 10, 2011 at 06:19:27PM -0500, Joseph Lorenzo Hall wrote:
> I run a no-exit relay that can sustain about a hundred KB/s but I need
> to limit to about 4 GB/day to stay under bandwidth caps. I have
> accounting set up but what happens now is that it blows through that
> in 12 hours and then hibernates until the next day.

Sounds reasonable.

> However, because
> server descriptors aren't accepted into the consensus if they're not
> much different from the last one, at some point during hibernation my
> node appears to go down (presumably until it starts relaying again and
> publishes a significantly different descriptor).

Your node *is* down. That's what hibernation does. As soon as it goes into
'soft' hibernation, it closes its external ports. Next time the directory
authorities test it for reachability, they will find that it is gone.

That said, the authorities should be accepting your new descriptor,
because it _is_ much different from the previous one. The "hibernating
1" line makes it different. It also means that they won't wait until
they've tried several reachability tests to mark you as not running,
since you published an explicit "I'm hibernating" descriptor.

> Is that the trade-off nodes that do bandwidth accounting have to make?
> That is, appear down due to the consensus refresh parameter of 12
> hours?


> Are nodes that hibernate daily by definition not stable? (and
> in torstatus and torweather appear down for a large chunk of the day?)

Tor weather's behavior here may need some improvement. I haven't had time
to look at how they determine whether you're hibernating vs down. It's
quite possible they made some wrong assumptions when building that part.

As for whether they're "not stable" by definition, the definition is that
you have to be in the top half of nodes by mean-time-between-failure. So
if many nodes have this behavior, some of them will end up with the stable
flag. If few nodes do, probably none of them will get the stable flag.


To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/