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
Not fully resolved.
The situation was much improved with the (V3.05) driver. The long trains of long response times are gone, but still occasionally there is a single, isolated long response time.
This happens about once per minute, pinging at 1 second intervals, with 100ms TCPNet timer_tick(). Here is a typical sequence:
64 bytes from 192.168.2.203: icmp_seq=226 ttl=128 time=1.20 ms 64 bytes from 192.168.2.203: icmp_seq=227 ttl=128 time=1.61 ms 64 bytes from 192.168.2.203: icmp_seq=228 ttl=128 time=1.32 ms 64 bytes from 192.168.2.203: icmp_seq=229 ttl=128 time=1001 ms 64 bytes from 192.168.2.203: icmp_seq=230 ttl=128 time=2.88 ms 64 bytes from 192.168.2.203: icmp_seq=231 ttl=128 time=1.51 ms 64 bytes from 192.168.2.203: icmp_seq=232 ttl=128 time=1.25 ms 64 bytes from 192.168.2.203: icmp_seq=233 ttl=128 time=1.64 ms
This shows two interesting features:
1. The lengthened response time is often, but not always, almost exactly 1 second.
2. The response time to the ping immediately following the long one is always approximately double the normal response time.
Taken together, this evidence strongly suggests to me that sometimes a packet is received, but TCPNet is not informed of this until the subsequent packet arrives, and then both are processed together, thankfully in the order in which they arrived.
CH ==
Thanks Christopher.
I am using the V3.05 driver but my PING response times are much greater :- 64 bytes from dev_00 (10.51.21.48): icmp_seq=35 ttl=128 time=0.734 ms 64 bytes from dev_00 (10.51.21.48): icmp_seq=36 ttl=128 time=0.780 ms 64 bytes from dev_00 (10.51.21.48): icmp_seq=37 ttl=128 time=0.759 ms 64 bytes from dev_00 (10.51.21.48): icmp_seq=38 ttl=128 time=0.747 ms 64 bytes from dev_00 (10.51.21.48): icmp_seq=39 ttl=128 time=0.771 ms 64 bytes from dev_00 (10.51.21.48): icmp_seq=40 ttl=128 time=200.714 ms 64 bytes from dev_00 (10.51.21.48): icmp_seq=41 ttl=128 time=44.451 ms 64 bytes from dev_00 (10.51.21.48): icmp_seq=42 ttl=128 time=266.451 ms 64 bytes from dev_00 (10.51.21.48): icmp_seq=43 ttl=128 time=162.466 ms 64 bytes from dev_00 (10.51.21.48): icmp_seq=44 ttl=128 time=195.019 ms 64 bytes from dev_00 (10.51.21.48): icmp_seq=45 ttl=128 time=214.114 ms
It would appear the PING response time jumps whenever my TCP socket connects. If I disable TELNET in the NETCONFIG.C file and do not make a call to TCP_LISTEN then the PING responses are of the order of 0.7mS. If TELNET is enabled or I make a call to TCP_LISTEN then the PING response times jump up once the TCP connection is made.
As an aside, I have also noticed the PING response times increase (with no TCP socket connection or TELNET) if you exit the debugger i.e., build your code, download to flash via the debugger and then exit the debugger.
I have raised these issues with Keil and will let you know their findings whenever they get back to me.
Des
Maybe that is expected behaviour (lengthed ping response times while there is TCP activity).
Remember that TCPNet is single-threaded, so while a TCP packet is being processed (i.e. while in the TCP socket callback), any other incoming packets (including incoming pings) are buffered, and processed once the TCP callback has completed (or maybe the next time you call main_TcpNet() - I am not sure).
This is in contrast to bigger systems where typically separate threads/processes respond to each TCP/UDP socket. In this case even if one thread takes a long time to respond to a packet on a given socket, the pings are handled by a separate thread and so respond immediately.
In my case I have no IP activity except the pings themselves.
CH