Pi Zero W - Wifi ping latency within lan not consistent

[xbipin]

we use rpi for voip and pbx and everything works fine except if we use the builtin wifi, then for some reason ping latency increases even on LAN and its more erratic when there is a voip call going through the rpi. For multiple calls we use the rpi3 and for single call purpose we are using the rpi zero w, power management is off on both and both on latest firmware and kernel, the strnage thing is if we use those cheap usb nano wifi dongles then those work flawless with latency close to 5-7ms only but with the builtin wifi it starts at 20-30ms and randomly goes upto 50-100ms even when the cpu load is hardly 10%. Power supply for both r beefy

[ghollingworth]

You say that you are using latest kernel and firmware, are these latest with apt-get update or rpi-update

A recent fix by @JamesH65 in the SMSC9514 and BCM fmac drivers may well explain why ping packets are going missing but he has since fixed that...

[xbipin]

just today i updated using rpi-update coz till now apt-get update was what i was using but that didnt fix it and with rpi-update also the latency is still high even when pinging from rpi to the internet router.

[xbipin]

both the rpi3 and rpi zero w are just next to the WiFi ap and we even tried using a different ap but results r same so for the rpi3 we use Ethernet and for the rpi zero w we r using the cheap realtek 8188 nano dongle which heat up a lot but atleast they work consistently

[JamesH65]

Does ifconfig show a lot of dropped packets? We've had reports that the dropped packet count has been unusually high since a kernel update about 6 months (guessing) ago. Does the dropped packet count increase when the ping time increases?

[xbipin]

the dropped packet issue remains on the Ethernet connection on the rip3 but in my case those dont happen on the wifi connection, ill get u a ping log using the builtin wifi as well as the one with a external wifi dongle to show what i mean shortly.

the Ethernet dropped packet issue is as below, its reduced compared to older versions but is still there RX packets:537935 errors:0 dropped:7618 overruns:0 frame:0 TX packets:338381 errors:0 dropped:0 overruns:0 carrier:0

[xbipin]

here is the ping log using inbuilt wifi chip to the internet router, the rpi is right next to the ap, notice the latency goes to 10+ms at times, when the rpi is a 2-3 meters away from the ap that latency goes higher than 30ms randomly:

PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. 64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=7.90 ms 64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=8.53 ms 64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=10.3 ms 64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=4.77 ms 64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=5.18 ms 64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=5.18 ms 64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=6.14 ms 64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=4.81 ms 64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=4.84 ms 64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=7.95 ms 64 bytes from 192.168.0.1: icmp_seq=11 ttl=64 time=2.05 ms 64 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=1.99 ms 64 bytes from 192.168.0.1: icmp_seq=13 ttl=64 time=2.08 ms 64 bytes from 192.168.0.1: icmp_seq=14 ttl=64 time=10.4 ms 64 bytes from 192.168.0.1: icmp_seq=15 ttl=64 time=8.13 ms 64 bytes from 192.168.0.1: icmp_seq=16 ttl=64 time=2.66 ms 64 bytes from 192.168.0.1: icmp_seq=17 ttl=64 time=2.70 ms 64 bytes from 192.168.0.1: icmp_seq=18 ttl=64 time=1.98 ms 64 bytes from 192.168.0.1: icmp_seq=19 ttl=64 time=2.83 ms 64 bytes from 192.168.0.1: icmp_seq=20 ttl=64 time=2.90 ms 64 bytes from 192.168.0.1: icmp_seq=21 ttl=64 time=4.46 ms 64 bytes from 192.168.0.1: icmp_seq=22 ttl=64 time=5.48 ms 64 bytes from 192.168.0.1: icmp_seq=23 ttl=64 time=4.89 ms 64 bytes from 192.168.0.1: icmp_seq=24 ttl=64 time=6.32 ms 64 bytes from 192.168.0.1: icmp_seq=25 ttl=64 time=6.29 ms 64 bytes from 192.168.0.1: icmp_seq=26 ttl=64 time=10.7 ms 64 bytes from 192.168.0.1: icmp_seq=27 ttl=64 time=16.7 ms 64 bytes from 192.168.0.1: icmp_seq=28 ttl=64 time=4.90 ms 64 bytes from 192.168.0.1: icmp_seq=29 ttl=64 time=4.81 ms 64 bytes from 192.168.0.1: icmp_seq=30 ttl=64 time=5.52 ms

there is no dropped packets on the wifi:

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9527 errors:0 dropped:0 overruns:0 frame:0 TX packets:9404 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1843330 (1.7 MiB) TX bytes:2243786 (2.1 MiB)

[xbipin]

here is a second try and now ping latency goes upto 200ms:

PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. 64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=1.71 ms 64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=4.78 ms 64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=4.13 ms 64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=4.84 ms 64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=7.61 ms 64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=5.02 ms 64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=4.90 ms 64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=8.99 ms 64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=6.30 ms 64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=9.46 ms 64 bytes from 192.168.0.1: icmp_seq=11 ttl=64 time=5.02 ms 64 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=5.77 ms 64 bytes from 192.168.0.1: icmp_seq=13 ttl=64 time=5.02 ms 64 bytes from 192.168.0.1: icmp_seq=14 ttl=64 time=6.23 ms 64 bytes from 192.168.0.1: icmp_seq=15 ttl=64 time=9.87 ms 64 bytes from 192.168.0.1: icmp_seq=16 ttl=64 time=2.22 ms 64 bytes from 192.168.0.1: icmp_seq=17 ttl=64 time=6.71 ms 64 bytes from 192.168.0.1: icmp_seq=18 ttl=64 time=3.29 ms 64 bytes from 192.168.0.1: icmp_seq=19 ttl=64 time=1.71 ms 64 bytes from 192.168.0.1: icmp_seq=20 ttl=64 time=3.81 ms 64 bytes from 192.168.0.1: icmp_seq=21 ttl=64 time=1.63 ms 64 bytes from 192.168.0.1: icmp_seq=22 ttl=64 time=2.01 ms 64 bytes from 192.168.0.1: icmp_seq=23 ttl=64 time=2.46 ms 64 bytes from 192.168.0.1: icmp_seq=24 ttl=64 time=11.1 ms 64 bytes from 192.168.0.1: icmp_seq=25 ttl=64 time=51.6 ms 64 bytes from 192.168.0.1: icmp_seq=26 ttl=64 time=36.0 ms 64 bytes from 192.168.0.1: icmp_seq=27 ttl=64 time=4.27 ms 64 bytes from 192.168.0.1: icmp_seq=28 ttl=64 time=6.41 ms 64 bytes from 192.168.0.1: icmp_seq=29 ttl=64 time=51.0 ms 64 bytes from 192.168.0.1: icmp_seq=30 ttl=64 time=194 ms 64 bytes from 192.168.0.1: icmp_seq=31 ttl=64 time=20.2 ms 64 bytes from 192.168.0.1: icmp_seq=32 ttl=64 time=16.9 ms 64 bytes from 192.168.0.1: icmp_seq=33 ttl=64 time=42.5 ms 64 bytes from 192.168.0.1: icmp_seq=34 ttl=64 time=2.14 ms 64 bytes from 192.168.0.1: icmp_seq=35 ttl=64 time=3.60 ms 64 bytes from 192.168.0.1: icmp_seq=36 ttl=64 time=1.57 ms 64 bytes from 192.168.0.1: icmp_seq=37 ttl=64 time=2.09 ms 64 bytes from 192.168.0.1: icmp_seq=38 ttl=64 time=1.62 ms 64 bytes from 192.168.0.1: icmp_seq=39 ttl=64 time=2.43 ms 64 bytes from 192.168.0.1: icmp_seq=40 ttl=64 time=9.97 ms 64 bytes from 192.168.0.1: icmp_seq=41 ttl=64 time=1.56 ms 64 bytes from 192.168.0.1: icmp_seq=42 ttl=64 time=4.76 ms 64 bytes from 192.168.0.1: icmp_seq=43 ttl=64 time=4.83 ms 64 bytes from 192.168.0.1: icmp_seq=44 ttl=64 time=5.10 ms

[xbipin]

could it be the wifi chip starts getting lower priority on the bus it sends data to the processor when there is just a small CPU spike because when the VoIP call is initiated the cpu is at 10% and combined with other system processes the cpu jumps to 20% once in a while and at that time u see this ping latency shoot up. Problem then is the audio starts lagging by more than 200ms and it takes a while for things to go back to normal probably due to the packet queue on the wifi. This doesnt happen with Ethernet connection even with the dropped packets issue nor does it with a realtek based usb wifi dongle

[JamesH65]

That's an interesting data point, the Zero's only have the single core, and it's not exactly a speed demon, so other processes needing CPU time will affect the speed with which the Wifi requests can be dealt with. I believe that Wifi does need more CPU cycles than the wired ethernet, or perhaps we need to adjust some priorities somewhere.

On 11 July 2017 at 13:54, xbipin notifications@github.com wrote:

