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.