Re: 8159 bytes takes 20 ms, 8160 bytes takes 200 ms?

From: Arkady Frenkel (arkadyf_at_hotmailxdotxcom)
Date: 10/13/04


Date: Wed, 13 Oct 2004 10:20:34 +0200

Nagle always with us :) , look for Nagle algorithm in TCP
Arkady

"Itjalve" <itjalve@hotmail.com.(donotspam)> wrote in message
news:2E997F61-BFFA-49E0-B0DE-5876E692943C@microsoft.com...
> Win2k communicating with an embedded system via a point-to-point link
using
> tcp winsock. 8159 bytes (7 fragments) takes about 20 milli seconds, 8160
> bytes (8 fragments) takes about 200 milli seconds.
>
> Its looks like that win2k waits about 150 ms before ack the last, 8,
> fragment. Is this a win2k problem or is it my application that is slow?
>
> I have checked my code for delays, but I can't find any problems there,
i'm
> waiting for packets and the cpu load is less than 10%.
>
> //
> this is what etheral shows, a packet with ack and push flag set, and win2k
> (192.168.125.2) waits 0.15s before sending the ack
> //
>
> No. Time Source Destination Protocol
Info
> 47727 36.458361 192.168.125.1 192.168.125.2 TCP
> 5515 > 2179 [PSH, ACK] Seq=2400562144 Ack=2286139454 Win=8192 Len=304
>
> Frame 47727 (358 bytes on wire, 358 bytes captured)
> Arrival Time: Oct 13, 2004 08:13:02.001731000
> Time delta from previous packet: 0.000535000 seconds
> Time since reference or first frame: 36.458361000 seconds
> Frame Number: 47727
> Packet Length: 358 bytes
> Capture Length: 358 bytes
> Ethernet II, Src: 00:00:23:08:80:33, Dst: 00:04:76:22:89:fe
> Destination: 00:04:76:22:89:fe (00:04:76:22:89:fe)
> Source: 00:00:23:08:80:33 (00:00:23:08:80:33)
> Type: IP (0x0800)
> Internet Protocol, Src Addr: 192.168.125.1 (192.168.125.1), Dst Addr:
> 192.168.125.2 (192.168.125.2)
> Version: 4
> Header length: 20 bytes
> Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
> 0000 00.. = Differentiated Services Codepoint: Default (0x00)
> .... ..0. = ECN-Capable Transport (ECT): 0
> .... ...0 = ECN-CE: 0
> Total Length: 344
> Identification: 0x2384 (9092)
> Flags: 0x04 (Don't Fragment)
> 0... = Reserved bit: Not set
> .1.. = Don't fragment: Set
> ..0. = More fragments: Not set
> Fragment offset: 0
> Time to live: 64
> Protocol: TCP (0x06)
> Header checksum: 0x9ac7 (correct)
> Source: 192.168.125.1 (192.168.125.1)
> Destination: 192.168.125.2 (192.168.125.2)
> Transmission Control Protocol, Src Port: 5515 (5515), Dst Port: 2179
(2179),
> Seq: 2400562144, Ack: 2286139454, Len: 304
> Source port: 5515 (5515)
> Destination port: 2179 (2179)
> Sequence number: 2400562144
> Next sequence number: 2400562448
> Acknowledgement number: 2286139454
> Header length: 20 bytes
> Flags: 0x0018 (PSH, ACK)
> 0... .... = Congestion Window Reduced (CWR): Not set
> .0.. .... = ECN-Echo: Not set
> ..0. .... = Urgent: Not set
> ...1 .... = Acknowledgment: Set
> .... 1... = Push: Set
> .... .0.. = Reset: Not set
> .... ..0. = Syn: Not set
> .... ...0 = Fin: Not set
> Window size: 8192
> Checksum: 0x91d9 (correct)
> Data (304 bytes)
>
>
> No. Time Source Destination Protocol
Info
> 47728 36.609320 192.168.125.2 192.168.125.1 TCP
> 2179 > 5515 [ACK] Seq=2286139454 Ack=2400562448 Win=17216 [CHECKSUM
> INCORRECT] Len=0
>
> Frame 47728 (54 bytes on wire, 54 bytes captured)
> Arrival Time: Oct 13, 2004 08:13:02.152690000
> Time delta from previous packet: 0.150959000 seconds
> Time since reference or first frame: 36.609320000 seconds
> Frame Number: 47728
> Packet Length: 54 bytes
> Capture Length: 54 bytes
> Ethernet II, Src: 00:04:76:22:89:fe, Dst: 00:00:23:08:80:33
> Destination: 00:00:23:08:80:33 (00:00:23:08:80:33)
> Source: 00:04:76:22:89:fe (00:04:76:22:89:fe)
> Type: IP (0x0800)
> Internet Protocol, Src Addr: 192.168.125.2 (192.168.125.2), Dst Addr:
> 192.168.125.1 (192.168.125.1)
> Version: 4
> Header length: 20 bytes
> Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
> 0000 00.. = Differentiated Services Codepoint: Default (0x00)
> .... ..0. = ECN-Capable Transport (ECT): 0
> .... ...0 = ECN-CE: 0
> Total Length: 40
> Identification: 0xf909 (63753)
> Flags: 0x04 (Don't Fragment)
> 0... = Reserved bit: Not set
> .1.. = Don't fragment: Set
> ..0. = More fragments: Not set
> Fragment offset: 0
> Time to live: 128
> Protocol: TCP (0x06)
> Header checksum: 0x0000 (incorrect, should be 0x8671)
> Source: 192.168.125.2 (192.168.125.2)
> Destination: 192.168.125.1 (192.168.125.1)
> Transmission Control Protocol, Src Port: 2179 (2179), Dst Port: 5515
(5515),
> Seq: 2286139454, Ack: 2400562448, Len: 0
> Source port: 2179 (2179)
> Destination port: 5515 (5515)
> Sequence number: 2286139454
> Acknowledgement number: 2400562448
> Header length: 20 bytes
> Flags: 0x0010 (ACK)
> 0... .... = Congestion Window Reduced (CWR): Not set
> .0.. .... = ECN-Echo: Not set
> ..0. .... = Urgent: Not set
> ...1 .... = Acknowledgment: Set
> .... 0... = Push: Not set
> .... .0.. = Reset: Not set
> .... ..0. = Syn: Not set
> .... ...0 = Fin: Not set
> Window size: 17216
> Checksum: 0x7b6f (incorrect, should be 0x5689)
>
>
>
>
>
>
>
>



Relevant Pages

  • Re: dx upgrade - unexpected network connection
    ... > Ethernet II (Packet Length: ... > Internet Protocol ... = Don't fragment: Set ... > Header checksum: 0xa61c ...
    (microsoft.public.security)
  • RE: First TCP packet
    ... The TCP datagram travels inside an IP packet, ... to B should be the TTL on the IP Header. ... might change depending of devices on the path ...
    (Pen-Test)
  • Re: sshd hangs after SSH2_MSG_KEXINIT sent - Fedora Core 5 update
    ... For each network interface on both client and server set the MTU to 576, ... Only the first fragment has TCP port numbers. ... such devices should perform packet reassembly first so as to properly consider fragmented packets. ...
    (SSH)
  • Re: OID_TCP_TASK_OFFLOAD question
    ... Well, right, TCP packets will not fragment at sender because there is no ... you just send up to the MTU limit. ... a TCP segment usually fits in a single network packet at the ...
    (microsoft.public.development.device.drivers)
  • Re: Sockets: How to force recv of unknown data size (all data)
    ... >>this mean the packet gets splitted into two sends? ... TCP will typically fragment in MSS-sized packets ... >to opinions held by my employer, ...
    (comp.unix.programmer)