<HTML>
<HEAD>
<TITLE>BasicTaskScheduler not reading fast enough?</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Hi,<BR>
<BR>
I have an RtspServer implementation that reads from many pipes and sends out to its clients. The pipes are fed externally from other threads in the same process. Each pipe could be receiving up to 10 Mbits of video data. Each thread that writes to the pipe has a buffer that is filled from another receiving thread. If the buffer is full when the receiving thread tries to add, my program outputs an error message, empties the buffer and continues.<BR>
<BR>
What I am concerned with is that the BasicUsageEnvironment might not be fast enough to receive and process and send all the incoming data on all of these pipes. There is a specific use case when the a client of the server initiates 16 additional connections (causing 16 new streams / pipes), and then a another client then closes 16 previous connections. This is a “redistribution” of a pool of recording devices. In this situation, the number of pipes will jump from 16 to 32, and then a minute or so later back down to 16 again. Remember each of these pipes is handling multiple megabits of data.<BR>
<BR>
The behavior I am seeing is that the incoming threads are not able to add to the buffers that are being written to the pipe in the second thread. The threads that write to the pipe are not timing out on the writes (I have set a write timout on the pipe), indicating to me that the writing thread and live555 thread is able to process all the data, just not fast enough for the incoming buffers to be freed.<BR>
<BR>
I have spent a lot of time analyzing the SingleStep function in the BasicTaskScheduler that I am using. I added an optimization that seemed to improve things slightly: Basically, if the timeToDelay is 0 before the select, it means that there are “alarms” ready to process (Which is usually the packets ready to send in MultiFramedRTPSink). In this case I call fDelayQueue.handleAlarm immediatly. Whilst this helps, in the situation I described above the same error can still occur. <BR>
<BR>
I thought about creating my own TaskScheduler that iterates over the all the sockets after the select has returned indicating there is data ready on the sockets, rather than returning after processing one socket. Ross, any reason you did not do this in your original implementation? I think it would be to allow the watch variable to be checked really frequently, correct?<BR>
<BR>
I was wondering if anyone has any advice that might help me with this. In my opinion, it should be able to handle it. The library seems fairly efficient in most cases, but I was wondering if anyone has pushed as much data through the BasicTaskScheduler as I am doing (around 150 - 300Mbits). If so, what has their experience been?<BR>
<BR>
Jerry Johns has previously mentioned on this list that he lowers the thread priority that is containing the live555 library, and this seems to help with performance (particularly CPU load). I generally avoid using any thread prioritization as I tend to believe the kernel knows more about scheduling than I do. Has anyone got any more feedback on this? I have thought above raising the thread priority to see what happens.<BR>
<BR>
Sorry for the long email, I am trying to provide as much data as possible for you to answer my questions,<BR>
<BR>
Regards,<BR>
Stuart<BR>
</SPAN></FONT>
<BR>
- ------------------------------------------------------------------------------<BR>
Confidentiality Notice: The information contained in this transmission is legally privileged and confidential, intended only for the use of the individual(s) or entities named above. This email and any files transmitted with it are the property of Pelco. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you receive this communication in error, please notify us immediately by telephone call to +1-559-292-1981 or forward the e-mail to administrator@pelco.com and then permanently delete the e-mail and destroy all soft and hard copies of the message and any attachments. Thank you for your cooperation. <BR>
- ------------------------------------------------------------------------------<BR>
</BODY>
</HTML>