I am contemplating creating a realtime app where an iPod Touch/iPhone/iPad talks to a server-side component (which produces MIDI, and sends it onward within the host). When I ping my iPod Touch on Wifi I get huge latency (and a enormous variance, too):
64 bytes from 192.168.1.3: icmp_seq=9 ttl=64 time=38.616 ms
64 bytes from 192.168.1.3: icmp_seq=10 ttl=64 time=61.795 ms
64 bytes from 192.168.1.3: icmp_seq=11 ttl=64 time=85.162 ms
64 bytes from 192.168.1.3: icmp_seq=12 ttl=64 time=109.956 ms
64 bytes from 192.168.1.3: icmp_seq=13 ttl=64 time=31.452 ms
64 bytes from 192.168.1.3: icmp_seq=14 ttl=64 time=55.187 ms
64 bytes from 192.168.1.3: icmp_seq=15 ttl=64 time=78.531 ms
64 bytes from 192.168.1.3: icmp_seq=16 ttl=64 time=102.342 ms
64 bytes from 192.168.1.3: icmp_seq=17 ttl=64 time=25.249 ms
Even if this is double what the iPhone->Host or Host->iPhone time would be, 15ms+ is too long for the app I’m considering. Is there any faster way around this (e.g., USB cable)? If not, would building the app on Android offer any other options?
Traceroute reports more workable times:
traceroute to 192.168.1.3 (192.168.1.3), 64 hops max, 52 byte packets
1 192.168.1.3 (192.168.1.3) 4.662 ms 3.182 ms 3.034 ms
can anyone decipher this difference between ping and traceroute for me, and what they might mean for an application that needs to talk to (and from) a host?
I think this may be the WiFi power-save mode killing you. I think the phone buffers up packets and sends them out only occasionally. I saw similar behavior over WiFi on an N900 I was playing with.
Notice the strong pattern in the pings you posted. This is likely a beat pattern generated by the pings and antenna switching on and off periodically.