On 2018/10/12 上午3:30, Michał Kazior wrote: > 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). Thanks for your detailed explanation, this really helps me to understand the problem. > > 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). Yeah, completely the same case. > > 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. Works like a charm. > > 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. Not a problem for Thinkpad with better thermal paste and extra tweaked CPU parameters. > > 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? On battery, windows behaves exactly the same as Linux. I only need to add some hook for AC/battery switch for Linux. Thanks for your help! Qu > > > Michał >
Attachment:
signature.asc
Description: OpenPGP digital signature
