[Interest] Q(Tcp/Udp)Socket stall

Shantanu Tushar shaan7in at gmail.com
Wed Apr 29 14:23:52 CEST 2015


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20150429/cd6e470a/attachment.html>


More information about the Interest mailing list