date:20181011

Re: Intel 8265 unstable/asymmetric ping response time (only under Linux)

2018-10-11 Thread Qu Wenruo



On 2018/10/12 上午3:30, Michał Kazior wrote:
> On Thu, 11 Oct 2018 at 15:56, Qu Wenruo  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ł
> 



signature.asc
Description: OpenPGP digital signature

[PATCH] brcmfmac: support STA info struct v7

2018-10-11 Thread Dan Haab

The newest firmwares provide STA info using v7 of the struct. As v7
isn't backward compatible, a union is needed.

Even though brcmfmac does not use any of the new info it's important to
provide the proper struct buffer. Without this change new firmwares will
fallback to the very limited v3 instead of something in between such as
v4.

Signed-off-by: Dan Haab 
---
 .../broadcom/brcm80211/brcmfmac/fwil_types.h   | 39 ++
 1 file changed, 32 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
index d5bb81e..189d576 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
@@ -176,6 +176,8 @@
 
 #define BRCMF_VHT_CAP_MCS_MAP_NSS_MAX  8
 
+#define BRCMF_HE_CAP_MCS_MAP_NSS_MAX   8
+
 /* MAX_CHUNK_LEN is the maximum length for data passing to firmware in each
  * ioctl. It is relatively small because firmware has small maximum size input
  * playload restriction for ioctls.
@@ -601,13 +603,36 @@ struct brcmf_sta_info_le {
__le32 rx_pkts_retried;/* # rx with retry bit set */
__le32 tx_rate_fallback;   /* lowest fallback TX rate */
 
-   /* Fields valid for ver >= 5 */
-   struct {
-   __le32 count;   /* # rates in 
this set */
-   u8 rates[BRCMF_MAXRATES_IN_SET];/* rates in 
500kbps units w/hi bit set if basic */
-   u8 mcs[BRCMF_MCSSET_LEN];   /* supported 
mcs index bit map */
-   __le16 vht_mcs[BRCMF_VHT_CAP_MCS_MAP_NSS_MAX];  /* supported 
mcs index bit map per nss */
-   } rateset_adv;
+   union {
+   struct {
+   struct {
+   __le32 count;   
/* # rates in this set */
+   u8 rates[BRCMF_MAXRATES_IN_SET];
/* rates in 500kbps units w/hi bit set if basic */
+   u8 mcs[BRCMF_MCSSET_LEN];   
/* supported mcs index bit map */
+   __le16 vht_mcs[BRCMF_VHT_CAP_MCS_MAP_NSS_MAX];  
/* supported mcs index bit map per nss */
+   } rateset_adv;
+   } v5;
+
+   struct {
+   __le32 rx_dur_total;/* total user RX duration 
(estimated) */
+   __le16 chanspec;/** chanspec this sta is on */
+   __le16 pad;
+   struct {
+   __le16 version; 
/* version */
+   __le16 len; 
/* length */
+   __le32 count;   
/* # rates in this set */
+   u8 rates[BRCMF_MAXRATES_IN_SET];
/* rates in 500kbps units w/hi bit set if basic */
+   u8 mcs[BRCMF_MCSSET_LEN];   
/* supported mcs index bit map */
+   __le16 vht_mcs[BRCMF_VHT_CAP_MCS_MAP_NSS_MAX];  
/* supported mcs index bit map per nss */
+   __le16 he_mcs[BRCMF_HE_CAP_MCS_MAP_NSS_MAX];
/* supported he mcs index bit map per nss */
+   } rateset_adv;  /* rateset along with mcs index 
bitmap */
+   __le16 wpauth;  /* authentication type */
+   u8 algo;/* crypto algorithm */
+   __le32 tx_rspec;/* Rate of last successful tx 
frame */
+   __le32 rx_rspec;/* Rate of last successful rx 
frame */
+   __le32 wnm_cap; /* wnm capabilities */
+   } v7;
+   };
 };
 
 struct brcmf_chanspec_list {
-- 
1.9.1

Re: Intel 8265 unstable/asymmetric ping response time (only under Linux)

2018-10-11 Thread Michał Kazior

On Thu, 11 Oct 2018 at 15:56, Qu Wenruo  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ł

Dear Friend,

2018-10-11 Thread Eng. Ibrahim Mahamadi

Dear Friend,

Greeting in the name of our creator Allah the most Merciful, My Name is Eng.
Ibrahim Mahamadi from Damascus Syria I am now 47 years Old, and a military
officer under Marine Corps with 4 year experience in medical field.

I was in charge of supply of weapon and ammunitions from Russia to Syrian
Government. I have personally repented and decided to leave military work for a
holy living that was the reason I contacted you today if you know any
profitable Business in your Country I can invest my Money since my Country
Syria Security, Economy and happiness has been lost to the Lowest level
including our happiness has been taken away from us.

Our Country has been on fire for many years that made me lost my only child and
wife and I will like to relocate out from Syria. I need a trustworthy foreign
partner to enable me move my investment capital which is in my international
account amounting 12.5 million dollars. I will resign from work to join you in
your country as soon as you receive my investment fund.

You may as well tell me little more about yourself. Contact me urgently to
enable us proceed with the business.

SINCERELY YOURS
eng-ibrahim...@hot-shot.com

تحية باسم الله الخالق الرحيم اسمي المهندس. إبراهيم محمدي من دمشق سوريا أنا الآن
في السابعة والأربعين من العمر ، ضابط عسكري تحت قيادة مشاة البحرية مع خبرة 4
سنوات في المجال الطبي.

كنت مسؤولاً عن توريد الأسلحة والذخائر من روسيا إلى الحكومة السورية. لقد تبعت
شخصياً وقررت ترك العمل العسكري من أجل حياة مقدسة كان السبب في أنني اتصلت بك
اليوم إذا كنت تعرف أي عمل مربح في بلدك يمكنني أن أستثمر أموالي منذ أن فقدت بلدي
سوريا الأمن والاقتصاد والسعادة إلى أدنى مستوى بما في ذلك سعادتنا قد اتخذ بعيدا
عنا.

كانت بلادنا مشتعلة منذ سنوات عديدة ، مما جعلني أفقد ولدي وزوجتي الوحيدتين ،
وأنا أرغب في الانتقال من سوريا. أحتاج إلى شريك أجنبي جدير بالثقة لتمكينني من
تحريك رأسمال استثماري في حسابي الدولي الذي يبلغ 12.5 مليون دولار. سأستقيل من
العمل للانضمام إليك في بلدك بمجرد تلقي صندوق الاستثمار الخاص بي.

يمكنك كذلك أن تخبرني بالمزيد عن نفسك. اتصل بي على وجه السرعة لتمكيننا من المضي
قدمًا في العمل.

50 matches

Mail list logo