[Interest] Q(Tcp/Udp)Socket stall

Nuno Santos nunosantos at imaginando.pt
Fri Apr 24 13:23:34 CEST 2015


This happens, even with Wifi turned off. 

Nuno

> On 24 Apr 2015, at 12:18, 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20150424/e6d5196d/attachment.html>


More information about the Interest mailing list