 |
| 2 users recommended this comment. What they said: |
|
scott_s Jan 8, 2019 | on: Ask HN: What is your favorite HN post? | context
Some of my actually favorited posts: jjoonathan on Oct 6, 2014 on: Glut of postdoc researchers stirs quiet crisis in ... https://news.ycombinator.com/item?id=8416875, "For most people it's not, but some people subscribe to the notion that choice implies consent/endorsement/approval ..." scardine 12 months ago on: Ask HN: My company plans an ICO despite my opposit... https://news.ycombinator.com/item?id=16126082, "Like almost all problems in life you have only 4 options: ..." graycat on Mar 28, 2015 on: The FedEx Problem https://news.ycombinator.com/item?id=9282104, "Yes, at FedEx, we considered that problem for about three seconds before we noticed that we also needed: ..." Animats on Nov 21, 2015 on: How a little bit of TCP knowledge is essential https://news.ycombinator.com/item?id=10608356, "That still irks me. The real problem is not tinygram prevention. It's ACK delays, and that stupid fixed timer. ..." |
|
gioele Dec 5, 2016 | on: Tell HN: Political Detox Week – No politics on HN for one… | context
> I find this experiment a bit strange/disturbing, avoiding political subjects is a way of putting the head in the sand. I wonder why it is called an experiment at all. In the end this just the mods upholding the part of HN guidelines [1] that I like the most: The problem with having stories and comments about mundane politics is also that they bury the technically interesting comments and they make stories on the the front page go away quicker. There are plenty of other sites where one can discuss about politics. Only on HN can one discuss, for example, with Animats (John Nagle) about the shortcomings and the history of the Nagle's algorithm [2,3] or getting lessons of public speaking from patio11 [4]. Mundane politic topics interfere with HN being the exception place it is. [1] https://news.ycombinator.com/newsguidelines.html [2] https://news.ycombinator.com/item?id=9050645 [3] https://news.ycombinator.com/item?id=10608356 [4] https://news.ycombinator.com/item?id=6199544 |
| Also recommended by people who recommended this: | ||
| 1. | Polyphasic Sleep: One Man's 6-Month Experiment (2005) (stevepavlina.com) | |
| recommended by 1 user | 2009 | 60 points by thinkzig | original thread | | ||
| 2. | Zuckerberg accused of securities fraud (venturebeat.com) | |
| recommended by 1 user | 2010 | 201 points by bjonathan | original thread | | ||
| 3. | Facebook says it owns rights to the name 'book' (chicagobreakingbusiness.com) | |
| recommended by 1 user | 2010 | 21 points by blahedo | original thread | | ||
| 4. | Let’s Build a Compiler (1995) (compilers.iecc.com) | |
| recommended by 3 users | 2010 | 196 points by aycangulez | original thread | | ||
| 5. | Why do pilots still die from not knowing which end is up? (airspacemag.com) | |
| recommended by 1 user | 2011 | 83 points by sajid | original thread | | ||
| 6. | "Lighten up" (therealkatie.net) | |
| recommended by 2 users | 2012 | 1371 points by jnoller | original thread | | ||
That still irks me. The real problem is not tinygram prevention. It's ACK delays, and that stupid fixed timer. They both went into TCP around the same time, but independently. I did tinygram prevention (the Nagle algorithm) and Berkeley did delayed ACKs, both in the early 1980s. The combination of the two is awful. Unfortunately by the time I found about delayed ACKs, I had changed jobs, was out of networking, and doing a product for Autodesk on non-networked PCs.
Delayed ACKs are a win only in certain circumstances - mostly character echo for Telnet. (When Berkeley installed delayed ACKs, they were doing a lot of Telnet from terminal concentrators in student terminal rooms to host VAX machines doing the work. For that particular situation, it made sense.) The delayed ACK timer is scaled to expected human response time. A delayed ACK is a bet that the other end will reply to what you just sent almost immediately. Except for some RPC protocols, this is unlikely. So the ACK delay mechanism loses the bet, over and over, delaying the ACK, waiting for a packet on which the ACK can be piggybacked, not getting it, and then sending the ACK, delayed. There's nothing in TCP to automatically turn this off. However, Linux (and I think Windows) now have a TCP_QUICKACK socket option. Turn that on unless you have a very unusual application.
Turning on TCP_NODELAY has similar effects, but can make throughput worse for small writes. If you write a loop which sends just a few bytes (worst case, one byte) to a socket with "write()", and the Nagle algorithm is disabled with TCP_NODELAY, each write becomes one IP packet. This increases traffic by a factor of 40, with IP and TCP headers for each payload. Tinygram prevention won't let you send a second packet if you have one in flight, unless you have enough data to fill the maximum sized packet. It accumulates bytes for one round trip time, then sends everything in the queue. That's almost always what you want. If you have TCP_NODELAY set, you need to be much more aware of buffering and flushing issues.
None of this matters for bulk one-way transfers, which is most HTTP today. (I've never looked at the impact of this on the SSL handshake, where it might matter.)
Short version: set TCP_QUICKACK. If you find a case where that makes things worse, let me know.
John Nagle