What should I do to get STABLE flag for my middle relays?

michal_roesler · December 17, 2023, 1:39am

I’m running one middle relay for 300 days now “0C4D7C61271C32DFBD0DF4A0296E4CE1BA2E952A” and another middle relay for 9 days “6AE0E65677643B9DB60390AAC0AF544114825FD4”.

I’ve got problem with obtaining a STABLE flag for my relays. I know I’ve been experimenting lately with the /etc/tor/torrc config file and I’ve been resetting my relays quite often, but I needed to configure them correctly, not to exceed my bandwidth limitations I have with my virtual server provider.

RelayBandwidthRate 1536 KB
RelayBandwidthBurst 3072 KB
AccountingMax 60 GB
AccountingStart day 00:00

Do I have a chance to earn a STABLE flag with such settings on my middle relay??
I cannot make it any faster, without risking running out of my 60 GB maximum daily traffic limit (after 16-20 hours) and hibernating my relay, which as I understand it correctly, results in labeling my relay as not STABLE.

I only have 3TB monthly bandwidth limit at my virtual server provider and currently cannot afford to upgrade the VPS size.

I’ve read this thread Loss of Stable Flag but I guess I wasn’t able to understand the answers provided there, or maybe there was no specific tips for reaching the STABLE flag.

Is there any other way than NYX or Relay Search Information that I can use to monitor my relay and learn what to do, to increase my chances on earning the STABLE flag?

Here is my sudo journalctl -u tor output.

-- Boot 1641de55df954ba1b0f8f43e065031e3 --
gru 12 14:18:11 debian systemd[1]: Starting tor.service - Anonymizing overlay network for TCP (multi-instance-master)...
gru 12 14:18:11 debian systemd[1]: Finished tor.service - Anonymizing overlay network for TCP (multi-instance-master).
-- Boot af3f676d030c48e5afb2f107b3f27941 --
gru 13 12:37:14 debian systemd[1]: Starting tor.service - Anonymizing overlay network for TCP (multi-instance-master)...
gru 13 12:37:14 debian systemd[1]: Finished tor.service - Anonymizing overlay network for TCP (multi-instance-master).
gru 14 02:48:17 debian systemd[1]: tor.service: Deactivated successfully.
gru 14 02:48:17 debian systemd[1]: Stopped tor.service - Anonymizing overlay network for TCP (multi-instance-master).
gru 14 02:48:17 debian systemd[1]: Stopping tor.service - Anonymizing overlay network for TCP (multi-instance-master)...
gru 14 02:48:17 debian systemd[1]: Starting tor.service - Anonymizing overlay network for TCP (multi-instance-master)...
gru 14 02:48:17 debian systemd[1]: Finished tor.service - Anonymizing overlay network for TCP (multi-instance-master).
-- Boot ba7e9d141bb04900a096dee16a55b8a1 --
gru 14 03:11:08 debian systemd[1]: Starting tor.service - Anonymizing overlay network for TCP (multi-instance-master)...
gru 14 03:11:08 debian systemd[1]: Finished tor.service - Anonymizing overlay network for TCP (multi-instance-master).
-- Boot 3227d0caaf74467197872b286b402d99 --
gru 14 16:26:43 debian systemd[1]: Starting tor.service - Anonymizing overlay network for TCP (multi-instance-master)...
gru 14 16:26:43 debian systemd[1]: Finished tor.service - Anonymizing overlay network for TCP (multi-instance-master).
gru 14 18:05:19 debian systemd[1]: tor.service: Deactivated successfully.
gru 14 18:05:19 debian systemd[1]: Stopped tor.service - Anonymizing overlay network for TCP (multi-instance-master).
gru 14 18:05:19 debian systemd[1]: Stopping tor.service - Anonymizing overlay network for TCP (multi-instance-master)...
gru 14 18:05:19 debian systemd[1]: Starting tor.service - Anonymizing overlay network for TCP (multi-instance-master)...
gru 14 18:05:19 debian systemd[1]: Finished tor.service - Anonymizing overlay network for TCP (multi-instance-master).
-- Boot 93f823f4b02d469b9ee7d3937b16277c --
gru 15 11:11:47 debian systemd[1]: Starting tor.service - Anonymizing overlay network for TCP (multi-instance-master)...
gru 15 11:11:47 debian systemd[1]: Finished tor.service - Anonymizing overlay network for TCP (multi-instance-master).

git-sunshinecowboy · December 24, 2023, 5:52pm

First, in order for a relay to be stable downtime needs to be limited. So, if you are stuck with that vps provider remove the accounting max and calculate the BandwidthRate max for 24/7 maximum bandwidth for the day and use that setting,. In your case this would be 728 KB/s. You would be better off finding a VPS provider that has unlimited bandwidth or much higher caps. I’d recommend BlueVPS, IONOS, Rack Nerd, or BuyVM.

neel · December 24, 2023, 5:52pm

A good idea is to get a VPS without a data transfer limit.

A few companies offer this including BuyVM, RDP.sh, DataIdeas, Trabia, ITLDC, OVH, Scaleway, 1&1 IONOS and GoDaddy. I personally do business with DataIdeas and GoDaddy for my exit relays. There are others as well.

A good site to ask for suggestions is WebHostingTalk and LowEndTalk.

michal_roesler · December 27, 2023, 8:21pm

I’ll try to do that, if I find some high transfer quota VPS on some black friday type of sale.

If I have a notice like this in my Nyx ? ? ?
Configured hibernation. This interval began at 2023-12-27 00:00:00; the scheduled wake-up time was 2023-12-27 00:00:00; we expect to exhaust our quota for this interval around 2023-12-28 00:00:00; the next interval begins at 2023-12-28 00:00:00 (all times local)

The 60 GB quota was not reached. I know because I’ve been checking this for few days in a row, by manually checking this Accounting Limit usage at 23:55.

Does this mean that the tor relay was nevertheless restarted and my downtime is increasing or, as I imagine that, the relay is only restarted if the AccountingMax quota is reached (let’s say) at 22:00, so the relay is hibernating for 2h until 00:00, and then it’s turned back on, which is an obvious example of hibernation/relay restart, that generates additional downtime.

Is there something in these notices that I should be worried about ? ? ?