Re: TCP-Protection is really a pain...

[Christian Schmid <webmaster@rapidforum.com>]

Hm how can I check that? and what do you mean with "board"? Mainboard? NIC? its an onboard-nic on 
this mainboard: http://www.supermicro.com/products/motherboard/Xeon/E7501/X5DP8-G2.cfm

The worst thing is the stalled downloads. It drops to 8-12 kb-sec. sometimes after a few seconds it 
goes up to full speed again, but sometimes it suddenly stops completely. After a few seconds it 
continues with full speed or it stalls forever. send-queue is always full.....

Thank you for your help in this matter.

Chris


Stephen Hemminger wrote:
> On Thu, 03 Feb 2005 06:21:46 +0100
> Christian Schmid <webmaster@rapidforum.com> wrote:
> 
> 
>>Actually, thats my problem. Single streams are too slow! Before I had buffers up to 500 KB. This was 
>>very nice to CPU because I only needed to "push" more data once in 5 seconds. I am doing this every 
>>second now... *sigh* well maybe you might just want to add a /proc file in order to configure this 
>>behaviour.
>>
>>btw: Another problem I am experiencing is that downloads suddenly break in speed from 360 kb/sec to 
>>8-12 kb/sec. 5 seconds later they stall completely. But the interesting part is, that the send-queue 
>>is completely full (checked with a grep in netstat). This looks like as if the receiver is just too 
>>slow. But this is not the case. That makes it rather funny. The receiver is waiting with an empty 
>>pipe but linux doesn't send. What could this be?
>>
> 
> 
> Are you using a board that support TCP Segmentation Offload.  The problem may well be that
> before we were not doing congestion control properly with TSO.  A pre-2.6.8 host with TSO was violating
> all sorts of RFC's and unfairly monopolizing bandwidth.
>