could it be the wifi chip starts getting lower priority on the bus it sends data to the processor when there is just a small CPU spike because when the VoIP call is initiated the cpu is at 10% and combined with other system processes the cpu jumps to 20% once in a while and at that time u see this ping latency shoot up. Problem then is the audio starts lagging by more than 200ms and it takes a while for things to go back to normal probably due to the packet queue on the wifi. This doesnt happen with Ethernet connection even with the dropped packets issue nor does it with a realtek based usb wifi dongle

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_firmware_issues_839-23issuecomment-2D314433919&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=NQM1jMNWa3LuXqUv8PijImRk45ee3PFy4zlSx069FkY&s=iztOfAhoI1-0skGwBqlIU-7ooTcNve9LdfYpXGBiIYI&e=, or mute the thread https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADqrHSp0IOswTFgMEAnVnfD9hcAGSL0gks5sM3BogaJpZM4OTDL1&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=NQM1jMNWa3LuXqUv8PijImRk45ee3PFy4zlSx069FkY&s=WEP83CGpNQdt485XGI9iwFbQe7iRsKaY09gg0iON2wI&e= .

-- James Hughes Principal Software Engineer, Raspberry Pi (Trading) Ltd

[xbipin]

let me add that the rpi3 and rpi zero w both run the basic raspbian lite image headless with no other packages other than freeswitch which we use for voip and the same behavior appears on both using the builtin wifi but disappears when using the usb wifi dongle. If it was related to cpu cycles then rpi3 wouldnt be affected compared to pi zero w and also why does it happen with a cpu usage of 20% only, it should happen when the cpu is very much busy right?

[JamesH65]

Ah, OK, I thought you only saw this on the Zero. Maybe not such an interesting data point!

On 11 July 2017 at 16:11, xbipin notifications@github.com wrote:

let me add that the rpi3 and rpi zero w both run the basic raspbian lite image headless with no other packages other than freeswitch which we use for voip and the same behavior appears on both using the builtin wifi but disappears when using the usb wifi dongle. If it was related to cpu cycles then rpi3 wouldnt be affected compared to pi zero w and also why does it happen with a cpu usage of 20% only, it should happen when the cpu is very much busy right?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_firmware_issues_839-23issuecomment-2D314475969&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=uTM6hsrZmjyTuKPLBEMFPSIk_0o-SBzV4hONHSpQCRg&s=CUA7oO4c5eWpY8D13vr16M3dinvkEq8ug3HXxMX0uRo&e=, or mute the thread https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADqrHW4OIi04uaV4-5FLt9ztpmSxvknnp4ks5sM5COgaJpZM4OTDL1&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=uTM6hsrZmjyTuKPLBEMFPSIk_0o-SBzV4hONHSpQCRg&s=so8EEb2eXzbzlmc1_Qy2Ye1M0nREAj0k9oU5xcGsEOo&e= .

-- James Hughes Principal Software Engineer, Raspberry Pi (Trading) Ltd

[Ferroin]

Is it worse on the Zero though? If not, then that implies a different source for the issue than if it is, but either way, I'd be willing to bet it's some combination of hardware and driver code that's causing the issue.

[xbipin]

its not worse on zero, its same on both and im having a strong feeling its related to the drivers only. If u have any realtek 8188cu based wifi dongles i recommend u test that and u will notice no matter what the cpu load it still pings happily under 5-7ms consistently always and there is almost no noticeable latency in calls compared to a wired connection

[xbipin]

shall i paste a ping output using that usb dongle on the same pi zero?

[JamesH65]

No, that won't help, just shows that the dongle is working correctly.

On 11 July 2017 at 16:25, xbipin notifications@github.com wrote:

shall i paste a ping output using that usb dongle on the same pi zero?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/839#issuecomment-314480422, or mute the thread https://github.com/notifications/unsubscribe-auth/ADqrHaZ_xY5n2e9fmDWbUrHySsxGl1DAks5sM5PwgaJpZM4OTDL1 .

-- James Hughes Principal Software Engineer, Raspberry Pi (Trading) Ltd

[xbipin]

any other way this can be traced, i could provide remote SSH as well if required or if any command that can put the system in debug mode which i can send to get this resolved

[JamesH65]

Just a warning, the last wireless bug, referred to by Gordon above, took about a month of debugging to find...so don't expect instant results on this one.

On 11 July 2017 at 16:48, xbipin notifications@github.com wrote:

any other way this can be traced, i could provide remote SSH as well if required or if any command that can put the system in debug mode which i can send to get this resolved

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/839#issuecomment-314487643, or mute the thread https://github.com/notifications/unsubscribe-auth/ADqrHRE58iFDYC4-kOR2RiyJcK5hbnnMks5sM5lagaJpZM4OTDL1 .

-- James Hughes Principal Software Engineer, Raspberry Pi (Trading) Ltd

[xbipin]

