nagling still doesn't work in Windows 10 ?
nagling still doesn't work in Windows 10 ?
It is still not possible to disable nagling in Windows 10? I am interested if anything changed.
You should be able to disable nagling I think, have you tried the TCP Optimizer recently?
There are a few changes with the Windows 10 builds, nothing I recall specifically about nagling though. You can check the TCP Optimizer revision history: https://www.speedguide.net/articles/tcp ... story-5811
There are a few changes with the Windows 10 builds, nothing I recall specifically about nagling though. You can check the TCP Optimizer revision history: https://www.speedguide.net/articles/tcp ... story-5811
Linux is user friendly, it's just picky about its friends...
Disclaimer: Please use caution when opening messages, my grasp on reality may have shaken loose during transmission (going on rusty memory circuits). I also eat whatever crayons are put in front of me.
๑۩۞۩๑
Disclaimer: Please use caution when opening messages, my grasp on reality may have shaken loose during transmission (going on rusty memory circuits). I also eat whatever crayons are put in front of me.
๑۩۞۩๑
The Registry settings still work AFAIK.
Nagle's algorithm introduces a small delay (200ms in most OSes) to ACKnowledgements. In other words, when the stack receives some data, it will wait a bit before sending acknowledgements to reduce the amount of ACKs. It is helpful for general traffic and downloads, not that great for real-time data.
You can try sniffing TCP/IP data and look for ACK packets delays I suppose.
Nagle's algorithm introduces a small delay (200ms in most OSes) to ACKnowledgements. In other words, when the stack receives some data, it will wait a bit before sending acknowledgements to reduce the amount of ACKs. It is helpful for general traffic and downloads, not that great for real-time data.
You can try sniffing TCP/IP data and look for ACK packets delays I suppose.
Linux is user friendly, it's just picky about its friends...
Disclaimer: Please use caution when opening messages, my grasp on reality may have shaken loose during transmission (going on rusty memory circuits). I also eat whatever crayons are put in front of me.
๑۩۞۩๑
Disclaimer: Please use caution when opening messages, my grasp on reality may have shaken loose during transmission (going on rusty memory circuits). I also eat whatever crayons are put in front of me.
๑۩۞۩๑
If i send you screenshot from wireshark, will you be able to tell me if it sends delayed ack. In wireshark forums, someone said, that ack packets with no tcp payload, are probably delayed ack and i have these. I wasn't able to google how to analyze delayed ack, i have no experience with wireshark, if you don't mind you could look at this picture an tell me if i send and get delayed ack.
White fields is me and other game server ip, it has port 1119. And i have disabled nagling in regedit and checked my nic name in ipconfig. I told you it doesn't work on windows 10. Read it on 20 various sites.
https://imgur.com/a/rCpNXhK
White fields is me and other game server ip, it has port 1119. And i have disabled nagling in regedit and checked my nic name in ipconfig. I told you it doesn't work on windows 10. Read it on 20 various sites.
https://imgur.com/a/rCpNXhK
Uhm I don't see any logic in only seeing ACK packets without TCP payload in delayed ACK environment. If anything, you should see more ACK packets when delayed ACKs are disabled.
To detect delayed ACK, you would have to look more closely at the pcap file, or each transfer in Wireshark. You will have to look for 200ms delay of the ACK packet at the end of a transfer segment. You'd have to figure out the exact sequence number of the packet. It is easiest if there is not much traffic on the network, and sending/disecting a single packet. That way you can see if there is a 200ms delay of the ACK for that particular packet. (It may also work with odd number of packets sent, again, look for 200ms delay in the ACK for the last packet of a transfer).
I can't see delayed acks simply from that screenshot, sorry. Again, if you want to detect delayed ACKs, you'd have to look at the last packet in a transfer, preferably with odd number of packets, and see 200ms delay in the ACK for that same packet.
Also, keep in mind that ACKs are cumulative, i.e. they acknowledge receipt of all previous packets in a sequence, not only that particular one.
To detect delayed ACK, you would have to look more closely at the pcap file, or each transfer in Wireshark. You will have to look for 200ms delay of the ACK packet at the end of a transfer segment. You'd have to figure out the exact sequence number of the packet. It is easiest if there is not much traffic on the network, and sending/disecting a single packet. That way you can see if there is a 200ms delay of the ACK for that particular packet. (It may also work with odd number of packets sent, again, look for 200ms delay in the ACK for the last packet of a transfer).
I can't see delayed acks simply from that screenshot, sorry. Again, if you want to detect delayed ACKs, you'd have to look at the last packet in a transfer, preferably with odd number of packets, and see 200ms delay in the ACK for that same packet.
Also, keep in mind that ACKs are cumulative, i.e. they acknowledge receipt of all previous packets in a sequence, not only that particular one.
Linux is user friendly, it's just picky about its friends...
Disclaimer: Please use caution when opening messages, my grasp on reality may have shaken loose during transmission (going on rusty memory circuits). I also eat whatever crayons are put in front of me.
๑۩۞۩๑
Disclaimer: Please use caution when opening messages, my grasp on reality may have shaken loose during transmission (going on rusty memory circuits). I also eat whatever crayons are put in front of me.
๑۩۞۩๑