Sometimes the HTTP server gets in a state where it serves a web page made up of tiny packets, with some containing as few as 2 bytes. Consequently the page comes up slowly in the browser.
If I reset the board, the problem goes away. I haven't figured out how to reproduce it predictably.
These packets come very close together. I thought the HTTP server used delayed ACK?
To improve the performance of HTTP server we split HTTP outgoing packets into 2 parts, one big and one very small packet with only a few bytes (because of a delayed ACK impact). It is thus normal if you see here and there a small TCP outgoing packet.
If all packets are small and the reaction of HTTP server is very slow, then there must be something wrong. Can you analyse the situation which leads to such behaviour? How can we duplicate the problem here?
Yes, I see that packets come in pairs, one "large", followed immediately by a 4 byte packet. Perhaps you did this to get around Windows XP's delayed ack algorithm. The problem is the "large" one is not large enough when it gets in this mode. For example:
send 6 bytes send 4 bytes get ack wait 100 ms send 3 bytes send 4 bytes wait 100ms .. and so on for several seconds.
There is always about 100mS from the ack to the next pair of tiny packets. I'll try to work out a small scenario to reproduce it, as I don't want to send all my source code.
Dave
Looks like my fault. The task with cgi_func() was starved for processor time, so I guess it was producing a small amount of data within 100mS. In any case, when it gets more cpu cycles, the speed of the web page is normal.
Thanks Dave