-
Notifications
You must be signed in to change notification settings - Fork 342
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Huge ping value increase after running 5g wifi for some time #152
Comments
This should be expected behaviour from iOS. It would not be possible for an iPad to achieve 10 hours of battery life if it behaved like a desktop computer. When the device is idle the wifi hardware goes into a powersave mode because it isn't critical to get data quickly. When network data is needed the wifi hardware is taken out of power save mode until network traffic is reduced to an idle state again so that power save mode is kicked back in. Source link Maybe streaming audio from the internet in the background of your game will prevent the iPad powersaving. |
no, the device is not idle and hardware does not go to powersave mode. because it's never happen when using wndr3800 with this same ipad doing same thing at same place. and this "idle" can't wake up whatever you do to ipad, unless you do restart on mt76 router. so it's mt76 driver not ios. |
@updatede I can't reproduce it with my iPad, what is for you "for some time" ? |
@Mafesa for some time is a duration of time , not fixed, 3mins,5mins,10mins or just connected. |
@Mafesa what's your ping value from route to client ? |
192.168.0.98 is your router IP? |
@Mafesa I don't know what's your client ip. you need ping from the router to client. |
OK I understand, I was doing the opposite from iPad to router with this app. |
Tested now OpenWrt SNAPSHOT r6152-f4e5880 and ping router -> iPad 5GHz is constant with ~50 ms |
@nbd168 because lack of debug info, I want to add some debug info in my copy of source code to find the reason why ping value get so high to 1000 or 2000 ms, any advice for places to add ? |
I can say that I see something similar on both mt7603 and mt7612. |
Seeing similar behavior on my Dir-860L. 1000-2000ms pings, high packet loss and very slow speeds. Only rebooting the router solves the issue for me. Lede 17.01.4 is completely fine. |
Please try to build the latest version from my staging tree at https://git.openwrt.org/?p=openwrt/staging/nbd.git;a=summary |
Because I rely on snapshot sdk to build, and this tree switch to kernel 4.14 before mac80211 patch, I don't know how to build it, I will test as soon as it commit to master tree. Thank very much @nbd168 |
nbd, I have been experimenting with mir3g and the new 4.14 kernel. i have been seeing similar behavior. Would love to test patches. I am currently running 6c194078db6958e349114c8605304a7b87edae3e on 4.09, but I can build 4.14 with patches tomorrow if you want me to try stuff (I have 6 of those units...). How do I build your staging, is that the entire build system or a package repo? |
@nbd168 I have modified function ieee80211_amsdu_aggregate according to your patch, and compile mac80211.ko on my old snapshot sdk with 4.9.77 kernel. I replace mac80211.ko on my router which run a 4.9.86 kernel snapshot, after restart, it always popup error of wifi password not correct. I'll try with same snapshot version system and sdk later. |
@nbd168 I am leaving for my holiday tomorrow. I will be back the 19th of March. If you still need testing to be done I will help after that. I'm sorry that I can't help at the moment. |
@nbd168, I manually patched tx.c in mac80211 directory of backports-2017-11-01, and rebuild mac80211.ko file with latest snapshot sdk. After testing, the same problem still exist. But it take about 20mins to trigger, it usually take 3-5mins to trigger before this patch. There are other similar problems, move to weak signal place, client will stuck in high ping value and packet loss, move back to strong signal place won't get out of stuck. Turn off wifi or screen on client, wait about 5mins, turn on wifi or screen again, client will stuck in high ping value and packet loss either. The common problem of all above is, once high ping and packet loss appears, you can't let it disappear by any means unless restart wifi on router. |
Any chance you could give me SSH access to your device while it's in the faulty state? Maybe I can find out a bit more about this bug that way. |
@nbd168 of course, but I need private way to tell you how. is there private message at github ? it is 22:28 at my time, if you can do it tonight, I’ll tell you privately as soon as stuck appear. |
You could send me an email: nbd@nbd.name |
ok , wait my email |
have you receive my email ? I have not receive any response. |
I'm logged in and running some tests already. Thanks! |
I am back from my skiing holiday. Do you still need testers, @nbd168 ? |
@nbd168 The latest r6653-c0bbb97 still has this bug unfixed after issue opened for about two months.
|
Thank you very much for digging into this! @nbd if you need testers, please let me know. |
I meant to tag @nbd168 :) sorry about that |
Please try the latest version |
@nbd168 |
"If the driver buffers frames in the driver for aggregation in any way, it must use the ieee80211_sta_set_buffered() call when it is notified of the station going to sleep to inform mac80211 of any TIDs that have frames buffered." from Linux 802.11 Driver Developer’s Guide. |
@nbd168 |
@nbd168 |
@nbd168 |
@nbd168
|
@nbd168 |
this project does not want to fix this bug and i switch to stock driver to abandon this driver. |
I do want to fix this bug, I just don't have much time on my hands at the moment. |
no, thanks |
Just keep the ticket open, please. There's other people who want to see this fixed. Thanks! |
Agreed. Please leave this ticket open. There is valuable information in here and there are more people who would like to see this fixed. |
And want help. Because @nbd168 do great work. (It is still opensource) |
I think I may have found a possible cause for this. Apparently the beacon timer drifts by one microsecond every time it fires. The minimum configurable interval is 64us, so it has to be corrected every 64 beacons. This would also explain why changing the beacon interval affects the time it takes for this issue to manifest. |
I was seeing the same issue 2 months ago when I tried the master branch. I returned back to 17.01.4 where this issue does not exist for me. I haven't tried the master branch in the mean time, but I plan on flashing the 18.06 branch this Monday when I come back from my holiday to help testing. Will let you know if I am able to reliably reproduce this. |
I've made a fix and verified the timings. It's in the master branch now, and I intend to push it to the 18.06 branch soon. |
@nbd168 - I am not trying to cross issues - but the description here in the
email as well as in the commit perfectly describe behavior that we are
getting really badly also on the mt7603 (2Ghz) chipset that we reported in
this issue: #167
Any chance there would be a way to implement similar checks and behavior
for the mt7603 chips as well? Could they both be suffering from the same?
We are only able to replicate the behavior when devices are coming out of
power save mode ....
…On Fri, May 18, 2018 at 9:16 AM, nbd168 ***@***.***> wrote:
I've made a fix and verified the timings. It's in the master branch now,
and I intend to push it to the 18.06 branch soon.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#152 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AB0TcvpjHM534DvjyJ0oyE2PQNQNwK9wks5tzvPJgaJpZM4SJL20>
.
|
I ran some tests, MT7603 does not have the same issue |
Hello. As I have mentioned in #139 during tests for mt76x2u (USB variant) that is sharing some of the code, this exact issue happens everytime one scans for networks. TX and RX are simply blocked for about 15 seconds, which is not normal. I've just had the chance of confirming that it happens exactly the same with mt76x2 on latest master. Just try it, launch some kind of speed test, iperf or ping and then do a As I've also mentioned there, if you go to tx.c and comment both of the My guess is that the original issue reporter has something in his configuration that triggers a network scan once in a while (in my case with the USB variant, it was happening very frequently since I was in a PC with Fedora/MATE and NetworkManager triggers a scan every other minute if the signal isn't what they would consider perfect). Hope this helps @nbd168 and @LorenzoBianconi to find out what is going on. |
I've fixed the issue with latency during scanning in current mt76 git. Please test. |
@nbd168 Looking good, I no longer have total RX/TX loss when scanning. Ping responses are now normal when doing so. Iperf3 performance isn't still what I'd call optimal on that situation, but that may involve something specific to my environment, so it would be nice if other people also tested and gave feedback :) Thank you. |
I promised to get back to you @nbd168 to report whether I could still reproduce this issue. I have been running the 18.06 branch since Tuesday (which does not contain the beacon timer drift fix) and I am unable to reproduce the issue. So in my case, the flaky 5ghz connection must have been caused by something else. So therefor, I am unable to test whether the beacon timer drift fix actually fixed anything regarding this reported issue. It would be best if @updatede could confirm/deny whether the fix is successful for him. |
device: xiaomi router 3g
target: ramips/mt7621
system: OpenWrt SNAPSHOT r6150-dc7a1e8
signal strength: -60dbm
I use just only one client to connect router: a ipad air2.
When wlan just start:
After play game for some time, network get stucked, at the same place, close all programs on pad, ping value increase huge, won't decrease untill restart wlan on router, after restart ping value decrease to normal.
The text was updated successfully, but these errors were encountered: