Does Tor itself estimate how it can run as quota-utilizing as possible?
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
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@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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
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@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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
participants (2)
-
telekobold -
trinity pointard