[tor-relays] Why is my Tor bridge relay not getting any traffic?
Hello everybody! I used to run a Tor bridge on Windows at home, where I have a 300/150 Mbps ISP. This Windows has memory leak and crashes after some hours, ad I believe that was making my bridge never get traffic. A few weeks ago I moved it to a Ubuntu server, also at home. I use uptimerobot.com to monitor if its port is reachable from outside and healthchecks.io to monitor if traffic entering from its local SOCKS port is reaching check.torproject.org. It's always up and reachable. But nyx reports it's rarely getting any traffic, and its bandwidth never surpasses 1KB/s. Its log heartbeat reports very little download and upload and always claims to has seen 0 unique clients. But how come, if my healthchecks.io monitor's curl call uses it every few minutes? metrics.torproject.org reports correct dates and uptime. Advertised Bandwidth is 58KB/s, way above what nyx reports. Flags are Fast, Running, V2Dir, Valid. What might be wrong? Or is it normal for a Tor bridge relay be this idle? This is my torrc removing identifiable data. |## Configuration file for a typical Tor user ## Last updated 9 October 2013 for Tor 0.2.5.2-alpha. ## (may or may not work for much older or much newer versions of Tor.) ## A handle for your relay, so people don't have to refer to it by key. Nickname MyNick ContactInfo mycontact ## Entry policies to allow/deny SOCKS requests based on IP address. SocksPort 9031 #SocksPort ::9031 #SocksPort 0.0.0.0:80 #SOCKSPolicy accept 192.168.* ## Send all messages of level 'notice' or higher to /var/log/tor/notices.log Log notice file /var/log/tor/notices.log ## Send every possible message to /var/log/tor/debug.log #Log debug file /var/log/tor/debug.log ## Use the system log instead of Tor's logfiles #Log notice syslog ## Uncomment this to start the process in the background... or use RunAsDaemon 1 ## The directory for keeping all the keys/etc. By default, we store ## things in $HOME/.tor on Unix, and in Application Data\tor on Windows. DataDirectory /var/lib/tor ## The port on which Tor will listen for local connections from Tor ## controller applications, as documented in control-spec.txt. ControlPort 9051 ## If you enable the controlport, be sure to enable one of these ## authentication methods, to prevent attackers from accessing it. CookieAuthentication 1 This section is just for relays # # ## See https://www.torproject.org/docs/tor-doc-relay for details. ## The IP address or full DNS name for incoming connections to your ## relay. Leave commented out and Tor will guess. Address hikari.mydomain.com ## Required: what port to advertise for incoming Tor connections. ORPort 80 ## Uncomment this to mirror directory information for others. Please do ## if you have enough bandwidth. DirPort 9030 # what port to advertise for directory connections ServerTransportPlugin obfs3,obfs4 exec /usr/bin/obfs4proxy #ExtORPort 0.0.0.0:8000 ExtORPort 9041 ## Uncomment to return an arbitrary blob of html on your DirPort. Now you ## can explain what Tor is if anybody wonders why your IP address is ## contacting them. See contrib/tor-exit-notice.html in Tor's source ## distribution for a sample. #DirPortFrontPage /etc/tor/tor-exit-notice.html ExitPolicy reject *:* # don't run as an exit node BridgeRelay 1 # bridge PublishServerDescriptor 1 # published on bridge directory DB BridgeRecordUsageByCountry 1 # it's nice to see the country codes of users you are assisting #BandwidthRate 512000 #RelayBandwidthBurst 512000 #RelayBandwidthRate 512000 CellStatistics 1 PaddingStatistics 1 DirReqStatistics 1 EntryStatistics 1 ExitPortStatistics 1 ConnDirectionStatistics 1 HiddenServiceStatistics 1 ExtraInfoStatistics 1 #If non-zero, try to write to disk less frequently than we would otherwise. This is useful when running on flash memory or other media that support only a limited number of writes. (Default: 0) AvoidDiskWrites 0| ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Improving throughput on weak CPU?
A few years ago I had some Intel Atoms with Scaleway. Same problem. Its the best a Atom can do :/ niftybunny > On 26. Aug 2019, at 11:06, Jochen wrote: > > Hi there, I'm the operator of the following two exit nodes: > > https://metrics.torproject.org/rs.html#search/family:94C268630BEDCB64E7F8881881A23D053F243C18 > > My CPU is an Intel C2750 (8 cores total), which supports hardware accelerated > AES yet a single process still maxes out at only ~150mbit/s. > > To get the most out of the machine and my single IPv4 address, I simply ran > another relay which works fine, and now I'm averaging at around ~315mbit/s. > > Is there anything else I can tweak to improve throughput without having to > order more IP addresses? I'm running Arch with stock 5.2.9 linux kernel. > > That being said, true multi threading would be much appreciated and would > help people like me a lot :-) > > Regards, > > Jochen > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Measuring the Accuracy of Tor Relays' Advertised Bandwidths
> On 27 Aug 2019, at 05:19, Toralf Förster wrote: > >> On 8/26/19 3:14 AM, teor wrote: >> We expect to have funding to fix these bugs some time in the next month >> or two. > > So I'll just wait. Waiting might not help, if the issue is on your relay: >> I don't think the sbws bandwidth authorities are causing the issue that >> you're seeing with your consensus weight or flags. >> >> The consensus is based on majority votes, and 2/6 bandwidth authorities >> or 2/9 authorities are not a majority. > FWIW I set "RelayBandwidthRate 30 MBytes" for a day or so to see whether a > possible overload of the my relays could cause some trouble but did not see > any positive effect so far. Perhaps your provider is dropping traffic, or has bad peering? T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Improving throughput on weak CPU?
Hi, > On 26 Aug 2019, at 19:06, Jochen wrote: > > Hi there, I'm the operator of the following two exit nodes: > > https://metrics.torproject.org/rs.html#search/family:94C268630BEDCB64E7F8881881A23D053F243C18 > > My CPU is an Intel C2750 (8 cores total), which supports hardware accelerated > AES yet a single process still maxes out at only ~150mbit/s. > > To get the most out of the machine and my single IPv4 address, I simply ran > another relay which works fine, and now I'm averaging at around ~315mbit/s. > > Is there anything else I can tweak to improve throughput without having to > order more IP addresses? I'm running Arch with stock 5.2.9 linux kernel. > > That being said, true multi threading would be much appreciated and would > help people like me a lot :-) Which code is your relay spending most of its (main thread) time on? If you can send us a profile, we will know where to focus our effort. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Measuring the Accuracy of Tor Relays' Advertised Bandwidths
On 8/26/19 3:14 AM, teor wrote: > We expect to have funding to fix these bugs some time in the next month > or two. So I'll just wait. FWIW I set "RelayBandwidthRate 30 MBytes" for a day or so to see whether a possible overload of the my relays could cause some trouble but did not see any positive effect so far. -- Toralf PGP C4EACDDE 0076E94E 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
[tor-relays] Improving throughput on weak CPU?
Hi there, I'm the operator of the following two exit nodes: https://metrics.torproject.org/rs.html#search/family:94C268630BEDCB64E7F8881881A23D053F243C18 My CPU is an Intel C2750 (8 cores total), which supports hardware accelerated AES yet a single process still maxes out at only ~150mbit/s. To get the most out of the machine and my single IPv4 address, I simply ran another relay which works fine, and now I'm averaging at around ~315mbit/s. Is there anything else I can tweak to improve throughput without having to order more IP addresses? I'm running Arch with stock 5.2.9 linux kernel. That being said, true multi threading would be much appreciated and would help people like me a lot :-) Regards, Jochen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
