7 ms·

No sources or benchmarks? Also: > But unless you’re using Fedora, your servers aren’t gonna taste it soon. Just by bad timing, the new Ubuntu LTS (18.04) due

by rb2k_ 8y ago

No sources or benchmarks? Also: > But unless you’re using Fedora, your servers aren’t gonna taste it soon. Just by bad timing, the new Ubuntu LTS (18.04) due out next week will still use 4.15, which it will support for 5 years. Since CentOS and Debian are even further behind on kernels, you won’t see a lot of “fast Linux” in production until April 2020 when Ubuntu 20.04 LTS comes out. If you are at a point where the differences would matter to you, you can (and will) probably just install a newer kernel and have the improvements available today. Just because upstream doesn't have it doesn't mean you couldn't compile it yourself or use backports.

corv 8y ago
> No sources or benchmarks? There was this in TFA: https://www.phoronix.com/scan.php?item=netperf-bsd-linux&num=3&page=article https://www.phoronix.com/scan.php?item=netperf-bsd-linux&num...
- r1ch 8y ago
  This benchmark is kind of meaningless. What is a "TCP request response" actually measuring? Any Linux server can certainly handle more than 340 HTTP reqs/sec for example. The "netperf" benchmarking software appears to be from 1993 (complete with a webpage from that era! https://hewlettpackard.github.io/netperf/ https://hewlettpackard.github.io/netperf/) so I have a lot of doubts that it is using modern networking APIs or taking advantage of modern hardware.
  - drewg123 8y ago
    Netperf is probably the most widely adopted network benchmark out there. Almost every company I've seen has used it for performance and Q/A testing. For what it does, it is quite efficient. I remember when I was doing 10GbE drivers in the mid 2000s, people would complain of terrible performance on "modern" tools like iperf, but would see 10Gb/s using netperf. This is because "modern" tools did things like gettimeofday() around every socket read or write, making them basically gettomeofday() benchmarks at high message rates, but netperf did the gettimeofday() around the entire test. Netperf's problem has always been that it is single connection, single-threaded. Most people use it coupled with patches or scripts to run many copies of netperf in parallel. I suspect what happened in these tests is that the author just ran a single copy of the tests, and did not bother to adjust the interrupt coalesing settings. So what he really measured was different interrupt coalescing settings in the FreeBSD and Linux driver. If he'd have run 500 or 1000 copies, I'll bet he'd see vastly different results. BTW, if you're looking for a modern network benchmark, check out uperf (http://uperf.org/ http://uperf.org/) It seems to have been largely abandoned after the Oracle acquisition, which is a shame, because it was just plane awesome. It could replicate many scenarios very realistically, supported multi-threading, etc.
    - rjmcmahon 8y ago
      Iperf 2.0.10+ uses clock_gettime() when a timestamps is needed. For TCP and no interval reporting the only calls needed are at the beginning and end of the test. The performance problem we hit with 2.0.5 had to do with insufficient shared memory between traffic threads and the reporter thread.
- jasondclinton 8y ago
  The benchmark results at that link are from machines with different processor clocks. The results are invalid.
ams6110 8y ago
> Just because upstream doesn't have it doesn't mean you couldn't compile it yourself True, but if you are managing production machines, compiling kernels for every errata and security update is pretty low on the list of things you get enthusiastic about. Also a lot of commercial or scientific linux software is only "certified" and supported on stock RHEL kernels.
- cozzyd 8y ago
  There's always http://elrepo.org/tiki/kernel-ml http://elrepo.org/tiki/kernel-ml (and also kernel-lt) so you don't have to compile things yourself. But things like VMWare and various proprietary device drivers will break.
- geofft 8y ago
  On the other hand, if you're making or losing money on latency (e.g., you're a high-frequency trader), compiling kernels for every potential performance improvement is a thing you're enthusiastic about, a lot of security fixes (local privilege escalations, drivers for desktop hardware, etc.) don't apply to you, and you don't care about things being "certified" because you have the expertise to fix problems in-house as necessary. And from the other direction, if you're making or losing money on security, expecting distro kernels to turn around security fixes in a timely manner seems like a mistake. At least know how to rebuild your distro kernel with a local patch.
- rb2k_ 8y ago
  The amount of filesystem/networking issues I've seen fixed and all the performance improvements I got from just updating a kernel probably make up for the time that it caused issues. I guess it needs a critical mass + certain infrastructure maturity that running on whatever the latest kernel is makes sense. As for the 'certified on stock RHEL kernel' software... I try to keep away from those, but I'm picky and pretty lucky when it comes to job selection :)
