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
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).