On Wed, 17 Nov 2010, Alexander Aganichev wrote:
On Tue, Nov 16, 2010 at 6:18 PM, Alexander Aganichev
<aaganic...@gmail.com> wrote:
Now I have a problem that lwip sometimes ignores IP frames from PC
which cause PC to retransmit frame after two seconds which is not
acceptable. This happens not under heavy load. Never saw anything
similar on previous lwip version. The response time on ICMP is very
good and I don't see any delay or ignorance... Just wondering if
anyone saw something similar and have ideas where to dig?
It looks like tcp_tmr() is not executed in sequential mode and this
cause the problem. Can it just be started from tcpip_thread() like
other timers?
Hi,
Can you provide your ecm file/test? Of curiosity I tried eCos `tcpecho'
test under some load and I did not observe the same fading.
Having no real H/W I used something virtual
eCos: CVS updated
Host: Linux
Target: pc_rltk8139
Template: lwip_eth
Startup: RAM
Hardware: QEMU
Test: tcpecho
Run land: GDB (i386-elf-gdb)
Only changed:
cdl_option CYGFUN_LWIP_MODE_SIMPLE {
user_value 0
};
cdl_option CYGFUN_LWIP_MODE_SEQUENTIAL {
user_value 1
};
Stress Fu:
% strings /dev/urandom | nc host port ;# port was mapped on 7th
I saw l-o-o-o-ng and continuous 'matrix' in terminal. No fading. After
STOP/CONT (I got a resumption of the run as I expected) Well, it was
lazy and not accurate test, it was virtual H/W (but real S/W) and I
could not reproduce the issue for my environment. However, I guess the
packets could be lost (I was looking only for any long fading and I did
not plan to dive in the dumps of network traffic). Also, I call that
default CDL options (like mine) cannot be suitable for stress conditions
(i.e. default sizes of net buffers, the stack sizes, etc.). Seek the
posts near the time of porting new LWIP version, please, I hope that
Simon gave some advices.
Sergei
WBR, Alexander
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss