[linux-dvb] Re: we might be losing multicast packets

[Jeremy Hall <jhall@maoz.com>]

Hello,

On a different stream, no matter what the RECV buffer size is, I get

recvfrom: resource temporarily unavailable

and now when I look at my ifconfig stats, I see that there are 3 errors, 
all three of them framing errors, although I have seen resource 
temporarily unavailable many more times than 3.

Under what circumstances could the 2.4 driver produce this error?

_J

In the new year, Jeremy Hall wrote:
> Hi Johannes,
> 
> In the new year, Johannes Stezenbach wrote:
> > On Sun, Feb 06, 2005 at 08:51:45PM -0500, Jeremy Hall wrote:
> > > I am using current dvb-kernel v2.4 branch with a dvb/s ff card.  I am 
> > > using dvbnet that I found in some apps dir on my hd, no telling how old it 
> > > is, but I run dvbnet -p pidnum to get a dvb0_0 and another one for dvb0_1.
> > > 
> > > The datarate for dvb0_1 is small, like 64k, so I don't see losing packets, 
> > > but dvb0_0 is like 7 or 8 megabits per second.
> > 
> > What do you mean by "datarate for dvb0_0"? The bandwidth on that PID
> > or just the multicast you want to receive?
> 
> It is hard to tell what the bandwidth is for each multicast group, since 
> there are 3 groups transmitting, eventually I'd like to pull all three at 
> once.  The srate is 7955, so I'm guessing maybe the whole stream is about 
> 10 or 11 meg a second.  This would mean each stream, if evenly divided, 
> might be around 4mb each, although if one isn't transmitting, the others 
> might spin up their datarate to use available bandwidth.  How would you 
> recommend I determine this accurately?
> 
> > The DEBI bandwidth on FF cards is limited (don't have exact figures).
> > If you just want a part of the packets on that PID you could try
> > hw_sections=1 to reduce the used DEBI bandwidth (but there are reports
> > that hw section filters stop on overflow conditions).
> > 
> My experience with hw_sections=1 has been (in the past) that the arm 
> crashes because I'm trying to process too many sections at once or am not 
> able to keep up or some other nonsense.
> 
> > Or the bottleneck is elsewhere: Does ifconfig report dropped packets?
> 
> no, it doesn't show dropping packets.
> 
> > Did you try to set SO_RCVBUF (see socket(7))?
> > 
> I just ran with SO_RCVBUF set to 2mb, 4mb, and now am running with 8mb.  I 
> have had improving results with each size increase.  That still seems 
> quite high to set the receive buffer.
> 
> _J
> 
> > Johannes
> > 
> > 
> 
> 
>