[tor-relays] Fast Exit Node Operators - ISP in US

Tue Nov 25 00:12:24 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 11/24/2014 7:32 PM, Mirimir wrote:
> On 11/24/2014 03:06 AM, s7r wrote:
>> If the only limit is consumed monthly traffic, and not the
>> bandwidth your relays consumes daily (e.g. you use your VPS only
>> for Tor) it is not recommended  to use RelayBandwidthRate. Better
>> use AccountingMax, and your relay will work at full speed until
>> it hits the accounting limit, then go into hibernation. It will
>> wake up at a random time in the next accounting period.
>> 
>> As the Tor manual says, it's better to have a fast relay
>> available some of the time instead of having a slow relay
>> available all the time.
>> 
>> Just use AccountingMax and do not forget there are other factors
>> as well which count in the speed of a relay, such as CPU, RAM,
>> network - a VPS (share resources machine) is unlikely to achieve
>> maximum resources usage. Give it a try with AccountingMax (so you
>> are sure it won't bypass the limit set by your provider and you
>> don't have to pay extra) and see what what speed it reaches.
> 
> OK, then. But in that case, and given that the provider states the 
> throughput limit as "1000 GB per month", I would want to use
> monthly accounting, in order to be in synch with them:
> 
> AccountingStart month 1 00:00 AccountingMax 900 GBytes
> 
> Yes? That way, with no RelayBandwidthRate limit, relay utilization
> will presumably increase for two or three months, until
> AccountingMax is exceeded, and the relay hibernates. Subsequently,
> it will tend toward an equilibrium, with some mix of bandwidth and
> activity/month that depends on the configuration of the directory
> authorities.
> 
Sounds about right. If you have 1000GB from your provider, why set it
to 900? You can put 995 GBytes without any problems, since 5GB per
month is more than enough for management / administration and time to
time regular operating system updates.

> If I used daily accounting, the relay might end up hibernating
> every day. That would be worse, right? Also, I'm imagining that
> this might lead to lower average throughput, because the relay
> would show up as unstable? Is that correct?
> 
> More generally, should AccountingStart (day vs week vs month) match
> the accounting period used by the service provider?
> 
It does not matter really, as for traffic consumption will have the
same effect. If you have 1000GB per month you can either set
accounting period of 995GBytes per month or accounting period of
248GBytes per week - it will still prevent your relay to consume more
than 1000GBytes per month... As a personal thought, I think it's much
better to have a monthly accounting period as your provider accounts
your traffic, this way you relay will go into hibernation one time per
month rather than 4 times (after the end of each accounting period Tor
goes into hibernation and waits for a random time until it 'wakes up'
again).

> Thanks.
> 
>> On 11/24/2014 5:24 AM, Mirimir wrote:
>>> On 11/23/2014 11:05 AM, s7r wrote:
>>>> That is, because in almost all cases, providers allow
>>>> unmetered incoming traffic to your server but keep count and
>>>> accounting on outgoing traffic from your server, which is why
>>>> the torrc setting acts the way it does.
>> 
>>> That would be great! I'll confirm with the provider.
>> 
>>> I'm also wondering what to set for RelayBandwidthRate for an
>>> exit. I see some old threads on this list, and a question at
>>> Tor.SE, but find nothing that's clear and persuasive.
>> 
>>> Assuming that the 1000 GB/mo limit applies to just outgoing 
>>> traffic, throughput would need to average ca. 0.4 MB/sec.
>>> However, median advertised exit bandwidth from Tor Metrics is
>>> ca. 1 MB/sec, so it seems unlikely that an exit advertising 0.4
>>> MB/sec would be used very heavily. And so actual usage would be
>>> far less than 0.4 MB/sec.
>> 
>>> Conversely, setting RelayBandwidthRate to 3 MB/sec would
>>> ultimately lead to heavy use. But with full utilization at 250
>>> GB per day, the relay would hibernate after just four days.
>>> There must be some intermediate value that would bring average
>>> usage to 0.4 MB/sec.
>> 
>>> What is the optimal RelayBandwidthRate for a 1000 GB/mo VPS?
>>> I'm guessing that it's about 1 MB/sec.
>> 
>>>> On 11/23/2014 7:58 PM, Seth wrote:
>>>>> On Sat, 22 Nov 2014 22:42:15 -0800, Mirimir 
>>>>> <mirimir at riseup.net> wrote:
>>>> 
>>>>>> How much throughput do you get with your VPS, 1000 GB/mo
>>>>>> or 2000 GB/mo?
>>>> 
>>>>> The 1000 GB/mo applies to whichever value is greater, input
>>>>> or output. So far the Tor node is pushing less than 1.5GB
>>>>> per day. Takes a while for traffic to ramp up apparently.
>>>> 
>>>>>> As I read comments in torrc, AccountingMax "applies 
>>>>>> separately to sent and received bytes, not to their sum",
>>>>>> and so "setting '4 GB' may allow up to 8 GB total before 
>>>>>> hibernating".
>>>> 
>>>>> Yes, others have raised this issue as well and I will look 
>>>>> into it. _______________________________________________ 
>>>>> 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
>>>>
>>>
>>>> 
_______________________________________________ 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
>> 
> _______________________________________________ tor-relays mailing
> list tor-relays at lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUc8loAAoJEIN/pSyBJlsRJFoIAJUID8SY89IOpqv4Q7htrPzo
GCyOIM9ylNfJs9zCW+2Tpk/gHqesL5YzmQI6l5tW8GGsnAJRVEx0E5UIuwYpg9zv
j0W44kOH+rI9oIkUTZbd5cY+bUQAeHf5CIXDVbSBjkfA04Wfk9ref6gPzzwCWrlx
7sqTuapOEPPjzDee06XNCaJ51LHjJvKORgbwvGD0EWE4jXJphXk6+h4fybofmJh6
Gt12kf3t8Q4i+11UGuHsWJI6BRG6DFD6eO84wnl8n9ydaWhXpRjNrpb0T5k51d60
X+XQya3icf8gJKI/elPTyCcSwFfWZd4traj9aujRzSXzuzg+nMC32ZcxLqloJJQ=
=tqh5
-----END PGP SIGNATURE-----