Separate names with a comma.
Discussion in 'General Chat' started by Geran, Sep 14, 2018.
Linus finally going to use pfsense
He's been using pfsense for awhile now. Watching him build it and set it up was painful
24:20 in case you don't want to watch the whole video
I put it to start playing 5secs before he mentions it and that works for me.
I wonder if he'll get his 10gig networking solid before I do
Not as painful as watching him build / cable his server room.
I give him credit for getting things "done" but I'd hate to support it.
Spent a solid amount of time and had nothing but good things to say other than the name which is something @Patrick wrestled with years ago but the name was already too established I think to change.
Serve the Home... "Where we are the only people to do real testing, in a real datacenter, with servers that cost more than your house." Maybe that is where the "Home" part comes from. I love this place.
I admit I'm here because of Linus (although the actual main reason I am here is because I like networking, system administration, home labbing, home servers, all that good stuff). He can definitely have his cringe moments but he's honestly pretty entertaining in my opinion.
Well welcome. There is a ton of knowledge here and a pretty great community.
Also it would be interesting to see if there is a traffic spike or new member spike in the couple days after the video.
There goes the neighbourhood.
There was a spike today. The front page Xeon discount article got picked up on [H], Reddit, Twitter and etc. Friday afternoon is usually slow for us as the EU is in the evening and the east coast US has signed off for the weekend. We have been running at about 2x normal Friday traffic most of the day.
On the LTT note. It was a surprise. I was at a songwriter concert (D.Vincent Williams, Lee Thomas Miller, Wendell Mobley and Paul Overstreet for country music fans) and started getting messages about it.
I do not think we got a link so we have not seen a traffic spike from that. At the same time, it was nice to have someone say something nice about STH. I wake up in the morning expecting people will tell me I know nothing about servers. Nice to get a positive message.
And welcome @ipkpjersi to STH.
@Patrick do you know what he is referring to when it talks about quickassist helping with pfsense?
Intel QAT will accelerate time consuming cryptographic operations, compare
https://01.org/sites/default/files/...-intelquickassisttechnologyandopenssl-110.pdf page 14ff
QAT will be most helpful e.g. when doing many RSA-2048 operations per second (new connections from SSL clients need this), but I doubt his VPN tunnel will profit much from it. For his intended use of VPN office to home with 1 Gbps symmetric cipher performance is more important. See
Benchmarks - WireGuard how a simple Ivy Bridge can saturate 1 Gbps already.
Aren't VPN speeds dependent on clock speed and not core count?
depends on the VPN implementation. for single stream openvpn, yes.
I am not even sure pfsense (i.e. FreeBSD) supports QAT. And it doesn't have to, because clever selection of cipher and authentication algorithms as exemplified by WireGuard will beat QAT through pure speed/instruction advances in general purpose CPUs. Except maybe 1% of corner cases that are not worth optimizing for imho anyway. Not saying WG is usable in pfsense (there is a slow user mode FreeBSD port), but that is the current VPN performance+security leader once upstreamed into the kernel (soon imho, because Torvalds reacted positively on LKML when seeing the first patches).
OpenVPN will profit from fast single-thread performance, unless you turn off expensive authentication (HMAC-SHA1 or similar) or switch to AES-GCM and can rely on AES-NI instructions from the cpu. Together with pfsense on FreeBSD it can be a very mixed bag and needs careful optimization.
My main point I guess is that for LTT to get anywhere near 10 Gbps VPN capability they need to dump pfsense and use plain Linux with WireGuard.
wireguard values simplicity above all else. note that the publicly available wireguard comparison uses hardware several generations old--the aes-ni performance of modern cpus is dramatically better. chacha-poly in software is simply slower than aes-gcm in hardware. and you can't tune wireguard to use a different algorithm if you don't have old clients and you know that the hardware crypto will perform better for you...
Yes AES-GCM is faster. Not by much though, see It takes two to ChaCha (Poly) On older CPUs at 1.5k packet sizes with 256-bit security level AES-GCM is only ahead 30%. On newer CPUs AES-GCM is faster more like 50%, compare On the dangers of Intel's frequency scaling but on such chips ChaCha20-Poly1305 will do 2.89 GB/sec/core i.e. saturate a 10 Gbps link duplex with a single core. Impressive really, and good enough...
Ever since Meltdown I am suspicious though of Intel not having yet another security problem in their silicon. Like a key-dependant timing side channel that lets you probe a system for a day and then you have the secret key of the victim server in hand. I realize this is highly paranoid thinking, but some data deserve only the best for protection. On AES-GCM you'd need to wait at least many months for Intel to come up with a microcode fix, if one is possible and this is not a FDIV kind of bug that requires a CPU swap. Which in essence would be a full system swap, because fixed CPU means different chipset means upgrade of the server. $$$ Or implement expensive flushes like against L1TF that throw you back into Haswell performance territory.
Chacha20-poly1305 could be fixed in software fast and cheap, should a problem show up. And there would be enough agility to even work around hardware weaknesses, should any more come up. After all it uses only SIMD.
And the chachapoly implementation only hits that speed with AVX-512, which isn't in most CPUs on the market. (Only the high-end server CPUs; if you have a desktop on one end you'll get a heck of a lot of AES acceleration but your chachapoly performance will be relatively worse. You're looking at somewhere around 4-5GB/s AES-128-GCM vs somewhere around 1.5GB/s CHACHA20-POLY1305.) See ARM Takes Wing: Qualcomm vs. Intel CPU comparison for a better per-generation breakdown. And if you follow the advice in the that post and abandon AVX-512 for this purpose due to the bad effects on overall performance, you're back well under 2GB/s even on the latest high-end hardware. Given the games intel's playing with AVX-512 as a product differentiator (and its lack of implementation on AMD) I don't expect that to change in the near future. Longer term maybe it'll be more available, but then we'll need to throw the new AVX AES instructions into the mix as well... (Kaby Lake has AES-GCM down to .64 cycles/byte vs , while the Ice Lake vector AES is projected to hit .16 cycles/byte; for comparison the ivy bridge architecture used on the wireguard performance page does AES-GCM in something like 2.5 cycles/byte!)
So, basically, there's a wholly imaginary attack against all AES-NI implementations, but no possible imaginary attack against AVX? In either case you could drop to a non-accelerated algorithm at the cost of an enormous performance penalty. It's worth noting that the AES-NI instructions were one of the few parts of the intel instruction set actually designed with side-channel resistance as a goal. (Unlike most of the recent side channel attacks, which involve functionality not explicitly designated as resistant to such attacks because nobody really cared to spend the money on that threat--including the AVX instructions.)