yes i can understand and for now ill continue to use the usb dongle on the zero and Ethernet on the 3. the way i see u can trace this much quicker is if u connect a usb wifi dongle and the builtin wifi to same ap and compare

[comdata]

I am seeing similar but worse issues on the PI Zero W.

The ping times vary a lot and connections get lost.

64 bytes from 192.168.1.47: icmp_seq=737 ttl=64 time=1399 ms 64 bytes from 192.168.1.47: icmp_seq=738 ttl=64 time=919 ms 64 bytes from 192.168.1.47: icmp_seq=739 ttl=64 time=447 ms 64 bytes from 192.168.1.47: icmp_seq=740 ttl=64 time=450 ms 64 bytes from 192.168.1.47: icmp_seq=745 ttl=64 time=2001 ms 64 bytes from 192.168.1.47: icmp_seq=746 ttl=64 time=1002 ms 64 bytes from 192.168.1.47: icmp_seq=747 ttl=64 time=916 ms 64 bytes from 192.168.1.47: icmp_seq=748 ttl=64 time=231 ms 64 bytes from 192.168.1.47: icmp_seq=750 ttl=64 time=634 ms 64 bytes from 192.168.1.47: icmp_seq=753 ttl=64 time=1739 ms 64 bytes from 192.168.1.47: icmp_seq=756 ttl=64 time=1254 ms 64 bytes from 192.168.1.47: icmp_seq=757 ttl=64 time=1760 ms 64 bytes from 192.168.1.47: icmp_seq=758 ttl=64 time=762 ms 64 bytes from 192.168.1.47: icmp_seq=759 ttl=64 time=183 ms 64 bytes from 192.168.1.47: icmp_seq=760 ttl=64 time=166 ms 64 bytes from 192.168.1.47: icmp_seq=761 ttl=64 time=245 ms 64 bytes from 192.168.1.47: icmp_seq=762 ttl=64 time=806 ms 64 bytes from 192.168.1.47: icmp_seq=763 ttl=64 time=1479 ms 64 bytes from 192.168.1.47: icmp_seq=764 ttl=64 time=917 ms 64 bytes from 192.168.1.47: icmp_seq=771 ttl=64 time=652 ms 64 bytes from 192.168.1.47: icmp_seq=772 ttl=64 time=642 ms 64 bytes from 192.168.1.47: icmp_seq=773 ttl=64 time=323 ms 64 bytes from 192.168.1.47: icmp_seq=776 ttl=64 time=941 ms 64 bytes from 192.168.1.47: icmp_seq=778 ttl=64 time=127 ms 64 bytes from 192.168.1.47: icmp_seq=779 ttl=64 time=14.2 ms 64 bytes from 192.168.1.47: icmp_seq=780 ttl=64 time=146 ms 64 bytes from 192.168.1.47: icmp_seq=782 ttl=64 time=1355 ms 64 bytes from 192.168.1.47: icmp_seq=783 ttl=64 time=321 ms 64 bytes from 192.168.1.47: icmp_seq=784 ttl=64 time=461 ms 64 bytes from 192.168.1.47: icmp_seq=785 ttl=64 time=737 ms 64 bytes from 192.168.1.47: icmp_seq=786 ttl=64 time=1614 ms 64 bytes from 192.168.1.47: icmp_seq=787 ttl=64 time=1671 ms 64 bytes from 192.168.1.47: icmp_seq=788 ttl=64 time=673 ms 64 bytes from 192.168.1.47: icmp_seq=789 ttl=64 time=381 ms 64 bytes from 192.168.1.47: icmp_seq=790 ttl=64 time=75.2 ms 64 bytes from 192.168.1.47: icmp_seq=795 ttl=64 time=1450 ms 64 bytes from 192.168.1.47: icmp_seq=796 ttl=64 time=414 ms 64 bytes from 192.168.1.47: icmp_seq=797 ttl=64 time=320 ms 64 bytes from 192.168.1.47: icmp_seq=798 ttl=64 time=449 ms

The wireless here is based on recent AVM products but I have seens this also with other Access Points.

What can be done to analyse and fix this?

[xbipin]

I tried it with ubiquiti and mikrotik access point and it's same with both, for now I use a realtek chipset USB dongle

[JamesH65]

There is a recent firmware change currently in testing, check the wlan issue on here for more details. The fix may have some relevance.

On 12 Aug 2017 10:05 pm, "xbipin" notifications@github.com wrote:

I tried it with ubiquiti and mikrotik access point and it's same with both, for now I use a realtek chipset USB dongle

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/839#issuecomment-322002790, or mute the thread https://github.com/notifications/unsubscribe-auth/ADqrHR2pnxmaYMtb8rVTPK5VyAPjLMluks5sXgWTgaJpZM4OTDL1 .

