Hi Andrew,
I believe the bottleneck is in lwip. As I stated
in my previous post, this is NOT a bug, but a
room for performance improvement for lwip.
Please see
http://lists.nongnu.org/archive/html/lwip-users/2010-12/msg00059.html
for my first post, and you can find out the rest
of them in
http://lists.nongnu.org/archive/html/lwip-users/2010-12/index.html
under the subject "Re: lwip-users Digest, Vol 88,
Issue 17" (My bad for not editing the title :(
I think the best way to rule out my platform or
bad coding is someone write a quick telnet
program on another platform(it is very very
simple and won't take long at all, mine is
similar to
http://www.ultimaserial.com/avr_lwip_tcp.html)
and it simply sends out 1200 byte packets
continously once TCP connection is made (I used lwip_send)
Configure the network like this:
lwip->hub->PC1, and connect PC2 to the hub
Run WireShark on PC2 to capture packets between lwip and PC1
Once lwip begins to send out packets to PC1, pull
the cable between PC1 and hub.
My capture shows lwip will not tranfer more than
two packets, it will wait for the ACK.
(non-lwip's RTO capture can be found in my first post)
If you can capture a different result, than the problem is on my end.
At 05:09 PM 12/15/2010, you wrote:
You may want to check Atmelâs website for the latest errata. They have
an upgraded version of your framework that already incorporates 1.3.2.
Even if you donât want to rework your entire project, it would be worth
looking into the low_level_input functions to ensure there werenât any
changes.
Andrew
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
