Messages in this thread | | | Date | Tue, 24 Mar 1998 08:24:38 -0500 (EST) | From | "Richard B. Johnson" <> | Subject | Re: `tcpdump` host-host |
| |
On Mon, 23 Mar 1998, David S. Miller wrote:
> > I checked out these dumps, and here is what I see. I am assuming that > 204.178.40.143 is your Sun box, and 204.178.40.224 is the Linux-2.1.90 > machine, am I correct? > Yes correct.
> Anyways, I think the bug is in the TCP code running on the Sun, here > is an example snippet:
[SNIPPED]
> > I'm sorry, that shows complete bogus data packaging being done by the > BSD networking running on the Sun (I assume it's running SunOS, the > data length behavior is very consistant with that of 4.3 BSD stacks). > And there are even worse segments: >
You may be correct. But the new Linux ACK policy may tend to bring out this condition on Suns.
I think that a resonant condition occurs which aggrevates this condition. Suns-to-Suns do not have this problem. The transmission-length settles down into a 1500 byte MTU with 1460 data bytes very quickly.
It is possible that changing the response time for the "next" ACK may dampen this condition. As I see it, if a packet has not been received for some period of time, the ACK to this packet should not be delayed. For lack of a better name, I'll call this the "keystroke" condition.
If, however, packets continue to arrive, i.e., continuous data-flow, then the ACK should be delayed so that two packets can be ACKed at the same time. But, if there are "missing" time-slots at which packets are not received as "expected", there should be some way to prevent immediately bouncing back to "keystroke" packet condition. Perhaps, still another timer?
> Bleech... In contrast look at how Linux boxes queue things in the same > situation: [SNIPPED]
I know. This looks wonderful.
> > Later on the timing jitters a bit, and we begin to queue smaller > frames, but we do act consistantly nonetheless, here's a snippet of > this behavior: > > 204.178.40.236.19 > 204.178.40.224.1118: P 59718:60458(740) ack 1 win 31856 <nop,nop,timestamp 5148732 6063799> (DF) (ttl 64, id 31965) > 204.178.40.236.19 > 204.178.40.224.1118: P 60458:61198(740) ack 1 win 31856 <nop,nop,timestamp 5148732 6063799> (DF) (ttl 64, id 31966) > 204.178.40.236.19 > 204.178.40.224.1118: P 61198:61938(740) ack 1 win 31856 <nop,nop,timestamp 5148732 6063799> (DF) (ttl 64, id 31967) > 204.178.40.236.19 > 204.178.40.224.1118: P 61938:62678(740) ack 1 win 31856 <nop,nop,timestamp 5148732 6063799> (DF) (ttl 64, id 31968) > 204.178.40.224.1118 > 204.178.40.236.19: . ack 62678 win 28960 <nop,nop,timestamp 6063801 5148732> (DF) (ttl 64, id 35045) > > It's a side effect of the speed of the ACK'ing clock coming back to > the sender, and how quickly the process does it's writes. Essentially > the congestion window has opened up wide enough that the sending TCP > can put the packets onto the wire before the process can sneak in and > and do another write. If the process gets there early enough, we can > take his short write onto the end of a packet which still has not gone > out. This _is_ happening above, which is why the data gets clumped > into nice 1436 byte at a time packets. > > There is a little comment in tcp_do_sendmsg() which mentions that we > perhaps might want to come up with a heuristic which sometimes > intelligently holds back the sends a little to allow the full > collapsing of data to occur (ie. long enough for the process to do > a few more tiny writes).
> Anyways, at this point I say it's a SunOS bug... if it's going to > package the writes into packets of that size, there isn't much our > ACKing policy as a receiver can do to alleviate the situation.
> (BTW: For the SunOS-->Linux dumps, where did you do the sniffing, on > the Linux machine, on the SunOS one, or on some other host? If on > some other host where was it in relation to the two machines doing > the transfer?)
The shiffing was none on a Linux 1.1.90 machine, not involved in any network transactions. This is why I mentioned on my first response that I had to go to my work site to get you the data you needed.
Cheers, Dick Johnson ***** FILE SYSTEM MODIFIED ***** Penguin : Linux version 2.1.90 on an i586 machine (66.15 BogoMips). Warning : It's hard to remain at the trailing edge of technology.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |