9 ms·
It's Always TCP_NODELAY
- eieio 10mo agoI found this article while debugging some networking delays for a game that I'm working on. It turns out that in my case it wasn't TCP_NODELAY - my backend is written in go, and go sets TCP_NODELAY by default! But I still found the article - and in particular Nagle's acknowledgement of the issues! - to be interesting. There's a discussion from two years ago here: https://news.ycombinator.com/item?id=40310896 https://news.ycombinator.com/item?id=40310896 - but I figured it'd been long enough that others might be interested in giving this a read too.
- miduil 10mo agoThere is also a good write-up [0] by Julia Evans. We ran into this with DICOM storescp, which is a chatty protocol and TCP_NODELAY=1 makes the throughput significantly better. Since DICOM is often used in a LAN, that default just makes it unnecessarily worse. [0]: https://jvns.ca/blog/2015/11/21/why-you-should-understand-a-little-about-tcp/ https://jvns.ca/blog/2015/11/21/why-you-should-understand-a-... [1]: https://news.ycombinator.com/item?id=10607422 https://news.ycombinator.com/item?id=10607422
- eieio 10mo agoOh! Thank you for this! I love Julia’s writing but haven’t read this post.
- TZubiri 10mo agoI wonder how this fix could be implemented without source code access. Suppose an old ct scanner is clogging up the network.
- vbezhenar 10mo agohttps://github.com/sschroe/libnodelay https://github.com/sschroe/libnodelay
- tecleandor 10mo agoOh, DICOM really like to talk back and forth... I guess that nowadays it should be better with all the WEB/REST versions of the protocol.
- sail0rm00n 10mo agoAny details on the game you’ve been working on? I’ve been really enjoying Ebitengine and Golang for game dev so would love to read about what you’ve been up to!
- eieio 10mo agoI've been playing with multiplayer games that run over SSH; right now I'm trying to push the framerate on the games as high as I can, which is what got me thinking about my networking stack. I mostly use go these days for the backend for my multiplayer games, and in this case there's also some good tooling for terminal rendering and SSH stuff in go, so it's a nice choice. (my games are often pretty weird, I understand that "high framerate multiplayer game over SSH" is a not a uhhh good idea, that's the point!)
- dan-robertson 10mo agoTwo things that can have a big impact on SSH throughput are cipher choice and the hardcoded receive buffer size. These are described in the fork https://github.com/rapier1/hpn-ssh https://github.com/rapier1/hpn-ssh Maybe that will be useful for thinking about workarounds or maybe you can just use hpn-ssh.
- eieio 10mo agoah this is great, thanks dan!
- kazinator 10mo ago> The bigger problem is that TCP_QUICKACK doesn’t fix the fundamental problem of the kernel hanging on to data longer than my program wants it to. Well, of course not; it tries to reduce the problem of your kernel hanging on to an ack (or genearting an ack) longer than you would like. That pertains to received data. If the remote end is sending you data, and is paused due to filling its buffers due to not getting an ack from you, it behooves you to send an ack ASAP. The original Berkeley Unix implementation of TCP/IP, I seem to recall, had a single global 500 ms timer for sending out acks. So when your TCP connection received new data eligible for acking, it could be as long as 500 ms before the ack was sent. If we reframe that in modern realities, we can imagine every other delay is negligible, and data is coming at the line rate of a multi gigabit connection, 500 ms represents a lot of unacknowledged bits. Delayed acks are similar to Nagle in spirit in that they promote coalescing at the possible cost of performance. Under the assumption that the TCP connection is bidirectional and "chatty" (so that even when the bulk of the data transfer is happening in one direction, there are application-level messages in the other direction) the delayed ack creates opportunities for the TCP ACK to be piggy backed on a data transfer. A TCP segment carrying no data, only an ACK, is prevented. As far as portability of TCP_QUICKACK goes, in C code it is as simple as #ifdef TCP_QUICKACK. If the constant exists, use it. Otherwise out of luck. If you're in another language, you have to to through some hoops depending on whether the network-related run time exposes nonportable options in a way you can test, or whether you are on your own.
- anonymousiam 10mo agoThe Nagle algorithm was created back in the day of multi-point networking. Multiple hosts were all tied to the same communications (Ethernet) channel, so they would use CSMA (https://en.wikipedia.org/wiki/Carrier-sense_multiple_access_with_collision_detection https://en.wikipedia.org/wiki/Carrier-sense_multiple_access_...) to avoid collisions. CSMA is no longer necessary on Ethernet today because all modern connections are point-to-point with only two "hosts" per channel. (Each host can have any number of "users.") In fact, most modern (copper) (Gigabit+) Ethernet connections have both ends both transmitting and receiving AT THE SAME TIME ON THE SAME WIRES. A hybrid is used on the PHY at each end to subtract what is being transmitted from what is being received. Older (10/100 Base-T) can do the same thing because each end has dedicated TX/RX pairs. Fiber optic Ethernet can use either the same fiber with different wavelengths, or separate TX/RX fibers. I haven't seen a 10Base-2 Ethernet/DECnet interface for more than 25 years. If any are still operating somewhere, they are still using CSMA. CSMA is also still used for digital radio systems (WiFi and others). CSMA includes a "random exponential backoff timer" which does the (poor) job of managing congestion. (More modern congestion control methods exist today.) Back in the day, disabling the random backoff timer was somewhat equivalent to setting TCP_NODELAY. Dumping the Nagle algorithm (by setting TCP_NODELAY) almost always makes sense and should be enabled by default.
- Hikikomori 10mo agoJust to add, ethernet uses csma/cd, WiFi uses csma/ca. Upgraded our DC switches to new ones around 2014 and needed to keep a few old ones because the new ones didn't support 10Mbit half duplex.
- anonymousiam 10mo agoThanks for the clarification. They're so close to being the same thing that I always call it CSMA/CD. Avoiding a collision is far more preferable than just detecting one. Yeah, many enterprise switches don't even support 100Base-T or 10Base-T anymore. I've had to daisy chain an old switch that supports 100Base-T onto a modern one a few times myself. If you drop 10/100 support, you can also drop HD (simplex) support. In my junk drawer, I still have a few old 10/100 hubs (not switches), which are by definition always HD.
- martingxx 10mo agoI've always thought that Nagle's algorithm is putting policy in the kernel where it doesn't really belong. If userspace applications want to make latency/throughput tradeoffs they can already do that with full awareness and control using their own buffers, which will also often mean fewer syscalls too.
- kvemkon 10mo agoThe tradeoff on one program can influence the other program needing perhaps the opposite decision of such tradeoff. Thus we need the arbiter in the kernel to be able to control what is more important for the whole system. So my guess.
- ghshephard 10mo agoIt's kind of in User Space though - right? When an application opens a socket - it decides whether to open it with TCP_NODELAY or not. There isn't any kernel/os setting - it's done on a socket by socket basis, no?
- naught00 10mo agoTCP_NODELAY is implemented within the kernel. A socket can decide whether to use it or not.
- klempner 10mo agoThe actual algorithm (which is pretty sensible in the absence of delayed ack) is fundamentally a feature of the TCP stack, which in most cases lives in the kernel. To implement the direct equivalent in userspace against the sockets API would require an API to find out about unacked data and would be clumsy at best. With that said, I'm pretty sure it is a feature of the TCP stack only because the TCP stack is the layer they were trying to solve this problem at, and it isn't clear at all that "unacked data" is particularly better than a timer -- and of course if you actually do want to implement application layer Nagle directly, delayed acks mean that application level acking is a lot less likely to require an extra packet.
- 10mo ago
- vsgherzi 10mo agohttps://oxide-and-friends.transistor.fm/episodes/mr-nagles-wild-ride https://oxide-and-friends.transistor.fm/episodes/mr-nagles-w... oxide and friends episode on it! It's quite good
- TZubiri 10mo agoVery on brand, oxide's core proposition is to actually invent a new (server) os+hardware, so they question/polish many of the traditional protocols and standards from the golden era.
- jonstewart 10mo ago<waits for animats to show up>
- armitron 10mo agoAssuming he shows up, he'll still probably be trying to defend the indefensible.. Disabling Nagle's algorithm should be done as a matter of principle, there's simply no modern network configuration where it's beneficial.
- e40 10mo agoCame here thinking the same thing...
- Animats 10mo agoOK, I suppose I should say something. I've already written on this before, and that was linked above. You never want TCP_NODELAY off at the sending end, and delayed ACKs on at the receiving end. But there's no way to set that from one end. Hence the problem. Is TCP_NODELAY off still necessary? Try sending one-byte TCP sends in a tight loop and see what it does to other traffic on the same path, for, say, a cellular link. Today's links may be able to tolerate the 40x extra traffic. It was originally put in as a protection device against badly behaved senders. A delayed ACK should be thought of as a bet on the behavior of the listening application. If the listening application usually responds fast, within the ACK delay interval, the delayed ACK is coalesced into the reply and you save a packet. If the listening application does not respond immediately, a delayed ACK has to actually be sent, and nothing was gained by delaying it. It would be useful for TCP implementations to tally, for each socket, the number of delayed ACKs actually sent vs. the number coalesced. If many delayed ACKs are being sent, ACK delay should be turned off, rather than repeating a losing bet. This should have been fixed forty years ago. But I was out of networking by the time this conflict appeared. I worked for an aerospace company, and they wanted to move all networking work from Palo Alto to Colorado Springs, Colorado. Colorado Springs was building a router based on the Zilog Z8000, purely for military applications. That turned out to be a dead end. The other people in networking in Palo Alto went off to form a startup to make a "PC LAN" (a forgotten 1980s concept), and for about six months, they led that industry. I ended up leaving and doing things for Autodesk, which worked out well.
- rowanG077 10mo agoI fondly remember a simple simulation project we had to do with a group of 5 students in a second year class which had a simulation and some kind of scheduler which communicated via TCP. I was appalled at the perfomance we were getting. Even on the same machine it was way too slow for what it was doing. After hours of debugging in turned out it was indeed Nagle's algorithm causing the slowness, which I never heard about at the time. Fixed instantly with TCP_NODELAY. It was one of the first times it was made abundantly clear to me the teachers at that institution didn't know what they were teaching. Apparently we were the only group that had noticed the slow performance, and the teachers had never even heard of TCP_NODELAY.
- saghm 10mo agoI first ran into this years ago after working on a database client library as an intern. Having not heard of this option beforehand, I didn't think to enable it in the connections the library opened, and in practice that often led to messages in the wire protocol being entirely ready for sending without actually getting sent immediately. I only found out about it later when someone using it investigated why the latency was much higher than they expected, and I guess either they had run into this before or were able to figure out that it might be the culprit, and it turned out that pretty much all of the existing clients in other languages set NODELAY unconditionally.
- dllthomas 10mo agoWildly, the Polish word "nagle" (pronounced differently) means "suddenly" or "all at once", which is just astonishingly apropos for what I'm almost certain is pure coincidence.
- sleepy_keita 10mo agoYeah, it's named after the person who wrote the RFC - John Nagle. Wild coincidence! https://datatracker.ietf.org/doc/html/rfc896 https://datatracker.ietf.org/doc/html/rfc896
- pests 10mo agohes on hn as "Animats"
- marton78 10mo agoStrangely, the Polish word seems to encode a superposition of both settings: with NODELAY on, TCP sends messages suddenly, whereas with NODELAY off it sends tiny messages all at once, in one TCP packet.
- Pikamander2 10mo ago
- otterley 10mo ago(2024) - previously discussed at https://news.ycombinator.com/item?id=40310896 https://news.ycombinator.com/item?id=40310896
- x2rj 10mo agoI've always thought a problem with Nagel's algorithm is, that the socket API does not (really) have a function to flush the buffers and send everything out instantly, so you can use that after messages that require a timely answer. For stuff where no answer is required, Nagel's algorithm works very well for me, but many TCP channels are mixed use these days. They send messages that expect a fast answer and other that are more asynchronous (from a users point of view, not a programmers). Wouldn't it be nice if all operating systems, (home-)routers, firewalls and programming languages would have high quality implementations of something like SCTP...
- lysace 10mo agoSomething like sync(2)/syncfs(2) for filesystems. Seems like there's been a disconnect between users and kernel developers here?
- loeg 10mo agoTCP_CORK?
- x2rj 10mo agoSadly linux only (and apparently some BSDs). Would love to have more (and more generalized) tcp socket modes like that.
- derriz 10mo agoYeah, I’ve always felt that the stream API is a leaky abstraction for providing access to networking. I understand the attraction of making network I/O look like local file access given the philosophy of UNIX. The API should have been message oriented from the start. This would avoid having the network stack try to compensate for the behavior of the application layer. Then Nagel’s or something like it would just be a library available for applications that might need it. The stream API is as annoying on the receiving end especially when wrapping (like TLS) is involved. Basically you have to code your layers as if the underlying network is handing you a byte at a time - and the application has to try to figure out where the message boundaries are - adding a great deal of complexity.
- hathawsh 10mo agoHa ha, well that's a relief. I thought the article was going to say that enabling TCP_NODELAY is causing problems in distributed systems. I am one of those people who just turn on TCP_NODELAY and never look back because it solves problems instantly and the downsides seem minimal. Fortunately, the article is on my side. Just enable TCP_NODELAY if you think it's a good idea. It apparently doesn't break anything in general.
- foltik 10mo agoWhy doesn’t linux just add a kconfig that enables TCP_NODELAY system wide? It could be enabled by default on modern distros.
- indigodaddy 10mo agoLooks like there is a sysctl option for BSD/MacOS but Linux it must be done at application level?
- rini17 10mo agoPerhaps you can set up iptables rule to add the bit.
- hsn915 10mo agoWouldn't distributed systems benefit from using UDP instead of TCP?
- 0xbadcafebee 10mo agoOnly if you're sending data you don't mind losing and getting out of order
- neomantra 10mo agoThis is true for simple UDP, but reliable transports are often built over UDP. As with anything in computing, there are trade-offs between the approaches. One example is QUIC now widespread in browsers. MoldUDP64 is used by various exchanges (that's NASDAQ's name, others do something close). It's a simple UDP protocol with sequence numbers; works great on quality networks with well-tuned receivers (or FPGAs). This is an old-school blog article about the earlier MoldUDP: https://www.fragmentationneeded.net/2012/01/dispatches-from-trading-floor-moldudp.html https://www.fragmentationneeded.net/2012/01/dispatches-from-... Another is Aeron.io, which is a high-performance messaging system that includes a reliable unicast/multicast transport. There is so much cool stuff in this project and it is useful to study. I saw this deep-dive into the Aeron reliable multicast protocol live and it is quite good, albeit behind a sign-up. https://aeron.io/other/handling-data-loss-with-aeron/ https://aeron.io/other/handling-data-loss-with-aeron/
- nospice 10mo agoStrictly speaking, you can put any protocol on top of UDP, including a copy of TCP... But I took parent's question as "should I be using UDP sockets instead of TCP sockets". Once you invent your new protocol instead of UDP or on top of it, you can have any features you want.
- wronex 10mo agoThere is also ENet which is used in a lot of games (that is, battle tested for low latency applications.) https://enet.bespin.org https://enet.bespin.org
- deleted 10mo ago[deleted]
- Veserv 10mo agoThe problem is actually that nobody uses the generic solution to these classes of problems and then everybody complains that the special-case for one set of parameters works poorly for a different set of parameters. Nagle’s algorithm is just a special case solution of the generic problem of choosing when and how long to batch. We want to batch because batching usually allows for more efficient batched algorithms, locality, less overhead etc. You do not want to batch because that increases latency, both when collecting enough data to batch and because you need to process the whole batch. One class of solution is “Work or Time”. You batch up to a certain amount of work or up to a certain amount of time, whichever comes first. You choose your amount of time as your desired worst case latency. You choose your amount of work as your efficient batch size (it should be less than max throughput * latency, otherwise you will always hit your timer first). Nagle’s algorithm is “Work” being one packet (~1.5 KB) with “Time” being the time until all data gets a ack (you might already see how this degree of dynamism in your timeout might pose a problem already) which results in the fallback timer of 500 ms when delayed ack is on. It should be obvious that is a terrible set of parameters for modern connections. The problem is that Nagle’s algorithm only deals with the “Work” component, but punts on the “Time” component allowing for nonsense like delayed ack helpfully “configuring” your effective “Time” component to a eternity resulting in “stuck” buffers which is what the timeout is supposed to avoid. I will decline to discuss the other aspect which is choosing when to buffer and how much of which Nagle’s algorithm is again a special case. Delayed ack is, funnily enough, basically the exact same problem but done on the receive side. So both sides set timeouts based on the other side going first which is obviously a recipe for disaster. They both set fixed “Work”, but no fixed “Time” resulting in the situation where both drivers are too polite to go first. What should be done is use the generic solutions that are parameterized by your system and channel properties which holistically solve these problems which would take too long to describe in depth here.
- deleted 10mo ago[deleted]
- buybackoff 10mo agoThen at a lower level and smaller latencies it's often interrupt moderation that must be disabled. Conceptually similar idea to the Nagle algo - coalesce overheads by waiting, but on the receiving end in hardware.
- mmaunder 10mo agoPSA: UDP exists.
- joelthelion 10mo agoWhat happens when you change the default when building a Linux distro? Did anyone try it?
- harikb 10mo agoSomewhat related, from 3 years ago. Unfortunately, original blog is gone. "Golang disables Nagle's Algorithm by default" 1. https://news.ycombinator.com/item?id=34179426 https://news.ycombinator.com/item?id=34179426
- withinboredom 10mo agoYeah. A disk failed, and I had to recreate the blog from whatever was still available via other means.
- wyldfire 10mo agoNagle's algorithm is just a special case of TCP worst case latency. Packet loss and congestion also cause significant latency. If you care about latency, you should consider something datagram oriented like UDP or SCTP.
- mort96 10mo agoWhat if occasional latency is fine, and latency on terrible networks with high packet loss is fine, but you want the happy case to have little latency? Both many (non-competitive) games and SSH falls into this: reliability is more important than achieving the absolute lowest latency possible, but lower latency is still better than higher latency.
- carlsborg 10mo agoUnless you're cross platform on Windows too and then theres also a vast number of random registry settings.
- deleted 10mo ago[deleted]
- rwmj 10mo agoI'm surprised the article didn't also mention MSG_MORE. On Linux it hints to the kernel that "more is to follow" (when sending data on a socket) so it shouldn't send it just yet. Maybe you need to send a header followed by some data. You could copy them into one buffer and use a single sendmsg call, but it's easier to send the header with MSG_MORE and the data in separate calls. (io_uring is another method that helps a lot here, and it can be combined with MSG_MORE or with preallocated buffers shared with the kernel.)
- mgaunard 10mo agoyou can already send fragmented data in one system call without copying it to a single buffer.
- rwmj 10mo agoIndeed you can, but we've found it useful to use MSG_MORE when using state machines, where different states are responsible for different parts of the reply. (Plenty of examples in states*.c here: https://gitlab.com/nbdkit/libnbd/-/tree/master/generator?ref_type=heads https://gitlab.com/nbdkit/libnbd/-/tree/master/generator?ref...)
- mgaunard 10mo agoDoing more system calls isn't really a good idea for performance. Also if you're doing asynchronous writes you typically can only have one write in-flight at any time, you should aggregate all other buffers while that happens. Though arguably asynchronous writes are often undesired due to the complexity of doing flow-control with them.
- mgaunard 10mo agoActually, with newer Linux kernels and io_uring, it appears it is now possible to do multiple writes asynchronously concurrently, by annotating each one with a sequencing constraint. Whether that's really useful or not depends on whether you do the associated buffer management work.
- skrebbel 10mo agoNagle himself says (or said 10y ago) that the real culprit is delayed ACK: https://news.ycombinator.com/item?id=10608356 https://news.ycombinator.com/item?id=10608356 I’m no expert by any means, but this makes sense to me. Plus, I can’t come up with many modern workloads where delayed ACK would result in significant improvement. That said, I feel the same about Nagle’s algorithm - if most packets are big, it seems to me that both features solve problems that hardly exist anymore. Wouldn't the modern http-dominated best practice be to turn both off?
- robinhouston 10mo agoThe article does address that: > Unfortunately, it’s not just delayed ACK2. Even without delayed ack and that stupid fixed timer, the behavior of Nagle’s algorithm probably isn’t what we want in distributed systems. A single in-datacenter RTT is typically around 500μs, then a couple of milliseconds between datacenters in the same region, and up to hundreds of milliseconds going around the globe. Given the vast amount of work a modern server can do in even a few hundred microseconds, delaying sending data for even one RTT isn’t clearly a win.
- mgaunard 10mo agoI've always found Nagle's algorithm being a kernel-level default quite silly. It should be up to the application to decide when to send and when to buffer and defer.
- nlitened 10mo agoIt’s up to the application to change this parameter on per-socket basis
- TZubiri 10mo ago> , suggesting that the default behavior is wrong, and perhaps that the whole concept is outmoded While outmoded might be the case, wrong is probably not the case. There's some features of the network protocols that are designed to improve the network, not the individual connection. It's not novel that you can improve your connection. By disabling "good neighbour" features.
- jurabek 10mo agoTCP_NODELAY enabled by default on most modern languages no?
- TacticalCoder 10mo agoIt's a bit tricky in that browsers may be using TCP_NODELAY anyway or use QUIC (UDP) and whatnots BUT, in doubt, I've got a wrapper script around my browsers launcher script that does LD_PRELOAD with TCP_NODELAY correctly configured. Dunno if it helps but it helps me feel better. What speeds up browsing the most though IMO is running your own DNS resolver, null routing a big part of the Internet, firewalling off entire countries (no really I don't need anything from North Korea, China or Russia for example), and then on top of that running dnsmasq locally. I run the unbound DNS (on a little Pi so it's on 24/7) with gigantic killfiles, then I use 1.1.1.3 on top of that (CloudFlare's DNS that filters out known porn and known malware: yes, it's CloudFlare and, yes, I own shares of NET). Some sites complain I use an "ad blocker" but it's really just null routing a big chunk of the interwebz. That and LD_PRELOAD a lib with TCP_NODELAY: life is fast and good. Very low latency.
- drfignewton 10mo agoI swear, it seems like I’ve seen some variation of this 50 times on HN in the past 15 years. The core issue with Nagle’s algorithm (TCP_NODELAY off) is its interaction with TCP Delayed ACK. Nagle prevents sending small packets if an ACK is outstanding, while the receiver delays that ACK to piggyback it on a response. When both are active, you get a 200ms "deadlock" where the sender waits for an ACK and the receiver waits for more data. This is catastrophic for latency-sensitive applications like gaming, SSH, or high-frequency RPCs. In modern times, the bandwidth saved by Nagle is rarely worth the latency cost. You should almost always set TCP_NODELAY = 1 for any interactive or request-response protocol. The "problem" only shifts to the application layer: if you disable Nagle and then perform many small write() calls (like writing a single byte at a time), you will flood the network with tiny, inefficient packets. Proper usage means disabling Nagle at the socket level but managing your own buffering in user-space. Use a buffered writer to assemble a logical message into a single memory buffer, then send it with one system call. This ensures your data is dispatched immediately without the overhead of thousands of tiny headers. Check the Linux tcp(7) man page for implementation details; it is the definitive reference for these behaviors.
- gwbas1c 10mo ago> Proper usage means disabling Nagle at the socket level but managing your own buffering in user-space. Honestly, if you're writing a (cough) typical webservice that just serializes an object to JSON, you've pretty much done that. Nagle just slows that situation down, and TCP_NODELAY should always be enabled in that situation. (Granted, if you're using newer HTTP (3? SPDY?) you probably aren't even on TCP and don't even need to bother.) It's only when sending large payloads that you might have to think about buffering.
- deleted 10mo ago[deleted]
- jcalvinowens 10mo ago> In modern times, the bandwidth saved by Nagle is rarely worth the latency cost. I actually took some packet dumps and did the math on this once, assuming any >=2 non-mtu-sized segments from the same flow within 10ms could have been combined (pretty conservative imo). The extra bandwidth cost of NODELAY amounted to just over 0.1% of the total AWS bandwidth bill, which, while negligible, was more than I expected.
- bullen 10mo agoWhat we need is configurable ack packet counts. Then we can make TCP become UDP. And then we solved everything. Both linux and Windows have this config but it's buggy so we're back to TCP and UDP.
- zbentley 10mo agoI’m curious about this. Can you share more details or some links that discuss what you’re describing?
- bullen 10mo agoTcpAckFrequency and net.ipv4.tcp_delack_min but they don't do exactly what we need: We need to be able to set it to -1 to tell the OS that no acks should be used at all, effectively turning that socket into UDP but with a TCP API! That way we only have one protocol for ALL internet traffic. I made a RFC about this a decade ago that was ignored.
- medoc 10mo agoAround 1999, I was testing a still young MySQL as an INFORMIX replacement, and network queries needed a very suspect and quite exact 100 mS. A bug report and message to mysql@lists.mysql.com, and this is how MySQL got to set TCP_NODELAY on its network sockets...
- dan-robertson 10mo agoA few random thoughts: 1. Perhaps on more modern hardware the thing to do with badly behaved senders is not ‘hang on to unfull packets for 40ms’ but another policy could still work, e.g. eagerly send the underfilled packet, but wait the amount of time it would take to send a full packet (and prioritize sending other flows) before sending the next underfull packet. 2. In Linux there are packets and then there are (jumbo)packets. The networking stack has some per-packet overhead so much work is done to have it operate on bigger batches and then let the hardware (or a last step in the OS) do segmentation. It’s always been pretty unclear to me how all these packet-oriented things (Nagle’s algorithm, tc, pacing) interact with jumbo packets and the various hardware offload capabilities. 3. This kind of article comes up a lot (mystery 40ms latency -> set TCP_NODELAY). In the past I’ve tried to write little test programs in a high level language to listen on tcp and respond quickly, and in some cases (depending on response size) I’ve seen strange ~40ms latencies despite TCP_NODELAY being set. I didn’t bother looking in huge detail (eg I took a strace and tcpdump but didn’t try to see non-jumbo packets) and failed to debug the cause. I’m still curious what may have caused this?
- alvineh 10mo agoNice