[pelwell]

JamesH65 is referring to this issue: https://github.com/raspberrypi/linux/issues/1342#issuecomment-321221748

[comdata]

I tried the firmware mentioned in the thread and have seen no progress.

[JamesH65]

Ok, thanks for the data. Not really much idea what this could be yet

On 13 Aug 2017 9:32 am, "Christoph Mertins" notifications@github.com wrote:

I tried the firmware mentioned in the thread and have seen no progress.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_firmware_issues_839-23issuecomment-2D322026918&d=DwMCaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=RzlpOLcwAuK6diMYN7ai-KjBYanoK9JXkoG3p8UH72o&s=HohoxYhFcVhjxFwJzVnwp1z5zrgBJ_knwSpB9j7dhgY&e=, or mute the thread https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADqrHSBkP94gqFETs9GvWKtZA9oYOgVGks5sXqaogaJpZM4OTDL1&d=DwMCaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=RzlpOLcwAuK6diMYN7ai-KjBYanoK9JXkoG3p8UH72o&s=ikSb00d1P2VDAMp2MuFcTJLAEg4gCqObWU4cAiijdkw&e= .

[comdata]

Just to rule out the access points, I can see this issue connected to Apple Airport Express, TP Link Archer C50 running LEDE, AVM FritzBox 7272 and AVM Fritz Repeater 1250E. The issue is consistent with multiple Zero W's and also on the stretch release.

[comdata]

Just seen these messages with stretch and 4.9.43: [ 143.441741] brcmfmac: brcmf_cfg80211_escan_handler: scan not ready, bsscfgidx=0 [ 143.441758] brcmfmac: brcmf_fweh_event_worker: event handler failed (69) [ 147.224998] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

[comdata]

any news on this issue?

[JamesH65]

I have not had any time to look into wireless issues at the moment due to lots of other projects. I'm try to look in the next couple weeks but I can't promise anything.

On 26 Oct 2017 22:01, "Christoph Mertins" notifications@github.com wrote:

any news on this issue?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_firmware_issues_839-23issuecomment-2D339799676&d=DwMCaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=YEfOyNTNmz24T2dIvnXBP5JmD_tf6SPAuYhrRdIpS8g&s=Lat2os7SQFCdoV7SMurWY51oZFsRWkQ5ie9shwFSudM&e=, or mute the thread https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADqrHSE0O4PlQuLuWKUi9ipCcs3lvvgfks5swPMsgaJpZM4OTDL1&d=DwMCaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=YEfOyNTNmz24T2dIvnXBP5JmD_tf6SPAuYhrRdIpS8g&s=ulrTameJyLa5Dhz2nDZymnZrCjeAys8huXsh_92BY68&e= .

[comdata]

it seems that disabling bluetooth helps.

[comdata]

Is there any news around this issue or is bluetooth on the PI Zero W to be considered broken?

[JamesH65]

There is a recent change to the BlueZ stack to help with this. In addition there is a very recent test firmware for the Wireless than may also help.

https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=203508

and specifically

https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=203508#p1264106

[uchagani]

I've got the same issue on raspberry pi 3:

ping raspberry pi

PING 192.168.1.22 (192.168.1.22): 56 data bytes
64 bytes from 192.168.1.22: icmp_seq=0 ttl=64 time=103.711 ms
64 bytes from 192.168.1.22: icmp_seq=1 ttl=64 time=8.303 ms
64 bytes from 192.168.1.22: icmp_seq=2 ttl=64 time=251.833 ms
64 bytes from 192.168.1.22: icmp_seq=3 ttl=64 time=155.825 ms
64 bytes from 192.168.1.22: icmp_seq=4 ttl=64 time=190.730 ms
64 bytes from 192.168.1.22: icmp_seq=5 ttl=64 time=13.065 ms
64 bytes from 192.168.1.22: icmp_seq=6 ttl=64 time=41.354 ms

ping google

PING google.com (64.233.177.101): 56 data bytes
64 bytes from 64.233.177.101: icmp_seq=0 ttl=43 time=4.685 ms
64 bytes from 64.233.177.101: icmp_seq=1 ttl=43 time=5.294 ms
64 bytes from 64.233.177.101: icmp_seq=2 ttl=43 time=5.216 ms
64 bytes from 64.233.177.101: icmp_seq=3 ttl=43 time=5.332 ms
64 bytes from 64.233.177.101: icmp_seq=4 ttl=43 time=5.492 ms
64 bytes from 64.233.177.101: icmp_seq=5 ttl=43 time=4.772 ms
64 bytes from 64.233.177.101: icmp_seq=6 ttl=43 time=5.318 ms

