Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor I
2,923 Views

Intel Edison TCP issues.

Hello,

For some time now I have been trying to find out why I have been experiencing massive latency with the Intel Edison. After reviewing configuration I see nothing that helps me to resolve the issue.

The latency issue is now causing me to 2nd guess my choice of using this device as the central server for my automation system. I am hoping that some of you guys may have experienced this or have suggestions for how to find and solve this issue.

Testing

VengNas.local (Linux Server) Connected VIA CAT 5 cable. (In computer Room)

RomoPi.local (Raspberry Pi P3) Wireless connection. (In Computer Room)

ProtoPi.local (Raspberry Pi P3) Wireless connection. (In Computer Room)

SmartOne.local (Intel Edison) Wireless connection. (In Computer Room)

MyraPi.local (Raspberry Pi P3) Wireless connection. (In Office downstairs)

All 5 devices are on the same network, as you can see, only one is connected with a wire. I perform a ping test to the VengNas.local from each device, one at a time. I only provided the output from 2 tests as it is enough to show the issue. The same pattern exists for each and every device that attempts to talk to the Intel Edison. I do not mind and my application wont suffer from slight deviations or latency, however as you can see, the latency issue is not minor.

[code]

VengNas.local ping SmartOne.local

64 bytes from SmartOne.local (192.168.1.68): icmp_seq=1 ttl=64 time=319 ms

64 bytes from SmartOne.local (192.168.1.68): icmp_seq=2 ttl=64 time=255 ms

64 bytes from SmartOne.local (192.168.1.68): icmp_seq=3 ttl=64 time=162 ms

64 bytes from SmartOne.local (192.168.1.68): icmp_seq=4 ttl=64 time=101 ms

64 bytes from SmartOne.local (192.168.1.68): icmp_seq=5 ttl=64 time=310 ms

64 bytes from SmartOne.local (192.168.1.68): icmp_seq=6 ttl=64 time=25.6 ms

64 bytes from SmartOne.local (192.168.1.68): icmp_seq=7 ttl=64 time=458 ms

64 bytes from SmartOne.local (192.168.1.68): icmp_seq=8 ttl=64 time=79.4 ms

64 bytes from SmartOne.local (192.168.1.68): icmp_seq=9 ttl=64 time=300 ms

64 bytes from SmartOne.local (192.168.1.68): icmp_seq=10 ttl=64 time=250 ms

64 bytes from SmartOne.local (192.168.1.68): icmp_seq=11 ttl=64 time=159 ms

64 bytes from SmartOne.local (192.168.1.68): icmp_seq=12 ttl=64 time=243 ms

VengNas.local ping ProtoPi.local

64 bytes from ProtoPi.local (192.168.1.60): icmp_seq=3 ttl=64 time=10.6 ms

64 bytes from ProtoPi.local (192.168.1.60): icmp_seq=4 ttl=64 time=8.69 ms

64 bytes from ProtoPi.local (192.168.1.60): icmp_seq=5 ttl=64 time=7.45 ms

64 bytes from ProtoPi.local (192.168.1.60): icmp_seq=6 ttl=64 time=9.49 ms

64 bytes from ProtoPi.local (192.168.1.60): icmp_seq=7 ttl=64 time=37.0 ms

64 bytes from ProtoPi.local (192.168.1.60): icmp_seq=8 ttl=64 time=15.4 ms

64 bytes from ProtoPi.local (192.168.1.60): icmp_seq=9 ttl=64 time=12.2 ms

64 bytes from ProtoPi.local (192.168.1.60): icmp_seq=10 ttl=64 time=4.37 ms

64 bytes from ProtoPi.local (192.168.1.60): icmp_seq=11 ttl=64 time=13.4 ms

64 bytes from ProtoPi.local (192.168.1.60): icmp_seq=12 ttl=64 time=8.54 ms

ProtoPi.local ping Smartone.local

64 bytes from 192.168.1.68: icmp_seq=1 ttl=64 time=44.9 ms

64 bytes from 192.168.1.68: icmp_seq=2 ttl=64 time=78.2 ms

64 bytes from 192.168.1.68: icmp_seq=3 ttl=64 time=287 ms

64 bytes from 192.168.1.68: icmp_seq=4 ttl=64 time=516 ms

64 bytes from 192.168.1.68: icmp_seq=5 ttl=64 time=139 ms

64 bytes from 192.168.1.68: icmp_seq=6 ttl=64 time=66.6 ms

64 bytes from 192.168.1.68: icmp_seq=7 ttl=64 time=358 ms

64 bytes from 192.168.1.68: icmp_seq=8 ttl=64 time=208 ms

64 bytes from 192.168.1.68: icmp_seq=9 ttl=64 time=381 ms

64 bytes from 192.168.1.68: icmp_seq=10 ttl=64 time=57.6 ms

ProtoPi.local ping VengNas.local

64 bytes from 192.168.1.3: icmp_seq=1 ttl=64 time=2.80 ms

64 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=8.72 ms

64 bytes from 192.168.1.3: icmp_seq=3 ttl=64 time=29.7 ms

