On Thu, 11 Oct 2018 at 15:56, Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: > > Hi, > > I found one pretty strange behavior for the Intel 8265/8275 wireless > (from ThinkPad X1 carbon) > > If I ping *FROM* my router/desktop to the wireless laptop, the response > time is very unstable and slow, like: > ------ > $ ping -4 thinkpad > PING thinkpad.lan (172.16.0.100) 56(84) bytes of data. > 64 bytes from thinkpad.lan (172.16.0.100): icmp_seq=1 ttl=64 time=143 ms > 64 bytes from thinkpad.lan (172.16.0.100): icmp_seq=2 ttl=64 time=166 ms > 64 bytes from thinkpad.lan (172.16.0.100): icmp_seq=3 ttl=64 time=188 ms > 64 bytes from thinkpad.lan (172.16.0.100): icmp_seq=4 ttl=64 time=211 ms > 64 bytes from thinkpad.lan (172.16.0.100): icmp_seq=5 ttl=64 time=29.8 ms > 64 bytes from thinkpad.lan (172.16.0.100): icmp_seq=6 ttl=64 time=51.7 ms > 64 bytes from thinkpad.lan (172.16.0.100): icmp_seq=7 ttl=64 time=72.8 ms > 64 bytes from thinkpad.lan (172.16.0.100): icmp_seq=8 ttl=64 time=94.6 ms > 64 bytes from thinkpad.lan (172.16.0.100): icmp_seq=9 ttl=64 time=117 ms > 64 bytes from thinkpad.lan (172.16.0.100): icmp_seq=10 ttl=64 time=140 ms > 64 bytes from thinkpad.lan (172.16.0.100): icmp_seq=11 ttl=64 time=163 ms > 64 bytes from thinkpad.lan (172.16.0.100): icmp_seq=12 ttl=64 time=186 ms > 64 bytes from thinkpad.lan (172.16.0.100): icmp_seq=13 ttl=64 time=207 ms > 64 bytes from thinkpad.lan (172.16.0.100): icmp_seq=14 ttl=64 time=25.1 ms > 64 bytes from thinkpad.lan (172.16.0.100): icmp_seq=15 ttl=64 time=47.6 ms > ----- > > It looks like the response time get increase by 20ms and flipped over > around 200ms. [...] > So is this something wrong with the wireless card or something wrong > with the firmware/powersaving setting of ThinkPad X1 Carbon 6th gen? What you're seeing here is powersave. When you ping your laptop its wifi card may be in powersave so AP will store those icmp requests in a queue. The AP will start advertising that fact in the next beacon frame (which it broadcasts regularily). The wifi client can then see that there's traffic queued up for it, wake up, receive it and possibly reply (with icmp response in your case). The interval between each ping is long enough for the wifi client to re-enter powersave due to "nothing more to do" every time causing the same sequence (sleep, queue, advertise, wake, txrx). The time drift comes from the fact beacon interval tends to be slightly off from your ping interval. The fact it wraps around at ~200msec for you means your AP's beacon interval is roughly that long as well which you can probably confirm with your AP/wifi router settings. Most APs tend to run 100 or 200msec (or TU, actually, which is 1024/1000 of msec) by default. If you run more traffic the lag will go away. I find this sort of behavior behavior annoying for mostly idle systems where I want to do remoting with ssh (or any other bursty and interactive work). You can try disabling powersave with: iw wlan0 set power_save off You might need to replace wlan0 with wlpXsY depending on your system. You'll need root privileges to do it, e.g. via sudo, or su. Keep in mind it'll cause more power to be outputted and e.g. leave you with slightly shorter battery runtime. On intel compute sticks disabling wifi powersave can cause its fan to kick in more often due to thermal impact and unfortunate fan trip points. Wifi powersave might be disabled in Windows for some reason. Maybe it does that disable it when AC is plugged in, and if you were to plug it out and run off of battery only, it'd enable it and show similar (laggy) behavior? Michał