kernel:

~: uname -a
Linux raspberrypi 4.14.17-v7+ #1090 SMP Mon Feb 5 21:02:18 GMT 2018 armv7l GNU/Linux

[Haringstad]

Bhahaha... I've got worse on the default wifi on the Pi Zero W:

64 bytes from pi-zero-w (2001:470:792d:1:ba27:ebff:fe9a:bde5): icmp_seq=659 ttl=64 time=402473 ms
64 bytes from pi-zero-w (2001:470:792d:1:ba27:ebff:fe9a:bde5): icmp_seq=660 ttl=64 time=401974 ms
64 bytes from pi-zero-w (2001:470:792d:1:ba27:ebff:fe9a:bde5): icmp_seq=661 ttl=64 time=401168 ms
64 bytes from pi-zero-w (2001:470:792d:1:ba27:ebff:fe9a:bde5): icmp_seq=662 ttl=64 time=400172 ms
64 bytes from pi-zero-w (2001:470:792d:1:ba27:ebff:fe9a:bde5): icmp_seq=663 ttl=64 time=399451 ms
64 bytes from pi-zero-w (2001:470:792d:1:ba27:ebff:fe9a:bde5): icmp_seq=664 ttl=64 time=398441 ms
64 bytes from pi-zero-w (2001:470:792d:1:ba27:ebff:fe9a:bde5): icmp_seq=665 ttl=64 time=397410 ms
64 bytes from pi-zero-w (2001:470:792d:1:ba27:ebff:fe9a:bde5): icmp_seq=666 ttl=64 time=396416 ms
64 bytes from pi-zero-w (2001:470:792d:1:ba27:ebff:fe9a:bde5): icmp_seq=667 ttl=64 time=395385 ms
64 bytes from pi-zero-w (2001:470:792d:1:ba27:ebff:fe9a:bde5): icmp_seq=668 ttl=64 time=394352 ms
64 bytes from pi-zero-w (2001:470:792d:1:ba27:ebff:fe9a:bde5): icmp_seq=669 ttl=64 time=393343 ms
64 bytes from pi-zero-w (2001:470:792d:1:ba27:ebff:fe9a:bde5): icmp_seq=670 ttl=64 time=392336 ms
64 bytes from pi-zero-w (2001:470:792d:1:ba27:ebff:fe9a:bde5): icmp_seq=671 ttl=64 time=392065 ms
64 bytes from pi-zero-w (2001:470:792d:1:ba27:ebff:fe9a:bde5): icmp_seq=672 ttl=64 time=391026 ms
64 bytes from pi-zero-w (2001:470:792d:1:ba27:ebff:fe9a:bde5): icmp_seq=673 ttl=64 time=390049 ms
64 bytes from pi-zero-w (2001:470:792d:1:ba27:ebff:fe9a:bde5): icmp_seq=674 ttl=64 time=389038 ms
64 bytes from pi-zero-w (2001:470:792d:1:ba27:ebff:fe9a:bde5): icmp_seq=675 ttl=64 time=389071 ms
64 bytes from pi-zero-w (2001:470:792d:1:ba27:ebff:fe9a:bde5): icmp_seq=676 ttl=64 time=389354 ms
64 bytes from pi-zero-w (2001:470:792d:1:ba27:ebff:fe9a:bde5): icmp_seq=677 ttl=64 time=388365 ms
64 bytes from pi-zero-w (2001:470:792d:1:ba27:ebff:fe9a:bde5): icmp_seq=678 ttl=64 time=389436 ms
64 bytes from pi-zero-w (2001:470:792d:1:ba27:ebff:fe9a:bde5): icmp_seq=679 ttl=64 time=389377 ms
64 bytes from pi-zero-w (2001:470:792d:1:ba27:ebff:fe9a:bde5): icmp_seq=680 ttl=64 time=388367 ms

Now top that.... Talking about SLOW Same issues with NetworkManager and systemd-networkd, static and dynamic addresses, 1, 5, 10, 15 meters from AP, Different AP's, With, or without walls in between. Reproduced easy.

[JamesH65]

I'd say that if you are using standard Raspbian, and all other devices on the same network are fine, then you probably have a defective Zero. Pretty sure if everyone was seeing the sames times, we would have seen a few more complaints.

[Haringstad]

@JamesH65 This is only seen after a couple of hours. The first 15 - 20 minutes, everything works fine. Then the delays are kicking in, and are only getting larger. Yep, I am using standard Raspbian Lite and all the other devices are fine. I am going to try with a different dongle too, to see how that is going to work out.....

[JamesH65]

The delay is an interesting data point.

[Haringstad]

