Re: [tor-relays] Quick Assist Technology and Tor?
Excerpts from mail--- via tor-relays's message of June 22, 2024 5:14 pm: > Hi o/, > > During the Tor Operator Meetup I asked about Quick Assist Technology (QAT) > support and was asked to bring it to the tor-relays mailing list so the > network team can take a look at the question. > > In 2025 we're going to build one or more new servers and we're looking in to > optimizing the performance per watt ratio since some of our current servers > are rather power hungry ;-). > > I'm wondering whether QAT works for Tor to offload compression, hashing and > encryption. In theory, looking at the nature of Tor (a lot encryption), this > could result in a huge performance boost of 100-300% (based on other hashing, > cryptographic and compression offload benchmarks). Support for QAT also has > improved considerably over the years so many programs/workloads already work > nicely with it, but I'm not sure about Tor. > > It looks like Tor uses [1] RSA-1024, AES-CBC, AES-CTR, Curve25519, Ed25519, > SHA1, AES256, AES3-256. Most (no Curve- and Ed25519) should in theory also > work with QAT [2] (although I guess only a few would impact performance > significantly when offloaded). But the question is: does it really work? If > not, what would be needed to make it work? Are there Tor operators who > already utilize QAT? Does the Network Team have some insight in to this? :) > > Some of the potential advantages when comparing a similar amount of traffic: > - Lower power consumption (much cheaper to run in expensive European > countries). > - Less CPU cycles required (= cheaper CPUs). > - Less heat/cooling required (easier to put in distribution boxes and other > small places). > - Smaller physical footprint (easier to put in distribution boxes and other > small places). > - Alleviates some of the issues and challenges caused by Tor's single > threaded architecture by effectively increasing bandwidth per CPU core > considerably. > > With regards, > > tornth > > [1] > https://spec.torproject.org/tor-spec/preliminaries.html?highlight=cipher#ciphers > [2] > https://www.intel.com/content/www/us/en/support/articles/93843/technologies/intel-quickassist-technology-intel-qat.html > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > I previously answered this at https://lists.torproject.org/pipermail/tor-relays/2022-April/020495.html. In principle, it should work if you set HardwareAccel 1. However, based on my profiling, the actual AES encryption doesn't use that much CPU when using regular AES instructions. I couldn't find any independent QAT benchmarks from an internet search, but https://calomel.org/aesni_ssl_performance.html says AES-NI can reach over 1 GB/s per core, which is far more than Tor can use. Cheers, Alex. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay no longer acting as a gaurd node?
Excerpts from Jonathan Proulx's message of November 9, 2023 10:03 am: > Hi All, > > A little while ago one of my relays switched from usually acting as a > guard node to never acting as a guard node: > > https://metrics.torproject.org/rs.html#details/9715C81BA8C5B0C698882035F75C67D6D643DBE3 > > Doesn't matter to me if it's a guard or not jsut want to understand > what's changed and if it's a problem. Do I have a misconfiguration? > > -Jon Your relay doesn't have the Stable flag, which is a requirement for Guard. If you're not sure why your relay is seen as unstable, you can try to run some monitoring software, or sign up for the revamped Tor Weather service (https://weather.torproject.org/). Unfortunately, if your downtime is due to system updates, you'll need to try to consolidate those, as even scheduled restarts are counted against a relay for Guard status. I'm not sure what the MTBF criteria are now, but restarting more than once a week will probably disqualify a relay from being a Guard. Cheers, Alex. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List number of circuits per connection
Excerpts from Logforme's message of October 19, 2022 8:47 am: > I run the relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3 > > Like most relays mine has been targeted by the DoS attack. Hundreds of > VPS IPs creating millions of IP connections. This I mitigated with rules > in my firewall. Looking at the firewall counters it looks like that > attack has now stopped. > > However the relay is still overloaded from lots of circuit creations. > Normally my little relay reports around 100K circuits open in the log > file but since the overloading started it's closer to 1M circuits open. > All these circuit creations put a strain on the CPU, sometime pegging it > at 100% (4 core i5-4670K CPU @ 3.40GHz). Worse, it seems to eat memory. > Normally the tor process uses about 3GB (out of 8GB) but I have seen it > quickly shoot up to using all memory and all swap. I assume this is > because of the circuit creation DoS (it's new behavior) and what causes > the oom killer to kill the tor process at least once a day or so. > > So, how do I mitigate the circuit creation DoS? My immediate thought is > to identify if there are a few IPs responsible for the majority and add > those to my firewall naughty list. > > Is there a way to query the tor process about number of open circuits > mapped to IP addresses? > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > this is a good idea, which is why someone's already had it (me, possibly also other people). there are a few problems with this plan: 1. tor doesn't expose this information in log (without SafeLogging 0, highly discouraged and possibly illegal except for testing) or control port, because it could potentially be used to deanonymize clients, made worse because... 2. it might not possible to know in general whether the clients with many connections are "abusive" clients or "abused" onion services. additionally, you definitely need to filter out relays, which will obviously have lots of open circuits. there are a couple of decent ways to do that, but it's non-trivial. for these reasons, I haven't aggressively pursued this plan. I have some more ideas based on intra-family correlation, but they also have similar problems as well as more implementation problems. in the long term, our best hope is the PoW scheme (note: not cryptocurrency) being somewhat quietly worked on. cheers, Alex. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] FreeBSD 13.1: clock_gettime(CLOCK_MONOTONIC_FAST) ~ 50 % performance gain
Excerpts from Andreas Kempe's message of June 21, 2022 11:50 am: > Hello everyone, > > I was doing some profiling on my two relays running on FreeBSD 13.1 > and noticed that they were spending a lot of time in clock_gettime() > which prompted me to have a look at the implementation. > > Time implementation > === > > The time implementation is abstracted in src/lib/time/compat_time.c > where different mechanisms are used for different operating systems. > On Linux CLOCK_MONOTONIC_COARSE is a clock that gives worse precision > than CLOCK_MONOTONIC, but is faster and the abstraction layer checks > for its presense and provides more performat less precise time where > applicable. > > On FreeBSD, there is also a fast monotonic time source available > called CLOCK_MONOTONIC_FAST. In the header file > src/lib/time/compat_time.h, a comment references this clock, but it is > not used. I thought it might be worth a shot seeing what difference it > would make if I enable the use of CLOCK_MONOTONIC_FAST on FreeBSD and > on the VM where I run my two FreeBSD relays, the difference was > stunning. > > I made did a quick patch simply replacing CLOCK_MONOTONIC_COARSE with > CLOCK_MONOTONIC_FAST, see patches attached, compiled and tested. > Tracing system calls to make sure the correct call was being used, > which it was. According to https://www.freebsd.org/cgi/man.cgi?query=clock_gettime, FreeBSD 13.1 has CLOCK_MONOTONIC_COARSE, which it says is an alias of CLOCK_MONOTONIC_FAST for compatibility with other systems. I suppose Tor could add #if !defined(CLOCK_MONOTONIC_COARSE) && defined(CLOCK_MONOTONIC_FAST) #define CLOCK_MONOTONIC_COARSE CLOCK_MONOTONIC_FAST, but I'm not sure how useful that would be. OpenBSD and NetBSD don't seem to define either. Perhaps something like that would be appropriate for a FreeBSD ports patch. Cheers, Alex. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [Workshop] Sysadmin 101 for (new) relay operators - June 4th @ 1900 UTC
Excerpts from gus's message of May 23, 2022 3:42 pm: > ## How to join the workshop > > The workshop is entirely free, and participants need to fill out this > registration form. The event will take place on BigBlueButton, an online > video conference platform, on June 4th at 1900 - 2030 UTC. > > You can register here: > https://nc.torproject.net/apps/forms/cDLPxryHJcP5kMeW Can you explain why it is necessary to register in order to attend? Additionally, the URL to the Code of Conduct is neither clickable nor selectable, making it rather difficult to navigate to. Thanks, Alex. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Does Tor work with Intel QAT acceleration
Excerpts from Andreas Bollhalder's message of April 12, 2022 2:12 am: > > Hello Alex > > Thank you for your nice hint ot QAT_Engine. > > Yes, in theory it really seems to be possible. Looking at the Github repo of > the QAT_Engine, it looks like there are still some issues with OpenSSL 3.0: > Support for QAT HW ECX, QAT SW ECX, QAT HW PRF and QAT HW HKDF is disabled > when built > against OpenSSL 3.0 due to known issues instead it uses non-accelerated > implementation > from OpenSSL.I'm on Ubuntu 20.04, so I should be still using OpenSSL 1.x. > There are plans for switching to OpenSSL 3.0 in Ubuntu 22.04. We'll see... > > So, one really has to test and I need to think about it. Wouldn't be a cheep > test, but if this platform can give me a medium power system (~50W) and great > speed, then it's definitively what I'm looking for. Otherwise I would prefer > a Ryzen like the 5750GE. > > Andreas If you don't already have a QAT device, I would not suggest getting one specifically for Tor. In particular, Tor doesn't spend very much time actually doing AES. It's mostly overhead from cell processing, TCP, small packets, etc. Additionally, because Tor uses a large number of relatively low-bandwidth connections, it will mostly send small chunks to the hardware engine, which is not particularly efficient. In the future, it may be possible to use KTLS, in which case QAT might actually improve performance quite a bit. However, there are a number of blockers to this, including that it messes with Tor's bandwidth limiting. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
