[Live-devel] BasicTaskScheduler not reading fast enough?

[Rawling, Stuart]

Hi,

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.

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.

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.

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.

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?

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?

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.

Sorry for the long email, I am trying to provide as much data as possible
for you to answer my questions,

Regards,
Stuart


- ------------------------------------------------------------------------------
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 at 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. 
- ------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091026/c7f4ea1b/attachment.html>