Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux network performance parameters

github.com

Post reply on HN
Print view View original

21–30 of 117 posts

Re: Linux network performance parameters

#21

Post by jeffbee »

doctorpangloss wrote: post #16

Does performance tuning for Wi-Fi adapters matter? On desktops, other than disabling features, can anything fix the problems with i210 and i225 ethernet? Those seem to be the two most common NICs nowadays. I don't really understand why common networking hardware and drivers are so flawed. There is a lot of attention paid to RISC-V. How about start with a fully open and correct NIC? They'll shove it in there if it's c…

i225 is just broken but I get excellent performance from i210. 1gb is hardly challenging on a contemporaneous CPU, and the i210 offers 4 queues. What's your beef with i210?

Re: Linux network performance parameters

#22

Post by [deleted] »

dijit wrote: post #18
Thaxll wrote: post #17

Earlier quoted context omitted.

I know they bypass the kernel but my point still stands, most of the servers on the internet runs on Linux, that's a fact, so there was more money, time invested, man power on that OS than any others.

Your point is that popularity means that it will improve. This is true, to a point. Counterpoint: Windows Desktop Experience. EDIT: that comment was glib, let me do a proper counterpoint. Common area's are some of the most least maintained in reality; I can think of meet-me-rooms or central fibre hubs in major cities; they are expensive and subject to a lot of the whims of the major provider. Crucially, despite large…

[deleted]

Re: Linux network performance parameters

#23

Post by Thaxll »

dijit wrote: post #18
Thaxll wrote: post #17

Earlier quoted context omitted.

I know they bypass the kernel but my point still stands, most of the servers on the internet runs on Linux, that's a fact, so there was more money, time invested, man power on that OS than any others.

Your point is that popularity means that it will improve. This is true, to a point. Counterpoint: Windows Desktop Experience. EDIT: that comment was glib, let me do a proper counterpoint. Common area's are some of the most least maintained in reality; I can think of meet-me-rooms or central fibre hubs in major cities; they are expensive and subject to a lot of the whims of the major provider. Crucially, despite large…

Yes things improve where we're talking about multi billions $ of infra cost.

Linux is not your "random on the side" feature that is good enough.

Re: Linux network performance parameters

#24

Post by sophacles »

jeffbee wrote: post #13
corbet wrote: post #12

Earlier quoted context omitted.

That's funny ... the "big guys" are some of the biggest contributors to the Linux network stack, almost as if they were actually using it and cared about how well it works.

History has shown that tons of Linux networking scalability and performance contributions have been rejected by the gatekeepers/maintainers. The upstream kernel remains unsuitable for datacenter use, and all the major operators bypass or patch it.

All the major operators sometimes bypass or patch it for some use cases. For others they use it as is. For other still they laugh at you for taking the type of drugs that makes one think any CPU is sufficient to handle networking in code.

Networking isn't a one size fits all thing - different networks have different needs, and different systems in any network will have different needs.

Userland networking is great until you start needing to deal with weird flows or unexpected traffic - then you end up either needing something a bit more robust and your performance starts dropping because you added a bunch of branches to your code or switched over to a kernel implementation that handles those cases. I've seen a few cases of userland networking being slower than just doing the kernel - and being kept because sometimes the what you care about is control over packet lifecycle more than raw throughput.

Kernels prioritize robust network stacks that can handle a lot of cases good enough. Different implementations handle different scenarios better - there's plenty of very high performance networking done with vanilla linux and vanilla freebsd.

Re: Linux network performance parameters

#25

Post by circularfoyers »

sophacles wrote: post #20
mikece wrote: post #4

[flagged]

Performance parity on which axis? For which use case? Talking generally about "network performance" is approximately as useful as talking generally about "engine performance". Just like it makes no sense to compare a weed-eater engine to a locomotive diesel without talking about use case and desired outcomes, it makes no sense to compare "performance of FreeBSD network stack" and "Linux network stack" without underst…

Can you provide some examples of different contexts where Linux or FreeBSD might be better or worse choices?

Re: Linux network performance parameters

#26

Post by dijit »

Thaxll wrote: post #23
dijit wrote: post #18

Earlier quoted context omitted.

