Latency spikes

[bbailey]

tl;dr - Issues with WiFi enumeration in QT's internal bearer plugins are causing latency spikes. Please upgrade to >= QT 5.9.4 for any future releases.

An internal bug/issue in QT introduces regular spikes of latency at frequent intervals (every 5-10 seconds depending on QT defaults). The effects are observable here; mudlet is causing the spikes in the second set of pings.

The issue occurs whenever the mudlet application is open. This is reproducible for me on Windows 10 Pro 1709 build 16299.309 with Mudlet 3.7.1, though I've been experiencing the issue for a while on previous recent versions of mudlet as well and have only just now narrowed down the specific issue.

The issue is present in QT versions from at least 5.6.2 (shipped with Mudlet 3.7.1's windows release) to 5.9.3, but has been fixed in QT 5.9.4.

Background article and relevant QTBUG reports:
https://lostdomain.org/2017/06/17/qt-qnetworkaccessmanager-causing-latency-spikes-on-wifi/
https://bugreports.qt.io/browse/QTBUG-40332
https://bugreports.qt.io/browse/QTBUG-65586

[bbailey]

The linked article does contain a workaround for the issue if upgrading QT is not viable in the near-term for some reason. I've confirmed it to work insofar as it alleviates the latency on my system, but being unfamiliar with QT's networking and mudlet's internals, I can't speak to whatever other side-effects may be introduced by such a 'fix'.

[keneanung]

Currently, we can't update Qt on windows (or more specifically the gcc version) due to #1316.

We'd like to update our dependencies, then have a closer look at the mentioned issue, but currently we don't have enough time (or experienced people in that regard) available.

[SlySven]

I would note that we may have this issue worse than some other Qt based applications. The documentation for QNetworkManager notes:

... . One QNetworkAccessManager should be enough for the whole Qt application...

However we instantiate many instances,

• One per TLuaInterpreter instance (mpFileDownloader)
• One per TMap instance (mpNetworkAccessManager)
• One per cTelnet instance (mpDownloader)
• One each time the "Editor" tab in dlgProfilePreferences instance is selected {manager in (void) dlgProfilePreferences::slot_editor_tab_selected(int tabIndex)}
• One per feedinstance (in 3rdparty/dblsqd/dblsqd/feed.cpp)

the first three are obviously per profile...!

I guess we might just increase that time-out to be a lot longer rather than 10 seconds (say 5 minutes?)

[vadi2]

Thanks so much for the investigation. Lets try the QT_BEARER_POLL_TIMEOUT workaround as it's seems most feasible at the moment (see keneanung above).

[SlySven]

💡 I suggest the following:

if (qgetenv("QT_BEARER_POLL_TIMEOUT").isEmpty()) {
    qputenv("QT_BEARER_POLL_TIMEOUT", "300000")
}

should go into int main(...) in main.cpp somewhere after:

/*******************************************************************
 * If we get to HERE then we are going to run a GUI application... *
 *******************************************************************/

and before:

mudlet::start();

this will put in that 5 minutes interval I suggest only if a value has not already been specified in the run-time environment. I will leave it for @bbailey to put forward because they are better suited to test it - and they deserved the credit (and will get the First-time contributor flag on Mudlet. 🏆 ) 😀

[SlySven]

Ah, is this specifically a Windoze issue?

[keneanung]

Ah, is this specifically a Windoze issue?

It seems so as our macOS builds (which the article linked mentions as well) are on 5.10...

[bbailey]

A five-minute timeout seems reasonable, and has behaved well for me in testing.