64 bytes from 192.168.1.3: icmp_seq=4 ttl=64 time=8.28 ms

64 bytes from 192.168.1.3: icmp_seq=5 ttl=64 time=13.4 ms

64 bytes from 192.168.1.3: icmp_seq=6 ttl=64 time=12.3 ms

64 bytes from 192.168.1.3: icmp_seq=7 ttl=64 time=13.2 ms

64 bytes from 192.168.1.3: icmp_seq=8 ttl=64 time=11.4 ms

64 bytes from 192.168.1.3: icmp_seq=9 ttl=64 time=7.41 ms

64 bytes from 192.168.1.3: icmp_seq=10 ttl=64 time=11.4 ms

64 bytes from 192.168.1.3: icmp_seq=11 ttl=64 time=9.50 ms

[/CODE]

13 Replies
Highlighted
Community Manager
22 Views

Are all the wireless devices connected via the same WiFi bands/versions?

0 Kudos
Highlighted
Community Manager
22 Views

Hi,

 

 

What image are you using?

 

 

-Sergio

 

0 Kudos
Highlighted
New Contributor I
22 Views

Yes, all devices are configured identically with the exception of ProtoPi.local that has a static IP address. Outside that, they all are on same network same band. All the Raspberry Pis are at the latest version.

0 Kudos
Highlighted
New Contributor I
22 Views

Linux SmartOne 3.10.17-poky-edison+ # 2 SMP PREEMPT Mon Mar 14 15:26:16 PDT 2016 i686 GNU/Linux

0 Kudos
Highlighted
New Contributor I
22 Views

Just to add.

Doing the tests in reverse show the ping times to be lower and more stable. They do bounce around a bit but not as bad.

I have checked for utilization thinking it is something. However, top shows the system not even working hard at all.

Now, I do have an NODE JS application that is running, with no devices connected to the software, the software does send a MultiCast packet ever 2 sec. This packet is small in nature and it is an outgoing packet, and simply contains some configuration information. Killing the application results in no noticeable improvement in the ping times.

In reviewing other posts here I came across someone posting how to change the DNS name. This person provided ping times, what was interesting is this person was on a local network and ping times were high and spiky for a local connection.

I did notice that iptables is installed, checked to see if some rule was set, the default rules I expected to see where in place as such I don't suspect firewall issues.

0 Kudos
Highlighted
Community Manager
22 Views

Try sending a larger packet.

It may have to do with TCP/IP packet flushing settings...

0 Kudos
Highlighted
New Contributor I
22 Views

I will try a large ping packet and report back.

However, it seems this is not a new issue. After doing more digging on this site I found this post.

It seems to be matching what I am seeing.

0 Kudos
Highlighted
New Contributor I
22 Views

Here are the results with a larger packet size. I also did a test with a 2k packet and it was worse.

Romonaga-MacBook:~ Romonaga$ ping -s 200 smartone.local

PING smartone.local (192.168.1.68): 200 data bytes

208 bytes from 192.168.1.68: icmp_seq=0 ttl=64 time=7.857 ms

208 bytes from 192.168.1.68: icmp_seq=1 ttl=64 time=17.994 ms

208 bytes from 192.168.1.68: icmp_seq=2 ttl=64 time=123.342 ms

208 bytes from 192.168.1.68: icmp_seq=3 ttl=64 time=17.775 ms

208 bytes from 192.168.1.68: icmp_seq=4 ttl=64 time=163.144 ms

208 bytes from 192.168.1.68: icmp_seq=5 ttl=64 time=3.237 ms

208 bytes from 192.168.1.68: icmp_seq=6 ttl=64 time=601.512 ms

208 bytes from 192.168.1.68: icmp_seq=7 ttl=64 time=22.311 ms

208 bytes from 192.168.1.68: icmp_seq=8 ttl=64 time=434.144 ms

208 bytes from 192.168.1.68: icmp_seq=9 ttl=64 time=7.920 ms

208 bytes from 192.168.1.68: icmp_seq=10 ttl=64 time=80.869 ms

208 bytes from 192.168.1.68: icmp_seq=11 ttl=64 time=504.716 ms

208 bytes from 192.168.1.68: icmp_seq=12 ttl=64 time=9.655 ms

208 bytes from 192.168.1.68: icmp_seq=13 ttl=64 time=19.803 ms

208 bytes from 192.168.1.68: icmp_seq=14 ttl=64 time=576.409 ms

208 bytes from 192.168.1.68: icmp_seq=15 ttl=64 time=3.207 ms

208 bytes from 192.168.1.68: icmp_seq=16 ttl=64 time=409.705 ms

208 bytes from 192.168.1.68: icmp_seq=17 ttl=64 time=18.899 ms

208 bytes from 192.168.1.68: icmp_seq=18 ttl=64 time=13.662 ms

208 bytes from 192.168.1.68: icmp_seq=19 ttl=64 time=475.499 ms

208 bytes from 192.168.1.68: icmp_seq=20 ttl=64 time=13.119 ms

Highlighted
New Contributor I
22 Views

Here is my test with Power Management on.