fulafel 8y ago
It's also incorrect even for LTS supported kernels: LTS releases incorporate new kernel versions along the way as part of the hardware enablement work, though they are not used by default. For example, here's 4.13 in the previous LTS (16.04), up from the default 4.4: http://packages.ubuntu.com/linux-signed-image-generic-hwe-16.04 http://packages.ubuntu.com/linux-signed-image-generic-hwe-16...

by rb2k_ 8y ago

corv 8y ago

> No sources or benchmarks? There was this in TFA: https://www.phoronix.com/scan.php?item=netperf-bsd-linux&num=3&page=article https://www.phoronix.com/scan.php?item=netperf-bsd-linux&num...

r1ch 8y ago
This benchmark is kind of meaningless. What is a "TCP request response" actually measuring? Any Linux server can certainly handle more than 340 HTTP reqs/sec for example. The "netperf" benchmarking software appears to be from 1993 (complete with a webpage from that era! https://hewlettpackard.github.io/netperf/ https://hewlettpackard.github.io/netperf/) so I have a lot of doubts that it is using modern networking APIs or taking advantage of modern hardware.
- drewg123 8y ago
  Netperf is probably the most widely adopted network benchmark out there. Almost every company I've seen has used it for performance and Q/A testing. For what it does, it is quite efficient. I remember when I was doing 10GbE drivers in the mid 2000s, people would complain of terrible performance on "modern" tools like iperf, but would see 10Gb/s using netperf. This is because "modern" tools did things like gettimeofday() around every socket read or write, making them basically gettomeofday() benchmarks at high message rates, but netperf did the gettimeofday() around the entire test. Netperf's problem has always been that it is single connection, single-threaded. Most people use it coupled with patches or scripts to run many copies of netperf in parallel. I suspect what happened in these tests is that the author just ran a single copy of the tests, and did not bother to adjust the interrupt coalesing settings. So what he really measured was different interrupt coalescing settings in the FreeBSD and Linux driver. If he'd have run 500 or 1000 copies, I'll bet he'd see vastly different results. BTW, if you're looking for a modern network benchmark, check out uperf (http://uperf.org/ http://uperf.org/) It seems to have been largely abandoned after the Oracle acquisition, which is a shame, because it was just plane awesome. It could replicate many scenarios very realistically, supported multi-threading, etc.
  - rjmcmahon 8y ago
    Iperf 2.0.10+ uses clock_gettime() when a timestamps is needed. For TCP and no interval reporting the only calls needed are at the beginning and end of the test. The performance problem we hit with 2.0.5 had to do with insufficient shared memory between traffic threads and the reporter thread.
jasondclinton 8y ago
The benchmark results at that link are from machines with different processor clocks. The results are invalid.

ams6110 8y ago

> Just because upstream doesn't have it doesn't mean you couldn't compile it yourself True, but if you are managing production machines, compiling kernels for every errata and security update is pretty low on the list of things you get enthusiastic about. Also a lot of commercial or scientific linux software is only "certified" and supported on stock RHEL kernels.

cozzyd 8y ago
There's always http://elrepo.org/tiki/kernel-ml http://elrepo.org/tiki/kernel-ml (and also kernel-lt) so you don't have to compile things yourself. But things like VMWare and various proprietary device drivers will break.
geofft 8y ago
On the other hand, if you're making or losing money on latency (e.g., you're a high-frequency trader), compiling kernels for every potential performance improvement is a thing you're enthusiastic about, a lot of security fixes (local privilege escalations, drivers for desktop hardware, etc.) don't apply to you, and you don't care about things being "certified" because you have the expertise to fix problems in-house as necessary. And from the other direction, if you're making or losing money on security, expecting distro kernels to turn around security fixes in a timely manner seems like a mistake. At least know how to rebuild your distro kernel with a local patch.
rb2k_ 8y ago
The amount of filesystem/networking issues I've seen fixed and all the performance improvements I got from just updating a kernel probably make up for the time that it caused issues. I guess it needs a critical mass + certain infrastructure maturity that running on whatever the latest kernel is makes sense. As for the 'certified on stock RHEL kernel' software... I try to keep away from those, but I'm picky and pretty lucky when it comes to job selection :)

fulafel 8y ago

It's also incorrect even for LTS supported kernels: LTS releases incorporate new kernel versions along the way as part of the hardware enablement work, though they are not used by default. For example, here's 4.13 in the previous LTS (16.04), up from the default 4.4: http://packages.ubuntu.com/linux-signed-image-generic-hwe-16.04 http://packages.ubuntu.com/linux-signed-image-generic-hwe-16...