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
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
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
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
Right now, Tor depends on the fact that all clients and all servers can contact all servers.
Once you add relays that are not reachable from the Internet because they are behind NAT for instance, this will no longer be true. This would making arguing about Tor's security properties way harder.
Somebody would have to come up with a design and its ...
answered Oct 5 '13 at 8:18
weasel - Peter Palfrader
4,7631 gold badge17 silver badges37 bronze badges
4
Right now Tor has no support for splitting connections over different circuits.
While, technically, support could be added if we had a design and the manpower to implement it, it's at this time not entirely clear if it's a good idea. The performance and anonymity implications have not been studied sufficiently.
answered Oct 1 '13 at 20:31
weasel - Peter Palfrader
4,7631 gold badge17 silver badges37 bronze badges
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
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
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
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
See also this report:
Jacob Appelbaum. Tor and NAT devices: increasing bridge & relay reachability or, enabling the use of NAT-PMP and UPnP by default (Technical Report 2012-08-001, The Tor Project, August 2012.)
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
I'm not sure if I understand your question correctly, but if you can't have any incoming connection then you can't run a relay. A non-exit relay has to be able to send/receive data within Tor network.
And that ExitPolicy reject *:* which is the correct setting for a non-exit relay means it will accept any connection in and out.
If you're running a non-exit ...
2
It could be that a firewall is giving you some troubles.
It could also be that you're using the wrong config file (I only mention this because it happened to me once).
Are you running an exit node or just a regular relay?
If you're running a regular relay then a slow increase in bandwidth could just be part of the relay's natural lifecycle.
If you're ...
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
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
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
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
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
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.
Only top voted, non community-wiki answers of a minimum length are eligible