root@SmartOne:~# iwconfig wlan0 power on

root@SmartOne:~# exit

logout

Connection to smartone.local closed.

Romonaga-MacBook:~ Romonaga$ ping smartone.local

PING smartone.local (192.168.1.68): 56 data bytes

64 bytes from 192.168.1.68: icmp_seq=0 ttl=64 time=2.706 ms

64 bytes from 192.168.1.68: icmp_seq=1 ttl=64 time=78.167 ms

64 bytes from 192.168.1.68: icmp_seq=2 ttl=64 time=400.583 ms

64 bytes from 192.168.1.68: icmp_seq=3 ttl=64 time=270.644 ms

64 bytes from 192.168.1.68: icmp_seq=4 ttl=64 time=7.576 ms

64 bytes from 192.168.1.68: icmp_seq=5 ttl=64 time=68.891 ms

64 bytes from 192.168.1.68: icmp_seq=6 ttl=64 time=6.839 ms

64 bytes from 192.168.1.68: icmp_seq=7 ttl=64 time=715.354 ms

64 bytes from 192.168.1.68: icmp_seq=8 ttl=64 time=10.394 ms

64 bytes from 192.168.1.68: icmp_seq=9 ttl=64 time=552.991 ms

64 bytes from 192.168.1.68: icmp_seq=10 ttl=64 time=776.679 ms

64 bytes from 192.168.1.68: icmp_seq=11 ttl=64 time=204.345 ms

64 bytes from 192.168.1.68: icmp_seq=12 ttl=64 time=17.152 ms

64 bytes from 192.168.1.68: icmp_seq=13 ttl=64 time=40.335 ms

64 bytes from 192.168.1.68: icmp_seq=14 ttl=64 time=7.707 ms

64 bytes from 192.168.1.68: icmp_seq=15 ttl=64 time=683.202 ms

64 bytes from 192.168.1.68: icmp_seq=16 ttl=64 time=15.731 ms

0 Kudos
Highlighted
New Contributor I
22 Views

Here is my test with Power Management off.

root@SmartOne:~# iwconfig wlan0 power off

root@SmartOne:~# exit

logout

Connection to smartone.local closed.

Romonaga-MacBook:~ Romonaga$ ping smartone.local

PING smartone.local (192.168.1.68): 56 data bytes

64 bytes from 192.168.1.68: icmp_seq=0 ttl=64 time=7.779 ms

64 bytes from 192.168.1.68: icmp_seq=1 ttl=64 time=21.878 ms

64 bytes from 192.168.1.68: icmp_seq=2 ttl=64 time=26.849 ms

64 bytes from 192.168.1.68: icmp_seq=3 ttl=64 time=7.524 ms

64 bytes from 192.168.1.68: icmp_seq=4 ttl=64 time=7.794 ms

64 bytes from 192.168.1.68: icmp_seq=5 ttl=64 time=11.481 ms

64 bytes from 192.168.1.68: icmp_seq=6 ttl=64 time=11.319 ms

64 bytes from 192.168.1.68: icmp_seq=7 ttl=64 time=22.993 ms

64 bytes from 192.168.1.68: icmp_seq=8 ttl=64 time=2.933 ms

64 bytes from 192.168.1.68: icmp_seq=9 ttl=64 time=2.893 ms

64 bytes from 192.168.1.68: icmp_seq=10 ttl=64 time=11.688 ms

64 bytes from 192.168.1.68: icmp_seq=11 ttl=64 time=15.907 ms

64 bytes from 192.168.1.68: icmp_seq=12 ttl=64 time=7.645 ms

64 bytes from 192.168.1.68: icmp_seq=13 ttl=64 time=7.709 ms

64 bytes from 192.168.1.68: icmp_seq=14 ttl=64 time=8.067 ms

64 bytes from 192.168.1.68: icmp_seq=15 ttl=64 time=19.679 ms

64 bytes from 192.168.1.68: icmp_seq=16 ttl=64 time=15.418 ms

64 bytes from 192.168.1.68: icmp_seq=17 ttl=64 time=3.079 ms

0 Kudos
Highlighted
New Contributor I
22 Views

Its clear that power management is playing a role in degrading the performance of the network interface. The ping times are much better, but they still have large spikes. I will examine my own network at this point to see if its network equipment as I notice the spikes happen on the other devices as well. However, at least now I am not seeing close to 1sec response times for a local network ping.

So yes turning off power management did improve the issue greatly. so now the question changes from how to fix it to when will power management be fixed?

FYI

iwconfig wlan0 power off

iwconfig wlan0 power on

 

0 Kudos
Highlighted
New Contributor I
22 Views

Added Note

My application is now responding much better after this change. Now, I wonder if this will solve the periodic loss of my SSH session. Suspect it will.

0 Kudos
Highlighted
New Contributor I
22 Views

Power management will turn back on after a reboot, to turn this off at boot, please refer to the following document.

http://www.intel.com/content/www/us/en/support/boards-and-kits/000006168.fast.html Disabling Wi-Fi Power Management At Boot Time for Intel® Edison...

0 Kudos