6
Advertised bandwidth as reported by atlas and globe is really what is
observed as of far. Your relay has only been up for four days, and as your
relay proves its reliability and speed, advertised bandwidth will go up.
https://lists.torproject.org/pipermail/tor-relays/2014-June/004711.html
6
A similar method to what Jens Kubieziel♦ already mentioned is not completely restarting the server, but using Tor's ControlPort to change the bandwidth limits at certain times of the day.
This can be achieved by the following cronjobs:
0 6 * * * echo -en "authenticate\r\nsetconf relaybandwidthrate=100000 relaybandwidthburst=200000\r\nquit\r\n" | nc ...
6
There's basically always a shortage of bandwidth in the Tor network, so every amount of Bandwidth you can donate helps.
Additionally, your relay usually serves more than one circuit at a time, so any one connection that's going through your relay will receive only a share of your bandwidth anyway.
The amount of circuits goes up the more bandwidth you ...
6
The Tor Project now recommends at least 250 kilobytes/second each way to keep the level of service at least somewhat sane for users. Providing less bandwidth than that is actually a net drain on resources inside the network, because information about all relays has to be transmitted to all clients, which adds up to surprising amounts of bandwidth. Also, it's ...
5
Those logs mean that you have transmitted 159 GB and received 157 GB as a total during the 5 days, which means you have sent only 31 GB in the period between the 2 log messages.
4
I'll give it a try:
BandwidthBurst: The maximum bandwidth of short spikes in network traffic. While Tor tries to use BandwidthRate on average, it may use this value for short bursts. It was advised that this value should be four times the BandwidthRate.
BandwidthRate: The average bandwidth Tor should use.
RelayBandwidthBurst and RelayBandwidthRate: Both ...
4
Maybe it's easiest to explain this by example. The following comes from the current consensus:
[...]
r TorNinurtaName AA8YrCza5McQugiY3J4h5y4BF9g TsD6f/8KF1h7Npm/w2vgkzDumjY 2014-05-08 23:15:06 151.236.6.198 9001 9030
s Fast Guard HSDir Named Running Stable V2Dir Valid
v Tor 0.2.3.25
w Bandwidth=238
p reject 1-65535
[...]
bandwidth-weights Wbd=849 Wbe=0 ...
4
You should set your RelayBandwidthRate to the monthly cap divided by the number of seconds in a month divided by 2. (The 2 is because all traffic you relay goes in and out, so it counts twice.) To be conservative, I assume 1G for the provider is 10^9 and that 1K for Tor is 1024, that would be:
500GB - 91 KB
1000GB - 182 KB
2000GB - 364 KB
4000GB - 792 KB
...
4
Newer versions of Tor don't report data as accurately anymore, but globe hasn't been updated yet to deal with that. It's nothing to be concerned about.
The change was introduced in 0.2.5.11 with the following ChangeLog entry:
o Minor bugfixes (statistics):
- Increase period over which bandwidth observations are aggregated
from 15 minutes to 4 ...
4
The type of attack you are describing is a congestion attack. In theory, the simplest form of such an attack would be a general DoS on the Tor network.
Taking things one step further, a congestion attack could be used in conjunction with traffic correlation to monitor a given user of the Tor network. Such a strategy is discussed in A Practical Congestion ...
4
TL;DR:
Tor does not make much use of more than one core, two cores (or one hyperthreaded core) per process is best
a maximum of two Tor processes may register from a single IP, so a CPU with 4 cores is ideal
64-bit is best for cryptography
2 GiB of system memory is a bare minimum
Whilst I can't back it up with much technical details, this is from what I ...
3
In your torrc, there are 2 keys that determine your advertised relay bandwidth:
RelayBandwidthRate - Sets/limits how much bandwidth you allow for
relaying.
MaxAdvertisedBandwidth - May not be higher than
RelayBandwidthRate. If you don't have this entry, then your RelayBandwidthRate is advertised.
3
You can find the advertised bandwidth values in the bandwidth.csv file, which is linked below each metric graph.
As explained on the Tor Metrics Portal: Statistics page, each row of this file has the following fields:
date,isexit,isguard,advbw,bwread,bwwrite,dirread,dirwrite
The rows where isguard column is t(rue) will give you the bandwidth for the ...
3
Have you read the lifecycle of a new tor relay? In particular:
So that's phase one: your new relay gets basically no use for the first few days of its life because of the low 20KB cap, while it waits for a threshold of bwauths to measure it.
3
I'll give it a shot:
consistent fast speed being #1
rewards based on total bandwidth available/consumed per period
total consistent uptime
Identity verification (at least online or via email)
Community involvement (member of tor-relays, tor-talk, etc)
Number of successful responses to complaints
Hosting in a country that the Tor Network needs for geo-...
2
You can find average bandwidth over time for each relay on Atlas and Globe.
Metrics on the network as a whole are here: https://metrics.torproject.org/
2
The measured bandwidth is mostly determined by external measurements by the Bandwidth Authorities. The following should help explain it...
https://blog.torproject.org/blog/lifecycle-of-a-new-relay
2
No it does not. (..and neither does the OR traffic.)
The idea that 'traffic counts towards consensus weight' is not how it works. As I understand (from the linked document), the bandwidth is measured by building a circuit through the relay and transferring a file through it (and measuring how long that takes). So the consensus weight is not determined any ...
2
One relay is probably better, both for performance and anonymity (assuming the relays would run on the same machine).
Performance: There's no obvious performance gain by running two relays with half the bandwidth, since you should add the other relay to the MyFamily and thus only one relay would be used per circuit. Additionally, a second relay would add ...
2
One relay with 4TB, with the relay using up the 4TB quota as fast as possible.
Faster relays are more attractive to traffic, so the network is better off if you move that 4TB in a week then hibernate for 3 weeks than if you throttled down the bandwidth to keep the relay active all month.
Plus, a single relay is easier to administer.
2
This is a tough one. You don't have enough bandwidth to become a guard, so assuming you're not running an exit node, your node will only be used in the middle position. 500GB / month is about 100KB/s, which is (just) enough for your node to be considered "fast" and so it will be used in most people's circuits. However, if we look at this graph:
https://...
2
The choice is yours to make. There are advantages and disadvantages to both scenarios. Some of the advantages and disadvantages of each scenario are listed below.
Advantages of stable relay:
If the relay is fast enough at the time of entering the network according to rules and regulations applied to relays at that particular period of time (These rules and ...
2
Those specs don't include CPU speed, number of cores, network speed. 512MB of RAM may be a bit tight.
You can use the following directives in your torrc to influence the bandwidth usage of your relay:
RelayBandwidthRate - Limits the average incoming bandwidth usage for relayed traffic on this node to the specified number of bytes per second.
...
2
There are multiple practical reasons where five ORs of bandwidth X MB/s each could be superior to one OR of bandwidth 5X MB/s. There are some restrictions and exceptions to this point in general. This list is not meant to be the comperhensive list of all possible advantages and/or disadvantages, but give you enough clues to get the idea. Let us start and ...
2
https://blog.torproject.org/blog/lifecycle-of-a-new-relay
The tl;dr of the link above is that it can take 2 months to ramp up to full utilization.
Note also that the more bandwidth you are providing, the more "attractive" you are to traffic. A 20KB/sec relay may meet the minimum standard for a relay, but won't actually contribute to the network.
And, yes,...
2
Try this maillist: https://lists.torproject.org/pipermail/tor-talk/2012-August/025296.html
This is Edward Snowden.
Hi guys,
I've been running a kind-of 1gbps (voxility style 1gbps) exit server
on Debian for a couple months, and while it started out very fast,
it's gotten much slower over time. ....
He used 1gbps, it is 10x more than your ...
2
Tor doesn't differentiate between "good" and "bad" traffic. For the network is no difference if there are 100 new users doing their stuff or one person with 100 instances. So if one user decides to do this experiment there is less bandwidth left for other users.
It is slower to download a 50KiB file with 100 concurrent connections (ca. one second for each) ...
2
Not really. You can know it's observed bandwidth, and what it's throughput has been seen to be but not "available" bandwidth. That would require knowledge of, for example, the upperbounds of throughput in any given situation which would be infeasible to calculate and wouldn't be consistent as it would necessarily depend on factors outside of the ...
Only top voted, non community-wiki answers of a minimum length are eligible