I am going to submit a bug report later today. Additionally, I have been looking at opportunities to contribute to Qt itself and I want to submit a patch to solve this bug. Would adding a method like setPollingEnabled(bool) to QNetworkConfigurationManager be a good solution?
On Thu, Apr 30, 2015 at 1:22 PM, Blasche Alexander < alexander.blas...@theqtcompany.com> wrote: > While removing the plugin is a workaround, it is not a solution. Please > file a bug including all you findings so far (including the pinned down > timer). Thank you. > > > -- > > Alex > ------------------------------ > *From:* interest-bounces+alexander.blasche=theqtcompany....@qt-project.org > <interest-bounces+alexander.blasche=theqtcompany....@qt-project.org> on > behalf of Shantanu Tushar <shaan...@gmail.com> > *Sent:* Wednesday, April 29, 2015 14:23 > *To:* Interests Qt > *Subject:* Re: [Interest] Q(Tcp/Udp)Socket stall > > Apologies for hijacking the thread. I use Qt for SoStronk > <http://www.sostronk.com>'s desktop app which gamers use to launch game > servers on demand (right now limited to Counter Strike : Global Offensive). > A lot of people had complained about their game lagging every 10 seconds. I > spent quite some time optimizing every timer that I had in the code, > eliminating timers wherever necessary and increasing intervals otherwise. > But, that didn't help. > > However, after seeing this thread reply, I used procexp > <https://technet.microsoft.com/en-in/sysinternals/bb896653.aspx>and in > the threads tab I can see that the WLAN poll is what causes our users' game > lagging every 10 seconds. Our users are otherwise happy with our servers > because its the best quality pings they can get. However, that goes to > trash because of this poll. > > I skimmed through the bearer code and it looks impossible to workaround. > Is there something I missed? Or, should I create a bugreport for this? > > On Fri, Apr 24, 2015 at 4:48 PM, Andre Barth <andre.ba...@autodesk.com> > wrote: > >> Are you on Wifi (only)? >> >> We did run into similar issues on 5.3.2 (but I don't know whether this is >> related to your problem, too): The reason for our problem was/is, that ... >> >> "...it looks as if Qt’s “Network Configuration Manager” was polling the >> Wifi engine every 10 seconds for available networks. >> >> This in turn will call Windows’ WlanScan function which “… requests a >> scan for available networks on the indicated interface…” >> (see qnativewifiengine::requestUpdate, line 517) " >> >> Could be right, could be wrong - but this is what I've seen. >> >> Thanks, >> Andre >> >> -----Original Message----- >> From: interest-bounces+andre.barth=autodesk....@qt-project.org [mailto: >> interest-bounces+andre.barth=autodesk....@qt-project.org] On Behalf Of >> Nuno Santos >> Sent: Friday, April 24, 2015 1:01 PM >> To: Interests Qt >> Subject: [Interest] Q(Tcp/Udp)Socket stall >> >> Hi, >> >> I have passed the last 48 hours trying to understand a problem I was >> having with sockets. I was driving crazy but I think I finally reached a >> conclusion. Let me summarize: >> >> - Program A that sends data via sockets to localhost >> - Program B, built in Qt, receives data via QUdpSocket (I have also tried >> with QTcpSocket and the problem is the same). >> >> Program A sends constant size messages (76 bytes) each 60 ms. >> Program B receives the message and prints the latency between the current >> message and the last message. >> >> The result is the following: >> >> latency 19 >> latency 60 >> latency 60 >> latency 60 >> latency 51 >> latency 59 >> latency 80 >> latency 61 >> latency 60 >> latency 58 >> latency 50 >> latency 60 >> latency 59 >> latency 538 >> latency 0 >> latency 43 >> latency 58 >> latency 62 >> latency 79 >> latency 50 >> latency 50 >> latency 61 >> latency 61 >> latency 58 >> latency 60 >> latency 80 >> latency 31 >> latency 59 >> latency 1946 >> latency 0 >> latency 54 >> latency 61 >> latency 49 >> latency 59 >> latency 52 >> latency 60 >> latency 58 >> latency 60 >> latency 60 >> latency 60 >> latency 60 >> latency 60 >> latency 51 >> latency 533 >> latency 0 >> latency 16 >> latency 60 >> latency 60 >> latency 60 >> latency 50 >> latency 60 >> latency 61 >> latency 60 >> latency 59 >> >> >From time to time, in a pretty much regular way, the message receiving >> stalls and the latency is printed as being around 500ms/1000ms/2000ms. >> >> Even the interval between stalls is pretty much regular, around 14 >> packets. Each packet is 76 bytes, which multiplied by 14 gives around 1024. >> >> I didn’t rest while I couldn’t who the fault was. So I did a C program >> that receives data on a socket from the same source to ensure that there >> was no stalls or latency. The result was NO STALLS. >> >> Then, I have done another program, this time built in Qt, to send data >> via QUdpSocket to the program B. The result was: STALLS again! >> >> My conclusion is that somewhere in the underlying Qt socket handling, >> there is a buffer, to be filled before readyRead is sent. >> >> Is anybody familiar with this problem and know how to work around it? Is >> this a setting that can be tweaked? >> >> This doesn’t seem normal or acceptable. >> >> Thx, >> >> Regards, >> >> Nuno Santos >> _______________________________________________ >> Interest mailing list >> Interest@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/interest >> _______________________________________________ >> Interest mailing list >> Interest@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/interest >> > > > > -- > Shantanu Tushar (UTC +0530) > shantanu.io > -- Shantanu Tushar (UTC +0530) shantanu.io
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest