Hi, I have just isolated the problem.
In program B i’m also using libimobiledevice to browse for attached iOS devices. The functions that establishes a callback for devices attach/detach notifying was causing the stall. I think I will need to move this object to a different thread. Nuno > On 24 Apr 2015, at 15:24, Nuno Santos <nunosan...@imaginando.pt> wrote: > > Well, > > I was just trying to create an small example to send to the list and it > didn’t show the problem. > > I think I have just found the problem. The B program I mentioned has Bonjour > browsing service implemented by a really old Qt project > BonjourServiceRegister. > > I have commented it out and the problem disappeared. I don’t know why, but it > seems that Bonjour Service Register is provoking this stall. Can anyone guess > why? > > Does anyone know any more recent Qt wrapper for dns_sd? > > Regards, > > Nuno Santos > Founder / CEO / CTO > www.imaginando.pt <http://www.imaginando.pt/> > +351 91 621 69 62 > >> On 24 Apr 2015, at 13:11, Klank, Michael <michael.kl...@amk-antriebe.de >> <mailto:michael.kl...@amk-antriebe.de>> wrote: >> >> We had the same problem. >> setSocketOption(QAbstractSocket::LowDelayOption, 1); solved the problem >> >> Von: interest-bounces+michael.klank=amk-antriebe...@qt-project.org >> <mailto:interest-bounces+michael.klank=amk-antriebe...@qt-project.org> >> [mailto:interest-bounces+michael.klank=amk-antriebe...@qt-project.org >> <mailto:interest-bounces+michael.klank=amk-antriebe...@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.ba...@autodesk.com >> <mailto: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> >> [mailto: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 <mailto:Interest@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: >> i...@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: i...@amk-antriebe.de >> > > _______________________________________________ > 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
