On 8 Sep 2003 at 1:03, BRANE wrote:

> > QLwIP offers a window of 8760, but I have found that neither Windows nor
> > Linux will exploit that in their standard configuration, at least not as
> > long as their counterpart has 20 ms latency. Depending on the application,
> > they send one, maximum two packets before they wait for ACK.
> >
> > Somehow QLwIP must live with standard behaviour of other machines, you can
> > not expect people to tune their TCP stacks.
> >
> > All the best
> > Peter
> 
> Hmm. Something doesn't sound right here. Internet is full of "speed up your
> Internet connection" programs that do amongst other things exactly this, so
> I presume this has to be negotiable.

Well for Windows I tried such programs, without effect in
the given situation. It is possible that the long latency leads 
(absolutely unusual in ethernet networks) the counterpart to the 
decision not to send more than one or two TCP packets at once. I 
have not yet invested much in tuning the other machines, since 
this can not be the general solution.

For the IRQ approach to work with the same performance as 
polling, you'd need at least 14 TCP packets to be transferred 
back to back without ACK. Decide yourself wether this is 
realistic.

> Besides, I find it a bit hard to believe that average PC does acknowledge
> every packet on 100 Mbit Ethernet.  This would mean something like
> interrupts with 100 kHz rate. Not very likely on modern machines...

The rate would be about 7 kHz. It may surprise you, but IRQ's 
are actually triggered at this rate, although not every single 
packet is acknowledged. Still the number of packets per ACK is 
usually very small.

> This would also make TCP/IP on 1Gbit Ethernet useless...

On a CPU that can handle TCP at this rate, it's also no problem 
to deal with the exception handling. I have not looked into 1Gb, 
no idea how it's usually implemented.

All the best
Peter

Reply via email to