[Live-devel] NIC overruns on IBM stbx25xx embedded platform

[Richard Flude]

Thanks Ross for the prompt reply.

 >>The MediaMVP device uses a smc91111 nic, with only a
 >> tiny on-chip buffer. I've tried increasing the kernel's RX buffers
 >> with no improvement.

 > Are you sure you did that properly?

I've been trying an number of things for many days hoping I could get 
the client to successfully receive the stream. I tried 2 methods with 
varying buffer sizes but with no difference. Firstly setting the values 
via /proc :

echo 1048576 > /proc/sys/net/core/rmem_max
echo 524288 > /proc/sys/net/core/rmem_default

and restarting my rtsp client application, and secondly modifying the 
code
setting the buffer size using setsockopt().

Both cases the new buffer size was confirmed with getsockopt()
and printed to stdout..

 > In particular, after a successful call to "subsession->initiate()", 
you can do the following:
 >        int rtpSocketNum = 
subsession->rtpSource()->RTPgs()->socketNum();
 >        increaseReceiveBufferTo(*env, rtpSocketNum, 
desiredReceiveBufferSize);

Certainly a more elegant way to do it!

I've tried this but again with no improvement. I can confirm the value 
returned by the call is
desiredReceiveBufferSize (and looking at the src this indicates a 
successful call).
I used a buffer size of 2,000,000 for video as you suggested (and a 
couple of other sizes).

I'm assuming of course that if getsockopt() is returning the correct 
value the kernel is using
this value (seems a fair assumption).

Is it practical to reduce the rtsp server's burst rate to a value the 
MVP can handle or is their something else I should try?

Thanks again

Richard