We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I'm using TCPNET and the RTX kernel on an STR912 ARM9.
A simple question first: can TCPNET be configured to respond to a broadcast PING?
Second, I have noticed that sometimes the response time to PINGs gets erratic and long. Normally the response time is ~1ms, but sometimes (for no reason I have been able to debug yet) the response times go up to 1 or 2 seconds (frequently almost exactly 1 or 2 seconds).
The only cure seems to be to power-cycle my board. This happens both on my own board and on an STRB9 from Keil. When I was running the http demo I noticed that when the ping time goes up, the HTTP response also becomes very slow. What is happening?
Christopher Hicks ==
NORMAL:
hiss:~# ping 192.168.2.12 PING 192.168.2.12 (192.168.2.12) 56(84) bytes of data. 64 bytes from 192.168.2.12: icmp_seq=1 ttl=128 time=1.03 ms 64 bytes from 192.168.2.12: icmp_seq=2 ttl=128 time=0.967 ms 64 bytes from 192.168.2.12: icmp_seq=3 ttl=128 time=0.998 ms 64 bytes from 192.168.2.12: icmp_seq=4 ttl=128 time=1.00 ms 64 bytes from 192.168.2.12: icmp_seq=5 ttl=128 time=0.908 ms
SOMETIMES:
hiss:~# ping 192.168.2.12 PING 192.168.2.12 (192.168.2.12) 56(84) bytes of data. 64 bytes from 192.168.2.12: icmp_seq=1 ttl=128 time=352 ms 64 bytes from 192.168.2.12: icmp_seq=2 ttl=128 time=2001 ms 64 bytes from 192.168.2.12: icmp_seq=3 ttl=128 time=1940 ms 64 bytes from 192.168.2.12: icmp_seq=4 ttl=128 time=941 ms 64 bytes from 192.168.2.12: icmp_seq=5 ttl=128 time=1001 ms 64 bytes from 192.168.2.12: icmp_seq=6 ttl=128 time=1186 ms 64 bytes from 192.168.2.12: icmp_seq=7 ttl=128 time=1011 ms 64 bytes from 192.168.2.12: icmp_seq=8 ttl=128 time=510 ms
Hi Christopher,
We experience a very similar behaviour here with a LPC2368 ARM7 based board.
I didn't do tests with the http demo, but only with our firmware. I was investigating on relationships with other task in our application, but your post suggests me that the problem could be somewhere else.
Did you get a deterministic path to make the ethernet performance fall down? As far as I can see I can make it happens with the following procedures: 1. by enabling tasks that require to run an ISR at relatively high frequency (every 20ms) 2. more simply by stopping the application anywhere with the debugger and making it run again a while after.
An interesting thing I noticed today is this: by disconnecting the eth cable while stopping the application and putting it back in place after restarting, the problem won't show up! If I just let the cable connected with the CPU stopped for a while, the slow down immediately appears, as soon as the application starts again.
I confirm that, once the performance decreases, nothing but a power cycle can put it back to full speed.
What version of TCPNet are you using? Are you targeting the http demo to the RTX RTOS or compiling as a standalone app?
I don't know enough of the LPC2368 architecture, but... Could this be due to some misconfiguration in the CPU internal MAC or the DMA module used by the MAC?
Does anybody out there have the same problem?
TIA
May you have lost the transmit interrupt, so that the stack only can send when it receives a packet and gets a receive interrupt?
In this case, the ping answer would hang in the stack until a new ping is received. In the same way, an http answer will hang until a new request or something else is seen.
Mmm, thanks... I thought of this, because if I "flood" ping at a very high rate then everything seems OK (response times stay short). The 1 or 2 second delay is an exact multiple of the rate at which I am sending out ping packets in the non-flood case.
I can make the behaviour happen both with debug and non-debug versions of TCPNet, and with or without the RTX kernel. I am beginning to suspect the STR9_ENET ethernet device driver code - I am using the "stock" code supplied by Keil.
Thanks again,
Christopher Hicks
There was a problem in the early device adapations. However this has been corrected long time ago.
Are you using the last RL-ARM release available on this web page?
Thank you, Reinhard. I had updated the library, but not the copy of the driver in my project (partly oversight, and partly because of some local modifications). The new driver seems to work better: there is an occasional long response time, but it seems to always recover immediately:
16 bytes from 192.168.2.11: icmp_seq=55 ttl=128 time=0.693 ms 16 bytes from 192.168.2.11: icmp_seq=56 ttl=128 time=0.664 ms 16 bytes from 192.168.2.11: icmp_seq=57 ttl=128 time=1000 ms 16 bytes from 192.168.2.11: icmp_seq=58 ttl=128 time=1.42 ms 16 bytes from 192.168.2.11: icmp_seq=59 ttl=128 time=0.676 ms
what hardware are you using? We need to know also the PC side so that we are able to replicate the problem.
The embedded board is a Keil STRB9 board (and a Hitex STR912 eval board behaves the same). I am sending the pings from an old PC running linux version 2.4.27, and lspci tells me this about the ethernet card:
Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
One weird thing I have noticed: if I have two STR912 boards on the network (different MAC and IP addresses obviously :-) ), and I send ping packets to both, then the delayed packets happen at about the same times for both boards.
There are switches, but no routers, between the host sending the pings and the two STR912 boards. The network is all 100MBit, and it is in use for other stuff but the load is not high.
I have a Windows PC on the same hub as the STR912 boards and running EtherSnoop on this seems to confirm that the delay happens inside the STR912 boards, and not elsewhere on the network.
On MCB2300 demo board vers. 3, using HTTP-Demo keil example, i have done as follows: 1) load application and let it run, in debug mode 2) start ping demo board: response time < 1ms 3) stop application wih debugger (obviously after a few seconds i see "ping timeout" on my pc) 4) restart application 5) after a few seconds, ping resumes but response time is very long (1000ms and more).