21 Dec
2005
21 Dec
'05
7:31 p.m.
You guys must be ACK'd off with this ;)
On 12/21/05, Phillip Susi <psusi(a)cfl.rr.com> wrote:
Ge van Geldorp wrote:
My current conclusion is that mozilla is poorly behaved because it sends
one byte at a time. Heck, it shouldn't even be using tcp/ip for local
IPC. You might want to file a bug with them on this issue. Sending
larger data blocks will be FAR more efficient, however, it should not be
as bad as you are reporting as long as they do set the TCP_NODELAY flag.
If they do set that flag and ReactOS does not correctly implement it,
that would explain why it works ok on windows and not ReactOS.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
--
"I had a handle on life, but then it broke"
Ok, so it seems that the sending side is correct
in holding back the packet.
In ReactOS the problem then is that the ACK is delayed for too long. I've
checked the delayed ACK path. Basically we fire a timer every 0.5 sec to do
cleanup tasks. Only one of every 5 of these timer ticks is passed on to the
oskittcp lib (routine TCPTimeout only calls TimerOskitTCP on every 5th
tick). This means that the oskittcp routine tcp_fasttimo() which is
responsible for sending delayed ACKs is only called every 2.5 sec, which
corresponds exactly to the delays in the loop.c test program I posted
earlier.
The delayed ACK is also correct behavior. Since there is plenty of room
left in the window, the ACK is supposed to be delayed so it can ACK
further data with one packet.
So, the solution seems to be to call
tcp_fasttimo() more often. Question is
how often? There's a comment in the accompanying tcp_slowtimo() that it
should be called every 500ms. So I guess tcp_fasttimo() should be called
substantially more often than that?
This is not the solution.
To avoid
any confusion, you can switch nagling off with the
TCP_NODELAY flag
Haven't checked yet if we implement this.