- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: if delayed ACK speeds things up, it suggests t...
Operating System - OpenVMS
1753730
Members
4736
Online
108799
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-23-2005 04:59 AM
тАО06-23-2005 04:59 AM
if delayed ACK speeds things up, it suggests the app was broken
this is a new post because the old post about presumed speed-up from disabling delayed ACK got closed.
if disabling delayed ACKs speeds-up an application, it suggests that application is actually broken and not presenting logically associated data to the transport in a single call.
for example, an application that does:
write app header
write app data
read remote response
is "broken" because app header and data shoudl be written to the transport at the same time. In that way, it will have no issue with Nagle and then no issue with interaction of Nagle with delayed ACK.
disabling delayed ACK may speed-up such a broken application, but it means more ACKs and in broad handwaving terms, it takes just as much CPU to process an ACK as it does a data segment.
so, what _should_ be a two packet exchange on the network - app request followed by app response becomes a five or six packet exchange:
-> app header
<- immediate ACK
-> app data
<- immediate ACK
<- app response
-> immediate ACK
(assumes delayed ACK is disabled at both ends - if the application is broken on one direction, it is probably broken in the other
while this six (perhaps 8 even if response is header and then data) may take less clock time than the four-packet delayed ACK version:
-> app header
<- delayed ACK
-> app data
<- remote response
it will take much more CPU, particularly when compared with the properly writen version of the application
if disabling delayed ACKs speeds-up an application, it suggests that application is actually broken and not presenting logically associated data to the transport in a single call.
for example, an application that does:
write app header
write app data
read remote response
is "broken" because app header and data shoudl be written to the transport at the same time. In that way, it will have no issue with Nagle and then no issue with interaction of Nagle with delayed ACK.
disabling delayed ACK may speed-up such a broken application, but it means more ACKs and in broad handwaving terms, it takes just as much CPU to process an ACK as it does a data segment.
so, what _should_ be a two packet exchange on the network - app request followed by app response becomes a five or six packet exchange:
-> app header
<- immediate ACK
-> app data
<- immediate ACK
<- app response
-> immediate ACK
(assumes delayed ACK is disabled at both ends - if the application is broken on one direction, it is probably broken in the other
while this six (perhaps 8 even if response is header and then data) may take less clock time than the four-packet delayed ACK version:
-> app header
<- delayed ACK
-> app data
<- remote response
it will take much more CPU, particularly when compared with the properly writen version of the application
there is no rest for the wicked yet the virtuous have no pillows
2 REPLIES 2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-23-2005 07:01 AM
тАО06-23-2005 07:01 AM
Re: if delayed ACK speeds things up, it suggests the app was broken
two examples of applications that are speeded up by this are samba V2.x and Pathworks (V5, V6)
____________________
Purely Personal Opinion
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-23-2005 07:36 AM
тАО06-23-2005 07:36 AM
Re: if delayed ACK speeds things up, it suggests the app was broken
packet traces would be interesting to see.
having pontificated earlier, I will add that for some applications, which are already sending logically associated data into the transport with a single send, they still need to disable the Nagle algorithm - because they have a stream of sub-MSS messages that need to be sent. however, even in that case, it should be setting TCP_NODELAY on the sending socket, rather than disabling delayed ACK on the receiver.
having pontificated earlier, I will add that for some applications, which are already sending logically associated data into the transport with a single send, they still need to disable the Nagle algorithm - because they have a stream of sub-MSS messages that need to be sent. however, even in that case, it should be setting TCP_NODELAY on the sending socket, rather than disabling delayed ACK on the receiver.
there is no rest for the wicked yet the virtuous have no pillows
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP