On Wed, Nov 17, 2010 at 11:56 PM, Sergei Gavrikov <sergei.gavri...@gmail.com> wrote: > 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.).
My target board is quite slow on Ethernet and HyperTerminal broke sending data in multiple small packets, so probably that's why I was able to reach point where no more pbufs could be allocated. > Seek the posts near the time of porting new LWIP version, please, I hope that > Simon gave some advices. It looks like the root of my problem is in the way I created tasks. I used POSIX message queues and POSIX threads. After switching I left POSIX threads that's why timers do not work for me. Tried to create threads with cyg_lwip_thread_new() but only first thread was started... Tried to rewrite cyg_lwip_thread_new() to create POSIX threads instead, but also no luck... The only way I was able to start all the threads was locking task scheduler before creating and unlocking after all threads are created. Just thinking what to do best: continue with modifying cyg_lwip_thread_new() or just get rid of message queues. 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