[tor-relays] Does Tor itself estimate how it can run as quota-utilizing as possible?

Sun Oct 1 19:40:19 UTC 2023

Hi,

thank you for your answer.

But for me, it seems like your explanation at least does not fully apply 
in my case: One of my relays reaches its quota every month before the 
end of the month, but it restarts automatically at the beginning of a 
month using the settings below, and it did so also today.

The behavior below, however, I observed with the other relay, which to 
my knowledge has *not* reached its quota - i only turned it on on the 
16th of September. Another look to my log files:

Sep 30 18:51:56.000 [notice] Heartbeat: Tor's uptime is 10 days 12:00 
hours, with 76581 circuits open. I've sent 10328.97 GB and received 
10137.37 GB. I've received 317665 connections on IPv4 and 39595 on IPv6. 
I've made 256147 connections with IPv4 and 74327 with IPv6.
Sep 30 18:51:56.000 [notice] While not bootstrapping, fetched this many 
bytes: 257413413 (server descriptor fetch); 7200 (server descriptor 
upload); 13167379 (consensus network-status fetch); 3664081 
(microdescriptor fetch)
Sep 30 18:51:56.000 [notice] Heartbeat: Accounting enabled. Sent: 
12375.74 GB, Received: 12185.16 GB, Used: 12375.77 GB / 20480.00 GB, 
Rule: max. The current accounting interval ends on 2023-10-01 00:00:00, 
in 5:08 hours.
[...]
Oct 01 00:00:00.000 [notice] Configured hibernation.  This interval 
began at 2023-10-01 00:00:00; the scheduled wake-up time is 2023-10-05 
06:06:25; we expect to exhaust our quota for this interval around 
2023-10-29 04:23:25; the next interval begins at 2023-11-01 00:00:00 
(all times local)
Oct 01 00:00:01.000 [notice] Commencing hibernation. We will wake up at 
2023-10-05 06:06:25 local time.
Oct 01 00:00:01.000 [notice] Going dormant. Blowing away remaining 
connections.
Oct 01 00:00:01.000 [notice] Delaying directory fetches: We are 
hibernating or shutting down.
Oct 01 00:00:14.000 [notice] Received reload signal (hup). Reloading 
config and resetting internal state.

I also don't understand the difference between the "I've sent/received" 
and the "Sent:/Received:" lines which differ in their values by approx. 
2TB each.

More confusingly, after restarting the relay an hour ago for other 
maintenance, I got the following warning messages (there were no warn 
messages in the logs before October 01, 16:58):

#:/var/log/tor# cat notices.log | grep warn
Oct 01 16:58:49.000 [warn] parse error: Malformed object: missing object 
end line
Oct 01 16:58:49.000 [warn] Unparseable microdescriptor found in download 
or generated string
Oct 01 18:09:09.000 [warn] Problem bootstrapping. Stuck at 10% 
(conn_done): Connected to a relay. (No route to host; NOROUTE; count 1; 
recommendation warn; host 453D69BB809FC59ED0CAD5D8399C27BC06DEB424 at 
109.250.99.118:9001)
Oct 01 18:09:09.000 [warn] Problem bootstrapping. Stuck at 14% 
(handshake): Handshaking with a relay. (No route to host; NOROUTE; count 
2; recommendation warn; host 13DB6CA2FCEFAEFD7551633BDDA215B32BC6E806 at 
91.248.123.129:8443)
Oct 01 18:09:09.000 [warn] 1 connections have failed:
Oct 01 18:09:09.000 [warn]  1 connections died in state connect()ing 
with SSL state (No SSL object)
Oct 01 18:09:11.000 [warn] Bad element "$C86F2844ED28274D15164E5897" 
while parsing a node family.
Oct 01 18:09:11.000 [warn] Bad element 
"$F8C37E0A09713ABB2BF07FF11EFDDA08" while parsing a node family.
Oct 01 18:09:11.000 [warn] parse error: Malformed object: missing object 
end line
Oct 01 18:09:11.000 [warn] Unparseable microdescriptor found in download 
or generated string
Oct 01 18:09:11.000 [warn] Bad element "$F62DF76750" while parsing a 
node family.
Oct 01 18:09:11.000 [warn] Bad element "$86A" while parsing a node family.

Kind regards
telekobold

On 01.10.23 20:16, trinity pointard wrote:
> Hi,
> 
> When using AccountingMax, tor tries to guess how long in will take for
> it to use its quotas, and will decide deliberately to hibernate for
> some time at the start of the period. It does that so not every relay
> is working at its max capacity on the first of the month, and only the
> unmetered ones are left at the end of the month.
> What it does isn't always perfect, it can end up wasting some
> bandwidth if the relay starts too late to use its quota, or cause too
> many relays to be out of quota before the end of the month, so that
> there is less capacity at the end than at the start, but it works well
> enough.
> Also your relay didn't learn from your behavior, this is something
> every relay with AccountingMax does if it managed to use its full
> quota before. It's very nice of you to think of that and try to make
> your relay the most useful possible over time, but sadly it wasn't
> worth the trouble.
> 
> Regards,
> trinity-1866a
> 
> On Sun, 1 Oct 2023 at 19:54, telekobold <torproject-ml at telekobold.de> wrote:
>>
>> Hello together,
>>
>> today I apparently discovered an interesting feature of Tor I wasn't
>> aware of:
>>
>> I'm running two relays at a large provider's data center having
>> 20TB/month free outgoing traffic for each relay. However, this quota is
>> often exhausted before the end of a month. In order to provide the Tor
>> project with some bandwidth all the time, I configured "AccountingMax 20
>> TB" and "AccountingStart month 1 00:00" and, for the last few months, I
>> used to switch off one of the relays on the first of a month and turn it
>> on again a few days after the beginning of the month, so that one of the
>> two relays is running all the time. I also connected the two relays
>> using the "MyFamily" flag.
>>
>> Until last month, each of the relays simply continued to run after the
>> end of the month. Today, however, I wondered why one of the relays shut
>> itself down apparently which did not change after a restart. A look into
>> /var/log/tor/notices.log provided the following entries:
>>
>> Oct 01 16:58:29.000 [notice] Configured hibernation.  This interval
>> began at 2023-10-01 00:00:00; the scheduled wake-up time is 2023-10-05
>> 06:06:25; we expect to exhaust our quota for this interval around
>> 2023-10-29 04:23:25; the next interval begins at 2023-11-01 00:00:00
>> (all times local)
>> [...]
>> Oct 01 16:58:49.000 [notice] Commencing hibernation. We will wake up at
>> 2023-10-05 06:06:25 local time.
>> Oct 01 16:58:49.000 [notice] Going dormant. Blowing away remaining
>> connections.
>>
>> So apparently Tor learned from my behavior and calculated itself when to
>> turn itself off and on again in order to use as much quota as possible
>> based on the bandwidth used and/or some other metrics so I don't have to
>> do this manually in future?
>>
>> Kind regards
>> telekobold
>> _______________________________________________
>> tor-relays mailing list
>> tor-relays at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays