lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] Microblaze and lwIP


From: jcr_alr
Subject: [lwip-users] Microblaze and lwIP
Date: Tue, 08 May 2007 10:41:46 -0300
User-agent: Internet Messaging Program (IMP) 3.1

Some months ago I started a thread when I ran into problems with response times 
using Microblaze and lwIP in sockets mode. I implemented the suggestions others 
had suggested - hardware multiplier, implementing a cache etc with improved 
performance but the underlying problem remained.

The application used lwip to transfer a small amount of data (requests really) 
from the PC to the host which sends back 2Kbytes of data, divided into one full 
1460 byte segment followed by the remaining 588 bytes in a partial segment. To 
make the system user-responsive, I wanted to complete the request/response time 
in, say, 100 millisecs. The problem arose when the PC client took some 200 - 
300 milliseconds to ACK the first segment, as seen on Windump traces. 

In tcp_out.c, I modified the tcp_enqueue() function to mark any full segment as 
PSH and in tcp_output() modified the conditions in the entry to the 'while' 
block to ensure that both segments were transmitted consecutively.

The complete transaction now takes place within 14 millisecs, which includes 
some short delays I added to the client code, eg between the read and close 
calls.

I am not sure why this modification was necessary - are there any settings in 
either lwipopts or Winsock that I could have changed to avoid this. I think the 
problem may lie more in the PC end - because in the original implementation the 
first segment was sent without PSH and the client then maybe waited for some 
timeout period before realising nothing more was coming, then sent the ACK at 
which time the host responded sending the second partial segment that was 
marked PSH.

Any thoughts or suggestions would be most welcome.

John Robbins.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]