To see if the hardware isn't faulty: Ordered 2 new Pi Zero W systems. Just to make sure it isn't the hardware.

[uchagani]

Mine is happening on a pi 3

[JsBergbau]

Here quite similiar problems. Pinging a zero W with about 1,5 m besides the AP

Antwort von 192.168.178.5: Bytes=32 Zeit=10ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=12ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=8ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=6ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=9ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=14ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=6ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=14ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=9ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=7ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=42ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=6ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=6ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=6ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=7ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=11ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=6ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=6ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=8ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=2ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=11ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=9ms TTL=64
Antwort von 192.168.178.5: Bytes=32 Zeit=8ms TTL=64

Pinging a RPI3 to Wifi Interface

Antwort von 192.168.178.6: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=7ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=7ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=7ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=7ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=64ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=8ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=6ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=6ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=22ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.6: Bytes=32 Zeit=4ms TTL=64

Interesting point is, there were short times when pinging the RPI3 via wifi when ping was <1ms as it should be. Perhaps some powersaving feature? Pinging router from my smartphone gives similiar high values.

Pinging from a Windows Wifi Notebook the Router gives

Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=2ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=8ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=3ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=2ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=11ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=2ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=3ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=2ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=30ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=2ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=2ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=2ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=2ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=3ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=20ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=44ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=6ms TTL=64
Antwort von 192.168.178.1: Bytes=32 Zeit=3ms TTL=64

Most time it is 1 ms as it should be. Sometimes the pings are a bit higher, probably because there is some load on the network.

[comdata]

updated to 4.14.39+ still seeing the issue.

before enabling bluetooth it is around 7ms afterwards it looks like this: 64 bytes from 192.168.1.111: icmp_seq=356 ttl=64 time=443.514 ms 64 bytes from 192.168.1.111: icmp_seq=357 ttl=64 time=468.530 ms 64 bytes from 192.168.1.111: icmp_seq=358 ttl=64 time=590.133 ms 64 bytes from 192.168.1.111: icmp_seq=359 ttl=64 time=58.007 ms 64 bytes from 192.168.1.111: icmp_seq=360 ttl=64 time=14.645 ms 64 bytes from 192.168.1.111: icmp_seq=361 ttl=64 time=8.543 ms 64 bytes from 192.168.1.111: icmp_seq=362 ttl=64 time=5.510 ms 64 bytes from 192.168.1.111: icmp_seq=363 ttl=64 time=8.566 ms 64 bytes from 192.168.1.111: icmp_seq=364 ttl=64 time=5.886 ms 64 bytes from 192.168.1.111: icmp_seq=365 ttl=64 time=38.658 ms 64 bytes from 192.168.1.111: icmp_seq=366 ttl=64 time=45.822 ms 64 bytes from 192.168.1.111: icmp_seq=367 ttl=64 time=43.620 ms 64 bytes from 192.168.1.111: icmp_seq=368 ttl=64 time=56.708 ms 64 bytes from 192.168.1.111: icmp_seq=369 ttl=64 time=76.601 ms Request timeout for icmp_seq 370 64 bytes from 192.168.1.111: icmp_seq=371 ttl=64 time=203.957 ms 64 bytes from 192.168.1.111: icmp_seq=372 ttl=64 time=485.653 ms 64 bytes from 192.168.1.111: icmp_seq=373 ttl=64 time=508.145 ms 64 bytes from 192.168.1.111: icmp_seq=374 ttl=64 time=531.000 ms 64 bytes from 192.168.1.111: icmp_seq=375 ttl=64 time=69.128 ms 64 bytes from 192.168.1.111: icmp_seq=376 ttl=64 time=14.352 ms 64 bytes from 192.168.1.111: icmp_seq=377 ttl=64 time=5.912 ms 64 bytes from 192.168.1.111: icmp_seq=378 ttl=64 time=5.812 ms 64 bytes from 192.168.1.111: icmp_seq=379 ttl=64 time=7.977 ms 64 bytes from 192.168.1.111: icmp_seq=380 ttl=64 time=10.140 ms 64 bytes from 192.168.1.111: icmp_seq=381 ttl=64 time=23.462 ms 64 bytes from 192.168.1.111: icmp_seq=382 ttl=64 time=53.464 ms 64 bytes from 192.168.1.111: icmp_seq=383 ttl=64 time=59.529 ms 64 bytes from 192.168.1.111: icmp_seq=384 ttl=64 time=88.132 ms 64 bytes from 192.168.1.111: icmp_seq=385 ttl=64 time=8.737 ms 64 bytes from 192.168.1.111: icmp_seq=386 ttl=64 time=582.759 ms 64 bytes from 192.168.1.111: icmp_seq=387 ttl=64 time=405.737 ms 64 bytes from 192.168.1.111: icmp_seq=388 ttl=64 time=948.464 ms 64 bytes from 192.168.1.111: icmp_seq=389 ttl=64 time=204.981 ms 64 bytes from 192.168.1.111: icmp_seq=390 ttl=64 time=80.242 ms

