PDA

View Full Version : QUdpSocket and priority



Pavlya
8th April 2013, 14:44
Hello. I write UDP server. Serever is started in the separate thread and receives packets every 20 mS. Thread has QThread::TimeCriticalPriority. Server reads data after readyRead() signal. When I start web-browser (Google Chrome or Firefox), packets are delayed. And packets received after delay time (delay spike). The delay time, which measured by WireShark is 250 mS. The delay time, which measured in the slot (I use QElapsedTimer), where I read data, is 800-900 mS. I think, delay is genereted in the socket thread (in the network module), which works with native socket for OS. When I start server, i see two new thread. First thread has TimeCriticalPriority (it's my thread). And second has normal priority (I think it's qt network thread, which started with qsocket). Can I increase the priority of this thread?

Santosh Reddy
10th April 2013, 10:15
Can I increase the priority of this thread?
Increasing the thread priority will not help, in fact even using a thread will not help because you still rely on readyRead() signal which has nothing to with thread, and not effected by thread priority.

I am afraid the packet itself is delayed, so your server cannot do much about it, moreover expecting a packet every 20ms over ethernet (or any shared network) is not practical.

Pavlya
10th April 2013, 12:45
I probably do not accurately described the situation.

1 I have server, which receives audiostream. Period between audio (rtp) packets is 20mS. It is ordinary period for rtp packets.
2 I run WireShark and I see packets and period between arriving. Also I see maximum delay between packets.
3 I run server (WireShark works too). Maximum delay between packets is the same in the Wireshark and in the server.
4 I run browser and delay is changed. 250 mS - in WireShark, 800 mS - in the server.

I made an experiment. Instead QUdpSocket I used native socket API (socket(), select() ...) in the server thread. I was running browser and I got the same delay in the WireShark and in the server. I think, when QUdpSocket is created, in the Qt network module is started thread, which monitors the state of the native socket and sends events. This thread has normal priority. (When I run server with QUdpSocket I see one additional thread.(I use "Process explorer" application for Windows).
And I want to increase priority of this thread or any way to speed up the network module.

Santosh Reddy
10th April 2013, 13:18
I think, when QUdpSocket is created, in the Qt network module is started thread, which monitors the state of the native socket and sends events. This thread has normal priority. (When I run server with QUdpSocket I see one additional thread.(I use "Process explorer" application for Windows).
And I want to increase priority of this thread or any way to speed up the network module.
I don't think QUdpSocket creates a thread. Please check again you might be looking at some other thread.

Pavlya
10th April 2013, 20:28
You are right. Work with sockets controlled in the events loop :) Thank you for answers.

ChrisW67
11th April 2013, 08:32
Whether your program is threaded or not you cannot make your CPU deliver network data if it is busy loading a browser and starting the tens of threads typically needed there. Network jitter like this is why streaming media players buffer some input before they start playing, and presumably also manage a buffer in the audio/video hardware which will play while the CPU is busy. All it may take is to buffer a second or two to cover a potential 500 millisecond glitch. The RTP timestamp is there to allow playback at correct intervals and the sequence allows detection/handling of lost packets (how is up to the receiver).

Qt does use a thread internally to its network code for HTTP (http://peter.hartmann.tk/blog/2012/02/inside-the-qt-http-stack.html) but that should not affect UDP unless Qt5 has done some more in this area.