Your point is that popularity means that it will improve. This is true, to a point. Counterpoint: Windows Desktop Experience. EDIT: that comment was glib, let me do a proper counterpoint. Common area's are some of the most least maintained in reality; I can think of meet-me-rooms or central fibre hubs in major cities; they are expensive and subject to a lot of the whims of the major provider. Crucially, despite large…

Yes things improve where we're talking about multi billions $ of infra cost. Linux is not your "random on the side" feature that is good enough.

To start with: it's not that much infra cost.

Especially since you don't even know what you're attempting to optimise for.

Latency? p99 of linux is fine, nobody is going to care that the request took 300μs longer. Even in aggregate across a huge fleet of machines waiting an extra 3ms is totally, totally fine.

Throughput? you'll bottleneck on something else most likely anyway, getting a storage array to hydrate at line rate for 100GBPs is difficult and anyway you want to do authentication and distribution of chunks and metadata operations anyway? right?

You're forgetting that it's likely an additional cost of a couple million dollars per year in absolute hardware to solve that issue with throughput, which is, in TCO terms, a couple of developers.

Engineering effort to replace the foundation of an OS? Probably an order of magnitude more. Definitely contains a significant amount more risk, and the potential risk of political backlash for upheaving some other companies workflow that is weird.

Hardware isn't so expensive really.

Of course, you could just bypass the kernel with much less effort and avoid all of this shit entirely.

Re: Linux network performance parameters

#27

Post by [deleted] »

dijit wrote: post #14
Thaxll wrote: post #5

Earlier quoted context omitted.

This is kind of an urban legend, do you think the multi millions servers from Google, Amazon etc... have those performance issues?

This is "appeal to authority" fallacy incarnate. Google/Amazon "etc;" are likely happy to pay the cost because it really is "good enough" and the benefits of Linux over FreeBSD are otherwise quite considerable. Google in particular seems blissfully happy to literally throw hardware at problems; since hardware is (for them especially) fundamentally extremely cheap. Even multiple percentage gains in throughput are not…

[deleted]

Re: Linux network performance parameters

#28

Post by eddtests »

jeffbee wrote: post #13
corbet wrote: post #12

Earlier quoted context omitted.

That's funny ... the "big guys" are some of the biggest contributors to the Linux network stack, almost as if they were actually using it and cared about how well it works.

History has shown that tons of Linux networking scalability and performance contributions have been rejected by the gatekeepers/maintainers. The upstream kernel remains unsuitable for datacenter use, and all the major operators bypass or patch it.

Do you have links on this? I’ve not heard anything about it

Re: Linux network performance parameters

#29

Post by tptacek »

jeffbee wrote: post #11
Thaxll wrote: post #5

Earlier quoted context omitted.

This is kind of an urban legend, do you think the multi millions servers from Google, Amazon etc... have those performance issues?

The big guys don't have the patience to wait for Linux kernel networking to be fast and scalable. They bypass the kernel and take over the hardware. https://blog.acolyer.org/2019/11/11/snap-networking/

Over the course of several years, the architecture underpinning Snap has been used in production for multiple networking applications, including network virtualization for cloud VMs [19], packet-processing for Internet peering [62], scalable load balancing [22], and Pony Express, a reliable transport and communications stack that is our focus for the remainder of this paper.

This paper suggests, as I would have expected, that Google uses userland networking in strategic spots where low-level network development is important (SDNs and routing), and not for normal applications.

Re: Linux network performance parameters

#30

Post by tptacek »

dijit wrote: post #14
Thaxll wrote: post #5

Earlier quoted context omitted.

This is kind of an urban legend, do you think the multi millions servers from Google, Amazon etc... have those performance issues?

This is "appeal to authority" fallacy incarnate. Google/Amazon "etc;" are likely happy to pay the cost because it really is "good enough" and the benefits of Linux over FreeBSD are otherwise quite considerable. Google in particular seems blissfully happy to literally throw hardware at problems; since hardware is (for them especially) fundamentally extremely cheap. Even multiple percentage gains in throughput are not…

Do you know for a fact that Google primarily uses userland networking, or does that just seem accurate to you?
Post reply on HN