| Richard Eich 2006-12-03, 7:20 pm |
| > > > > > > Would another explanation for the lack of retransmissions in the dump[vbcol=seagreen]
Disabling sack/dsack/fack HAS NOT permanently cleared up the original
symptoms as it initially appeared to do. Much to my dismay, we're
still seeing the SEND-Q build up and heavy retransmissions once
traffic reaches some unknown threshold level. There's been
improvement (the threshold seems to be higher) but no fix.
tcp_wmem on the senders are 4096 65536 16777216. I haven't placed
into production the code updates that "might" give me the write
buffer utilization -- I had to define SIOCOUTQ (0x544) even on
including <sys/ioctl.h>, and I haven't had a chance to test it yet so
I don't know if it really works.
The receiver is getting about 16-20 Mbit/sec, and while its tcp_rmem
settings are 4096 87380 174760 its receive window never drops below
30K.
It seems like the receiver is keeping up with its input, if barely,
or I'd expect to see the receive window hit 0.
I'm trying to predict what impact increasing the receive window size
would have on this behavior. I'm about ready to start sacrificing
chickens, or at least sharpening up my barista skills in the event I
continue to be unable to resolve this.
Collisions are as high as 10%, which I understand is the borderline
value for congestion. Maybe it's just "the network", although I
thought I'd hear myself resort to mere handwaving.
|