3 ms·
It delays one RTT, so if you have seen seconds of delays that means your TCP ACK packages were received seconds later for whatever reason (high load?). Decreasi
by littlecranky67 10mo ago
It delays one RTT, so if you have seen seconds of delays that means your TCP ACK packages were received seconds later for whatever reason (high load?). Decreasing latency in that situation would WORSEN the situation.
- CamperBob2 10mo agoMaybe, maybe not, whatever. I was testing some low-bandwidth voice chat code using two unloaded PCs sitting on the same desk. I nearly jumped out of my skin when "HELLO, HELLO?" came through a few seconds late, at high volume, after I had already concluded it wasn't working. After ruling out latency on the audio side, TCP_NODELAY solved the problem. All respect to Animats, but whoever thought this should be the default behavior of TCP/IP had rocks in their head, and/or were solving a problem that had a better solution that they just didn't think of at the time.
- littlecranky67 10mo agoWhatever your issue in that setup was, NODELAY had nothing to do with it
- CamperBob2 10mo agoThen why did it stop happening when NODELAY was used?
- littlecranky67 10mo agoHard to say without looking at the complete setup - and probably just a side-effect of the underlying issue. The question is, why did you have such high RTTs? That already points to a different cause. I would even argue that NODELAY for a VoIP solution makes no sense - why are you even using TCP instead of UDP in the first place?