Opened 11 years ago

Last modified 7 years ago

#902 closed defect (Fixed)

It appears there is a bug in the intersection of the bandwidthrate and accountingmax

Reported by: udo Owned by:
Priority: Low Milestone:
Component: Core Tor/Tor Version: 0.2.0.32
Severity: Keywords:
Cc: udo, nickm, arma, phobos, karsten Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

It appears there is a bug in the intersection of the bandwidthrate and
accountingmax when set to ridiculously high levels (999 TB).
But perhaps also at lower settings (9 GB).

Jan 05 19:10:54.773 [notice] Configured hibernation. This interval began at 2009-01-05 12:21:00; the scheduled

wake-up time was 2009-01-05 12:21:00; we expect to exhaust our quota for this interval around 2009-01-06 12:21:00;
the next interval begins at 2009-01-06 12:21:00 (all times local)

Jan 05 19:12:10.984 [notice] Received reload signal (hup). Reloading config.
Jan 05 19:12:10.988 [notice] Tor 0.2.0.32 (r17346) opening log file.

AccountingStart day 12:21
AccountingMax 5 GB

BandwidthRate 20000
BandwidthBurst 21000

Low traffic is the result
20000*3600*24 is less than 5 GB?

[Automatically added by flyspray2trac: Operating System: Fedora Core Linux]

Child Tickets

Attachments (1)

info.log.bz2 (22.1 KB) - added by udo 11 years ago.
log used by phobos@rootme

Download all attachments as: .zip

Change History (17)

Changed 11 years ago by udo

Attachment: info.log.bz2 added

log used by phobos@rootme

comment:1 Changed 11 years ago by phobos

This looks like my bug #816.

comment:2 Changed 11 years ago by udo

Indeed. Interesting.
I need the accounting for the mrtg graph.
I limit the bandwith already.

Any workarounds?

comment:3 Changed 11 years ago by arma

I don't understand what the bug is.

If you set bandwidthrate to 20KB, you won't attract much attention, so it
makes sense you won't have that much bandwidth used. If you further set
bandwidthburst to 20KB, you will limit yourself to a *max* of 1.7GB each
way, and quite likely much less than this.

From the three log lines you pasted above, Tor looks like it's working
correctly.

comment:4 Changed 11 years ago by arma

I guess the follow-up question: how low is low?

comment:5 Changed 11 years ago by phobos

See http://pindarots.xs4all.nl/mrtg/tor.html

and this thread, http://archives.seul.org/or/talk/Dec-2008/msg00310.html

It appears that setting AccountingMax, AccountingStart, BandwidthRate, and BandwidthBurst means Tor starts in hibernation
and never comes out.

comment:6 Changed 11 years ago by udo

Changed the bandwidth to:
BandwidthRate 120000
BandwidthBurst 121000

Did a SIGHUP and:

Jan 07 16:09:37.543 [notice] Configured hibernation. This interval began at 2009-01-07 12:21:00; the scheduled wake-up time was 2009-01-07 12:21:00; we expect to exhaust our quota for this interval around 2009-01-08 12:21:00; the next interval begins at 2009-01-08 12:21:00 (all times local)

So what can we conclude?
Who is looking into this bug?

comment:7 Changed 11 years ago by arma

The log line you keep printing indicates that everything is going well. The interval
for this day began a while ago, ends a while from now, and our estimates indicate
that we will never need to hibernate during the interval.

Nobody has described a bug to me. The bug as I understand it so far is that this
relay has accountingmax set, and it isn't pushing much bandwidth? Or maybe the bug
is that the log line is confusing you?

comment:8 Changed 11 years ago by udo

Both.
I already asked (elsewhere?) what the 'configuring' implicated.
What it says or that it is *activating* something.

Then the traffic stays low.
20 KB/s is enough for irc, text www, etc.

comment:9 Changed 11 years ago by udo

setting stuff to:
BandwidthRate 120000
BandwidthBurst 121000

Does change the mrtg graph after 16(!) hours.
Traffic peaks at a whopping 36 KB/s.

So why is 20 KB/s not used?

comment:10 Changed 11 years ago by udo

I gradually configured the Bandwidth back towards 20000:

BandwidthRate 21000
BandwidthBurst 22000

With this setting the traffic appears to keep going (needs a bit more time to be sure).

With the old settings traffic didn't even start:

BandwidthRate 20000
BandwidthBurst 21000

comment:11 Changed 11 years ago by udo

Why isn't my bandwidth used with 'BandwidthRate 20000'?

comment:12 Changed 11 years ago by arma

Ah ha. And here is the answer.

Every directory authority ranks relays by uptime, bandwidthrate, etc, and
assigns flags to them (Stable, Fast, etc) based on rankings. Currently:

Jan 11 08:29:24.386 [info] Cutoffs: For Stable, 116384 sec uptime, 357165 sec MTBF.
For Fast: 20480 bytes/sec. For Guard: WFU 95.864%, time-known 590407 sec, and
bandwidth 51200 or 52189 bytes/sec.

So that means to be labeled Stable, you must have a mean-time-between-failure
of 357165 seconds or more. And to be labeled Fast, you must have a speed of
at least 20480 bytes/sec.

Tor clients pretty much ignore (not entirely, but in most cases) relays that
don't have the Fast flag in their networkstatus entry. The 'Fast' cutoff is set
to exclude the lowest 1/8 of the network. That is, if the typical Tor relay is
slow, we are quite lenient about who gets the Fast flag. But as the typical Tor
relay gets bigger, we are more demanding.

Looking at the descriptors in moria1's cache (one of the directory authorities):
$ grep ^bandwidth cached-descriptors|cut -d' ' -f2-|sort -n|wc -l
8595

Of these, 81 of them have BandwidthRate set to lower than 20480.

I haven't added up which of the 81 are duplicates (many of the 8595 include
multiple descriptors from a given relay), but I think it's fair to see that
we're not missing very much overall by excluding these relays.

So. The short-term fix for this particular bug is for you to say

BandwidthRate 20 KB

which will expand to 20480 bytes, and will let you get the Fast flag.

The long-term fix is that we should consider either A) a lower bound
above which you always get the Fast flag. 20000 or not a crazy lower
bound. B) a log message telling the user "hey, your BandwidthRate is
set too low, you're not going to get used much". Detecting this situation
is tricky since the authorities don't publish their cutoffs, only their
decisions about each router. So, B') maybe we should publish cutoffs in
v3 votes, and publish the median of them (would that do what we want?
probably not in the general case) in the consensus.

comment:13 Changed 11 years ago by udo

Thanks for explaining.
Maybe set the bandwidth in the default torrc at 20KB?
(and add a suitable remark in torrc near that line)

comment:14 Changed 11 years ago by arma

Ok, in r19305 I made Tor refuse to start if your bandwidth is less than 20480
bytes per second.

I also made directory authorities automatically assign the "Fast" flag to a relay
that can actually handle 20480 bytes per second (that is, that has at least that
set for bandwidthrate, and also has actually seen that much use).

I'm going to mark this bug as fixed. Thanks!

comment:15 Changed 11 years ago by arma

flyspray2trac: bug closed.

comment:16 Changed 7 years ago by nickm

Component: Tor RelayTor
Note: See TracTickets for help on using tickets.