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

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



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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays