5 ms·
> As another test point, Firefox doesn't even blink at a symmetric gigabit connection going at full speed (my network is capped by my NIC, the pipe is way fatte
by jagrsw 4y ago
> As another test point, Firefox doesn't even blink at a symmetric gigabit connection going at full speed (my network is capped by my NIC, the pipe is way fatter).
FWIW Firefox under Linux (Firefox Browser 100.0.2 (64-bit)) behaves pretty much the same as Chrome. The speed raises quickly to 5-8Gb/s, then the UI starts choking, and the shown speed drops to 500Mb/s. It could be that there's some scheduling limit or other bottleneck hit in the OS itself, assuming these are different codebases (are they?).
- bayindirh 4y agoI'd love to test and debug the path where it dies, but none of the systems we have firefox have pipes that fat (again NIC limited). However, you can test the limits of Linux by installing CLI version of Speedtest and hitting a nearby server. The bottleneck maybe in the browser itself, or in your graphics stack, too. Linux can do pretty amazing things in the network department, otherwise 100Gbps Infiniband cards wouldn't be possible at Linux servers, yet we have them on our systems. And yes, Chrome and Firefox are way different browsers. I can confidently say this, because I'm using Firefox since it's called Netscape 6.0 (and Mozilla in Knoppix).
- bawolff 4y ago> I can confidently say this, because I'm using Firefox since it's called Netscape 6.0 (and Mozilla in Knoppix). Mozilla suite/seamonkey isn't usually considered the same as firefox, although obviously related.
- bayindirh 4y agoI'm not talking about the version which evolved to Seamonkey. I'm talking about Mozilla/Firefox 0.8 which had a Mozilla logo as a "Spinner" instead of Netscape logo on the top right.
- bawolff 4y agoNetscape 6 was not firefox based https://en.m.wikipedia.org/wiki/Netscape_6 https://en.m.wikipedia.org/wiki/Netscape_6 Firefox 0.8 did not have netscape branding http://theseblog.free.fr/firefox-0.8.jpg http://theseblog.free.fr/firefox-0.8.jpg
- bayindirh 4y ago> Netscape 6 was not Firefox based. I know. Firefox was not even an idea when Netscape 6 was released. However, inverse is true. Firefox is based on Netscape. It's just branched off actually. It started as a pared down version of SeaMonkey apparently. The thing I was remembering from Knoppix 3.x days was "Mozilla Navigator" of SeaMonkey/Mozilla Suite, which is even older than Firefox, and discontinued 3 years later. I just booted the CD to look at it. At the end of the day, Firefox is just Netscape Navigator, evolved.
- jeffreygoesto 4y agoFrom my experience long ago, all high performance networking under Linux was traditionally user space and pre-allocated pools (netmap, dpdk, pf-ring...). Did not follow, how much io_uring has been catching up for network stack usage... Maybe somebody else knows?
- bayindirh 4y agoWhile I'm not very knowledgeable in specifics, there are many paths for networking in Linux now. The usual kernel based one is there, also there's kernel-bypass [0] paths used by very high performance cards. Also, Infiniband can directly RDMA to and from MPI processes for making "remote memory local", allowing very low latencies and high performance in HPC environments. I also like this post from Cloudflare [1]. I've read it completely, but the specifics are lost on me since I'm not directly concerned with the network part of our system. [0]: https://medium.com/@penberg/on-kernel-bypass-networking-and-programmable-packet-processing-799609b06898 https://medium.com/@penberg/on-kernel-bypass-networking-and-... [1]: https://blog.cloudflare.com/how-to-receive-a-million-packets/ https://blog.cloudflare.com/how-to-receive-a-million-packets...
- sophacles 4y agoI have a service that beats epoll with io_uring (it reads gre packets from one socket, and does some lookups/munging on the inner packet and re-encaps them to a different mechanism and writes them back to a different socket). General usage for io_uring vs epoll is pretty comparable IIUC. It wouldn't surprise me if streams (e.g. tcp) end up being faster via io_uring and buffer registration though. Totally tangential - it looks like io_uring is evolving beyond just io and into an alternate syscall interface, which is pretty neat imho.