What I did is:

• start the bluetooth service
• run bluetoothctl
• activate scanning "scan on"

distance to AP is 1m, but tested with 2 other pi zero w's at different distances without any change.

[Line40]

I can also confirm this WIFI/BT issue. I'm running sensorReporter (https://github.com/rkoshak/sensorReporter) on a Zero W and when I switch bluetooth on the the phone I'm monitoring off, I get severe WIFI latency/packet loss issues. Depending on how agressively I configure sensorReporter, I can get any amount of packet loss, or even ssh disconnects when I'm connected to the Zero using WIFI. I'm pinging the PI from my OpenWRT box, which directly provides the WIFI the PI is using. Distance to the AP does not seem to matter, its the same if the PI is sitting next to the AP, or 5m away (the default distance in my case). Note that it's not a performance issue, I can work on the Zero just fine when I connect it using an USB-Ethernet dongle, at the same time the WIFI is literally out.

I already ran aptitude full-upgrade and rpi-update multiple times in the last few weeks, no changes.

I really hope this is not a hardware issue. I seem to recall something about Broadcom BT/WIFI combi chips :(

[gbus]

Same here: I have two zero W both updated to the latest firmware and OS. I run room-assistant, a software that use bluetooth to scan for proximity of registered devices. When I turn it on, the ping on the wifi interface becomes very unstable with high latency. As soon as I turn it off the wifi gets back to normal with zero packet loss.

[comdata]

Still an issue with:

Linux pizerow 4.14.70+ #1144 Tue Sep 18 17:20:50 BST 2018 armv6l GNU/Linux

[JamesH65]

Hmm. I would expect some latency changes when wifi and BT are both working at the same time - they use the same aerial and are required to coexist. So AIUI if BT is using the aerial, wifi waits for it to finish. Shoudn't be too horrendous though. There have been, IIRC, some changes to the coexist firmware on the chip, but that should be in 4.14.70. So, not sure. Still work to be done by Cypress on the firmmare I expect.

[comdata]

Tested again with 4.19.23+ and still an issue. Lost several ICMP packages when large bluetooth scans where active. Bluetooth is not usable with the PI ZERO W this way.

[comdata]

Still an issue with 4.19.34+.

64 bytes from 192.168.1.111: icmp_seq=18 ttl=64 time=59.530 ms 64 bytes from 192.168.1.111: icmp_seq=19 ttl=64 time=10.292 ms 64 bytes from 192.168.1.111: icmp_seq=20 ttl=64 time=37.558 ms

64 bytes from 192.168.1.111: icmp_seq=21 ttl=64 time=132.401 ms

64 bytes from 192.168.1.111: icmp_seq=22 ttl=64 time=35.054 ms 64 bytes from 192.168.1.111: icmp_seq=23 ttl=64 time=581.822 ms Request timeout for icmp_seq 24 Request timeout for icmp_seq 25 64 bytes from 192.168.1.111: icmp_seq=24 ttl=64 time=2233.823 ms 64 bytes from 192.168.1.111: icmp_seq=25 ttl=64 time=1855.638 ms 64 bytes from 192.168.1.111: icmp_seq=26 ttl=64 time=1872.624 ms 64 bytes from 192.168.1.111: icmp_seq=27 ttl=64 time=868.840 ms 64 bytes from 192.168.1.111: icmp_seq=28 ttl=64 time=65.474 ms 64 bytes from 192.168.1.111: icmp_seq=29 ttl=64 time=24.108 ms 64 bytes from 192.168.1.111: icmp_seq=30 ttl=64 time=16.551 ms 64 bytes from 192.168.1.111: icmp_seq=31 ttl=64 time=12.231 ms

The dropouts happened during a scan for bluetooth devices.

[JamesH65]

I would expect an increase in ping time during a BT scan, since the wireless and BT share the aerial, so one has to stop whist the other is active.

[salvq]

@JamesH65 is there any way to decrease a ping beside BT scan timeout optimization ? Or this is pure HW issue ?

[JamesH65]

Turn off BT altogether?

TBH, not my area of expertise, so no real idea. Fastest ping would be to use wired ethernet. Wifi will always be less consistent than wired.

[salvq]

Thanks, I do not have wire connection close to unit therefore using wireless.

Wireless is not that stable which is fine enough for my use case, the issue is BT / WiFi aerial switching and causing network instability :(

Do you know, is there any similar board as RPI ZERO W (Linux, BT and WiFi) which does not aerial sharing ?