Re: [tor-relays] Tools for managing multiple relays

[starlight.2015q3@xxxxxxxxxxx]

>None of the above :)
>
>I run these three relays[1][2][3].
>
>ccrelaycc [1] has acquired the guard flag in the
>last few days (don't know when, last time I
>checked it did not have it).

This relay is rated near the boundary of
minimum Guard rating and goes in and out
of the state.

>A thing that is bothering me is that ccrelaycc and
>inara ([1] and [2] respectively) are both on
>DigitalOcean, they are in two different regions
>(AMS and SIN) *but*, notwithstanding that they
>have an identical configuration, ccrelaycc has
>been experiencing 2 TB traffic per month in the
>last 3 or 4 months while inara has barely reached
>100 GB per month over same period (I use vnstat
>and arm for these stats), that is a 20x
>difference. I would like to understand this
>difference.

With a VPS a tremendous number of variables
are at work.  How heavily loaded is the
physical server with other VPS clients?
What kind of NICs are present?  What type
of server, etc?  Is not surprising at all
that the QOS varies wildly.

>It should be noted that both are the smallest VPS
>available on DigitalOCean and that comes with 1 TB
>of traffic per month but it seems that
>DigitalOcean is liberal about using more bandwidth
>(I have read a similar comment on this list about
>DO).
>
>jaine is much more recent and it is on Aruba.it in
>Italy. I expect that they are much less liberal
>about using more bandwidth than what is allotted
>so I set lower limits for the RelayBandwidhtRate
>parameter.
>
>For ccrelaycc and inara I have set:
>---
>RelayBandwidthRate 1600 KB
>RelayBandwidthBurst 3200 KB
>---
>and for jaine:
>---
>RelayBandwidthRate 800 KB
>RelayBandwidthBurst 1600 KB

If you have the ability to use 'tc' instead
of BandwidthRate (per posts earlier this month)
you should do that.  RelayBandwidth* are not
intended for limiting bandwidth in dedicated
relays.  Replace them with BandwidthRate
and BandwidthBurst if you can't use 'tc'.

>---
>What I see in the end are three quite different
>behaviors. Given that jaine is at the beginning of
>its lifecycle I would give it some more time
>before drawing any conclusions, but I would really
>like to understand why ccrelaycc and inara are
>behaving so differently. I would appreciate any
>input on this.

Per above, huge number of variables easily
explain it.  On top of the variability of the
VPS, the networks could have dramatically
different quality, reachability, loading
and congestion.  You can look at the individual
BWauth ratings for a more complete picture.  Found
https://collector.torproject.org/recent/relay-descriptors/votes/
where
# gabelmoo  ED03BB6...  Erlangen, Bavaria-DE
# maatuska  49015F7...  Belgium
# Faravahar EFCBE72...  ?
# longclaw  23D15D9...  Seattle, WA-US
# moria1    D586D18...  Cambridge, MA-US

here's Blutmagie (actual bandwidth)
_gfs_ ccrelaycc NL 942  98 4.27 L 95.85.8.226     443 80 95.85.8.226
__fs_ jaine     IT 216  13 4.27 L 5.249.145.164   443 80 ... .aruba.it
__fs_ inara     SG  38  98 4.27 L 128.199.148.243 443 80 128.199.148.243
and rueckgr.at (max self-measure / advertised)
_gfsh ccrelaycc NL 1987
__fsh jaine     IT  999
__fsh inara     GB  823

Suggest installing and running 0.2.6.10 in
instead of 0.2.4.27.

The Aruba dedicated Atom server discussed earlier
could make a nice relay, or perhaps the next-up
one for 20 euros.  Perhaps try running the
existing Aruba node as an exit for a month
first to see how they respond.  With
the "reduced" exit policy the worst-case is
a pile of automated complaints about WordPress
brute-force login attacks.  Very minor but
how they respond will be telling.  The exit
policy can be turned off if they freak.

LeaseWeb has 49 euro 100TB servers available
in the Netherlands--killer exit boxes that will
rate high and pull 15000 per Blutmagie.  OVH has
good offerings as well, including the Kimsufi
subsidiary.  Despite 'tor-relays' claims to the
contrary, Kimsufi apparently will tolerate
(at least one) exit nodes:

e_fs_ Kiss208 FR  703 10 6.10 L 5.135.152.208 443 444 ks3296627.kimsufi.com
e_fsh Kiss208 FR 1503

The above has been an exit for 14 months.
Here's the fastest Kimsufi though this is
probably a Pentium or Xeon:

_gfs_ Unnamed FR  9865 61 6.10 L 91.121.82.25 443 80 ks26969.kimsufi.com
_gfsh Unnamed FR 10947

=====

But an Aruba exit is perhaps a more diverse
addition.

_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays