chandu valesh wrote: > Hi James Carlson & all, > > James Carlson writes: > > Yes; the IPPROTO_TCP, TCP_NODELAY socket option can be used to change >> the way TCP deals with small writes from the application. > Are there any other parameters that will control/affect the Nagles > algorithm apart form TCP_NODELAY? i.e
The TCP ndd parameter tcp_naglim_def. > 1) Till when TCP buffers data ? does it buffer till the application > data accumulates to fit into a segment? A packet will be sent when the data accumulates to the max segment size (MSS) of the connection or tcp_naglim_def (default 4095), whichever is reached first. > 2) is there any timer till when the buffering will happen (if the data > is not fit into a segmet) and later sent on wire? If another packet needs to be sent - such as an ACK - TCP will send whatever data is currently available. ACKS might be deferred from 50ms to 100ms depending on whether the destination is on a local subnet (tcp_local_dack_interval, default 50ms) or "remote" (tcp_deferred_ack_interval, default 100ms). As James noted, adjusting these parameters just to make small payload packets be sent sooner is generally not a good approach - it increases packet count and decreases efficiency, perhaps seriously if any packet loss occurs. Better to have the app write data in larger chunks, if possible. - Neil > > > Best regards, > Chandu > > On Tue, Oct 21, 2008 at 6:01 PM, James Carlson <[EMAIL PROTECTED]> wrote: >> chandu valesh writes: >>> some where in the TCP layer). Now the previous response and the new >>> application data are sent in the same segment of the TCP. This is not >>> happening every time, but happening some times. Are there any parameters >>> that will effect this behavior ( buffering of the application data etc)? >> Yes; the IPPROTO_TCP, TCP_NODELAY socket option can be used to change >> the way TCP deals with small writes from the application. >> >> Several words of caution, though: >> >> - TCP is a byte-stream protocol. It doesn't respect any application >> "record" boundaries other than individual bytes, it's not required >> to do so, and can't be made to do that. If you need a record- >> oriented protocol on IP, then pick among: >> >> + SCTP >> + UDP with your own error control >> + TCP with your own record-marking on top >> >> - Setting the TCP_NODELAY option turns off part of TCP's congestion >> control mechanism and can result in far more packets on the wire. >> It's likely not to be the right answer here. >> >> - This is a well-known issue. Google for it. >> >>> the application in the receiver responds to the request immediately, but it >>> is delayed and sent later along with the other messages in the packet whose >>> No is 4985. >>> >>> where could be the problem? >> I don't see a problem here; it looks like normal TCP delayed ack >> behavior to me -- other than that the peer is sniping away the >> connection for no apparent reason. >> >> (Isn't Diameter typically implemented on top of SCTP ... ?) >> >> -- >> James Carlson, Solaris Networking <[EMAIL PROTECTED]> >> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 >> MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 > > > > -- > Chandu Valesh > _______________________________________________ > networking-discuss mailing list > [email protected] -- Neil Putnam Systems Technology Service Center / Network Performance Vteam Sun Microsystems, Inc. +1 303 464-4648 / x50648 _______________________________________________ networking-discuss mailing list [email protected]
