Re: [tor-relays] Low observed bandwith
Hi Mario, I'm having same trouble with raspberry pi 3b... I use Wi-Fi connection with high throughput. My local connection can copy files up to 15MB/s to this RPi. It is a USB adapter (mediatek MT7601). I'm asking myself that speed on tor network shouldn't be more than 2 MB/s. I've limited the maximum in 3,2 MB/s and burst to 4,3 MB/s, my connection here in Brazil is just of 240 Mb/s // 24 Mb/s... At least 2,2 MB/s should be reached in the measurements i guess. In the past i shouldn't pass from 600 KB/s thus because my CPU consumption with TOR was near to 100%. But i've set more parallel threads in torrc and recompilled my openssl to support it the linux crypto engine, that can handle faster crypto operations. With this i've enabled hardware acceleration on torrc and reached a little bit more than 1MB/s in the measurements. Luiz Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ Em Sábado, 11 de Abril de 2020 às 09:55, Mario Costa escreveu: > Hi list, > > I’m running a guard relay from my home connection on a Raspberry Pi 4. My > internet connection is 1000/100 Mbps, and I thought I’d allocate half of the > upload bandwidth for the relay. Then I set RelayBandwidthRate to 10 MB/s, > because I thought that Tor would upload 5 MB/s and download 5 MB/s. > > However, the maximum observed bandwidth was always about 6 MB/s. I’d like to > know what could cause this low observed bandwidth. I don’t think it’s the > Raspberry Pi, because CPU usage is always low and it has a Gigabit connection > to the router. > > The router itself easily reaches Gigabit speeds, so 10 MB/s should be a > breeze. Could it be the number of connections? nyx indicates that the > connections are always about 4000. If this is the case, how can I know if the > connections bottleneck is the router or the Raspberry Pi? > > Additionally, I’d like to ask for a rule of thumb for setting the > RelayBandwithBurst. I set it to 20 MB/s because I’m ok with the relay using > the whole upload bandwidth (about 10 MB/s, or 100 Mbps) for short periods of > time, but as I already explained I’m never seeing such speeds. > > For reference my relay’s fingerprint is > F942EE73F1B8E39125F617FA85E80E4C9E540A2E. > > -m > > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Multiple obsf4 Bridge Relays on macOS
Hi all, Firstly, I hope you're taking care and staying safe (against pandemics and surveillance, especially considering how the latter is taking advantage of the former). Secondly, and mainly, I am working on setting up ten obsf4 bridge relays on macOS and keep running into port issues, so I'm hoping to get some general advice and guidance about how to set this up in the absence of updated macOS tutorials online. These bridge relays are going to run on one macOS server. Knowing that they can each have their own dedicated IP address, could someone advise how to best set up these multiple obsf4 bridge instances so each can be run (tor -f /usr/local/etc/tor/torrc.1, torrc.2, torrc.3, etc...) under one non-root user with only two public ports open on the data center network (80 and 443)? I'm getting stuck at the port reachability phase, and even more so when trying to run multiple instances with forwarding/binding warnings. The Application Level Firewall allows certain granted programs (tor/tor-gencert/tor-print-ed-signing-cert/tor-resolve/torify/obfs4proxy) the ability to open or accept a network socket. By editing the macOS network system settings to route port 80 to 9005, and noting ORPort 80 NoListen ORPort 0.0.0.0:9005 NoAdvertise in the torrc, that works correctly (including routing 443 for obfs4proxy). Running a second instance is where it seems to break down. Is there a way to have multiple tor instances sharing a port? My guess is the main issue is that at the system routing level, I need a way to note each IP and port so it goes to the right tor instance. Currently, the forwarding is set up like: rdr pass on en1 inet proto tcp from any to any port 80 -> 127.0.0.1 port 9005 I'm guessing I need some way to designate IP XX.XXX.XX.120 -> port 9005 (torrc.1), XX.XXX.XX.121 -> port 9006 (torrc.2), XX.XXX.XX.122 -> port 9007 (torrc.3), etc. Is that correct? A copy of my notes and configurations so far can be found here: http://5jp7xtmox6jyoqd5.onion/p/ISjeXEW-vt8H1s89bwSW Please feel free to make suggestions or edits directly in that etherpad. I'm sure there are multiple ways to do this, but I definitely want to make sure I am using the most secure method as opposed to the easiest or quickest... Thanks for any help in advance. All the best, Wilton signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Low observed bandwith
Hi, > On 12 Apr 2020, at 10:10, Mario Costa wrote: > > I’m running a guard relay from my home connection on a Raspberry Pi 4. My > internet connection is 1000/100 Mbps, and I thought I’d allocate half of the > upload bandwidth for the relay. Then I set RelayBandwidthRate to 10 MB/s, > because I thought that Tor would upload 5 MB/s and download 5 MB/s. You have an asymmetric connections and Tor is a relay network. So your relay's speed will be limited by the slowest of your upload and download. Tor also assumes your connection is full duplex. (That is, there are separate limits of 10 MB/s up and 10 MB/s down.) You should set rate to the highest sustained bandwidth you're happy for Tor to use. Tor could use that much bandwidth for seconds or hours. That bandwidth should be lower than your connection bandwidth. (The minimum of your upload and download.) > However, the maximum observed bandwidth was always about 6 MB/s. I’d like to > know what could cause this low observed bandwidth. I don’t think it’s the > Raspberry Pi, because CPU usage is always low and it has a Gigabit connection > to the router. Where are you seeing this observed bandwidth? Tor reports its observed bandwidth over the busiest 10 second period each day. 60% of the rate is actually a pretty high load, because Tor is a low-latency network. (Once utilisation gets over around 10%, latency starts increasing.) If your connection is a high latency connection, Tor may send bandwidth to lower-latency connections. You can read a similar thread here: https://lists.torproject.org/pipermail/tor-relays/2020-April/018348.html > The router itself easily reaches Gigabit speeds, so 10 MB/s should be a > breeze. Could it be the number of connections? nyx indicates that the > connections are always about 4000. If this is the case, how can I know if the > connections bottleneck is the router or the Raspberry Pi? 4000 seems pretty normal. There are only around 6000 relays. Check your tor, kernel, and router logs for TCP warnings? > Additionally, I’d like to ask for a rule of thumb for setting the > RelayBandwithBurst. I set it to 20 MB/s because I’m ok with the relay using > the whole upload bandwidth (about 10 MB/s, or 100 Mbps) for short periods of > time, but as I already explained I’m never seeing such speeds. Setting your burst higher than your connection speed can cause latency or packet drops. Tor will allocate less bandwidth to slow or unreliable relays. You won't see the burst in Tor's observed bandwidth. The burst is over 1-2 seconds. The rate is averaged over a few seconds. Observed is over 10 seconds. Tor will compensate for a burst by having a few slow seconds afterwards. Set the burst to the highest speed you ever want the relay to use over 1-2 seconds. The burst should be equal to or lower than your connection speed. (In your case, the lowest of your upload and download speed.) > For reference my relay’s fingerprint is > F942EE73F1B8E39125F617FA85E80E4C9E540A2E. If you want Tor to use more bandwidth, try setting rate and burst to 10 Mbps. That way, you won't be causing congestion or packet drops. You may have to wait for a few weeks or months for your bandwidth to stabilise. https://blog.torproject.org/lifecycle-new-relay T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Question about authority clock skew
On 4/14/20 1:34 AM, Roger Dingledine wrote: > Using the definitions that "precision" is how many digits you're > providing, and "accuracy" is how right you are, I'd say that we're giving > you microsecond precision but not microsecond accuracy. :) Hehe, the first thing I was teached during my study was to not promise more accuracy than actually given ;-) -- Toralf signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
