[Interest] Q(Tcp/Udp)Socket stall

[Shantanu Tushar]

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.blasche at 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.com at qt-project.org
> <interest-bounces+alexander.blasche=theqtcompany.com at qt-project.org> on
> behalf of Shantanu Tushar <shaan7in at 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.Barth at 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.com at qt-project.org [mailto:
>> interest-bounces+andre.barth=autodesk.com at 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 at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>> _______________________________________________
>> Interest mailing list
>> Interest at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>
>
>
> --
>  Shantanu Tushar    (UTC +0530)
> shantanu.io
>



-- 
Shantanu Tushar    (UTC +0530)
shantanu.io
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20150430/f81171c0/attachment.html>