[Interest] Q(Tcp/Udp)Socket stall

[Klank, Michael]

We had the same problem.
setSocketOption(QAbstractSocket::LowDelayOption, 1); solved the problem

Von: interest-bounces+michael.klank=amk-antriebe.de at qt-project.org [mailto:interest-bounces+michael.klank=amk-antriebe.de at qt-project.org] Im Auftrag von Nuno Santos
Gesendet: Freitag, 24. April 2015 13:24
An: Andre Barth
Cc: Interests Qt
Betreff: Re: [Interest] Q(Tcp/Udp)Socket stall

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


________________________________

Persönlich haftende Gesellschafterin: AMK Verwaltungsgesellschaft mbH, Kirchheim/Teck
Geschäftsführer: Dr. Thomas Lützenrath, Jochen Breßmer, Dr. Ulrich Viethen
Registergericht Stuttgart HRB 230208; HRA 230681

Die in dieser E-Mail enthaltenen Informationen sind vertraulich. Diese E-Mail ist ausschließlich für den Adressaten bestimmt und jeglicher Zugriff durch andere Personen ist nicht zulässig. Falls Sie nicht der beabsichtigte Empfänger sind, ist jegliche Veröffentlichung, Vervielfältigung, Verteilung und sonstige in diesem Zusammenhang stehende Handlung untersagt und unter Umständen ungesetzlich. Falls Sie diese E-Mail irrtümlich erhalten haben, leiten Sie sie bitte weiter an die folgende E-Mail-Adresse: info at amk-antriebe.de

The information in this e-mail is confidential. It is intended solely for the address and access to the e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or committed to be taken in reliance on it, is prohibited and may be unlawful. If you have received this e-mail in error please forward to this e-mail-address: info at amk-antriebe.de