Linux Distributions vs. BSDs With netperf & iperf3 Network Performance

[indepe]

[...]

Netperf 2.7.0
Server: 169.254.122.150 - Test: TCP Request Response - Duration: 10 Seconds
Transaction Rate Per Second
generic ...... 572.88 |========================================
lowlatency .. 862.21 |================================================= ===========

[...]

I'm not sure if those results are comparable to Phoronix ones, but it seems strange my medium end laptop performs better.

That's an interesting measurement! Wondering what exactly causes this difference, and if it can also be done with normal kernel. Probably not easy to tell.

I'm not yet set up to make such measurements myself, but I expect to, sometime in the future.

[Guest]

Some Linux driver issue for Intel NIC? You seem to have markedly better results but also have different NIC in your machine (Atheros gigabit)

It's hard to say. I have another laptop from my friend, so I'll do some benchmarks. I'll also try to benchmark my PC which was serving here as a server. Too bad PTS have some irritating errors. For example I had to choose different names for every next lowlatency kernel benchmark. I also wasn't able to upload results to OpenBenchmarking due to some ftp error.

[Guest]

That's an interesting measurement! Wondering what exactly causes this difference, and if it can also be done with normal kernel. Probably not easy to tell.

I'm not yet set up to make such measurements myself, but I expect to, sometime in the future.

Maybe nvidia blob? It was disabled with lowlatency kernel. I'll make some more benchmark with newer kernel and different options, but I'll be busy this week.

[profoundWHALE]

Bullshit, you can swap sysvinit with systemd and it will work 100% the same with init scripts. You can even run OpenRC on top of systemd (working as sysvinit), the same as OpenRC runs on top of sysvinit.

Ah, this reminds me of the time that installing a media player or something (I think it was vlc) on Debian whilst using systemd. I figured it would be fine to install so I just told it "y" when it asked me. Ended up killing the init system. Whoops. For whatever reason the program I wanted to install had a dependency with sysvinit that had it remove systemd and then try to install sysvinit but ran into an issue with package versions...

Anyways, I think you missed the point. The point was (as I understand it) systemd does not work very well with anything else, everything else needs to work well with systemd. It's the same philosophy, for better or worse, that gave us pulseaudio. I only see pulseaudio on linux. I don't believe that it is used on anything other than desktop linux because of the design philosophy.

[Tomin]

Ah, this reminds me of the time that installing a media player or something (I think it was vlc) on Debian whilst using systemd. I figured it would be fine to install so I just told it "y" when it asked me. Ended up killing the init system. Whoops. For whatever reason the program I wanted to install had a dependency with sysvinit that had it remove systemd and then try to install sysvinit but ran into an issue with package versions...

Sounds more like someone screwed up the packaging than systemd's fault.

Anyways, I think you missed the point. The point was (as I understand it) systemd does not work very well with anything else, everything else needs to work well with systemd. It's the same philosophy, for better or worse, that gave us pulseaudio. I only see pulseaudio on linux. I don't believe that it is used on anything other than desktop linux because of the design philosophy.

I don't think that's true. Systemd has invented a lot of new things, which is true, but only because those things didn't exist before. Then again I don't know everything about systemd, so maybe I missed something. And doesn't pulseaudio have alsa compatibility layer or something like that?

[starshipeleven]

For whatever reason the program I wanted to install had a dependency with sysvinit that had it remove systemd and then try to install sysvinit but ran into an issue with package versions...

Neat, a completely unrelated packaging issue.

If I had a dime for all the times I've seen apt that asked me if I wanted to nuke half the system, convert ALL the system to 32bit libs or delete the DE because some package required bullshit or because Debian lacked proper multiarch so I had to install it manually with dpgk -i --force-all (or something like that) while cursing loudly....

Anyways, I think you missed the point. The point was (as I understand it) systemd does not work very well with anything else, everything else needs to work well with systemd.

Provide relevant examples to back up these claims, I'm tired of people that simply rephrase the same bullshit.
Systemd runs correctly programs that provide initscripts read by other init systems too so I don't see how "everything else needs to work well with it".

It's the same philosophy, for better or worse, that gave us pulseaudio.

Lol nope.
Also ALSA or OSS or Mesa or sysvinit whatever else working at the OS level requires that applications "need to work well with them", that's normal hierarchy.

I only see pulseaudio on linux. I believe that it isn't used outside of desktop linux because of the design philosophy.

(removed the confusing triple negation in the last sentence, preserved the same meaning)
Main reason Pulseaudio isn't used outside Linux is that some other OS have already their own sound system and it is fine (Windows or macOS), and *BSDs have relatively better situation with audio than Linux for basic stuff, and since their notion of PC or server is still firmly rooted in the early 90's they don't need all fancy things that Pulse allows, like for example 5.1 audio setups or bluetooth audio or whatever.

[aht0]

Main reason Pulseaudio isn't used outside Linux is that some other OS have already their own sound system and it is fine (Windows or macOS), and *BSDs have relatively better situation with audio than Linux for basic stuff, and since their notion of PC or server is still firmly rooted in the early 90's they don't need all fancy things that Pulse allows, like for example 5.1 audio setups or bluetooth audio or whatever.

I will forego the systemd portion of the debate now, you know I dislike it anyway.

"Pulseaudio" exists outside Linux. You can install it on FreeBSD for example if you feel like masochist. It's older version though. And AFAIK in the end it's going to still use OSS backend.

You are wrong partially. A lot of things Pulseaudio was meant to do, were doable in BSDs already on kernel level so it's in large parts superfluous to existing functionality.

[F.Ultra]

There must definitely be something strange going on between Linux and the particular NIC used in the tested machine. Just tested myself on a much leaner CPU (Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz) using the Intel igb NIC driver and had no problem to saturate 1Gbps (and this was tested on working servers as well) and I did also use the botch standard kernel (3.13.0-101-generic) in Ubuntu 12.04LTS so no low-latency kernel:

root@lon:~# netperf -H x.159.94.204 -t TCP_STREAM
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to x.159.94.204 () port 0 AF_INET : demo
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  

 87380  16384  16384    10.02     935.49  

root@lon:~# netperf -H x.159.94.204 -t TCP_MAERTS
MIGRATED TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to x.159.94.204 () port 0 AF_INET : demo
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  

 87380  16384  16384    10.00     937.93  

root@lon:~# netperf -H x.159.94.204 -t TCP_RR
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to x.159.94.204 () port 0 AF_INET : demo : first burst 0
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate        
bytes  Bytes  bytes    bytes   secs.    per sec  

16384  87380  1        1       10.00    19201.19  
16384  87380

root@lon:~# netperf -H x.159.94.204 -t UDP_RR
MIGRATED UDP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to x.159.94.204 () port 0 AF_INET : demo : first burst 0
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate        
bytes  Bytes  bytes    bytes   secs.    per sec  

212992 212992 1        1       10.00    19248.45  
212992 212992

[indepe]

Transaction rate > 19,000 per sec? That is so much better than both previous results that one has to ask: what is going on there?

[indepe]

Unexpectedly, one of the computers in my local network responds to ping requests (UDP). The time I get with Fedora 25 is 0.4 ms, which I guess corresponds to a transaction rate of roughly 2,500 / sec, somewhere midway between your 19,000 / sec and Michael's ~150 / sec on F25. These differences are enormous.

(EDIT: Fedora 25 Workstation, that is.)