[linux-dvb] Re: EOVERFLOW

[Guido Draheim <guidod-2003-@gmx.de>]

Vincent Bernat wrote:
> OoO Lors de la  soirée naissante du lundi   28 juin 2004, vers  17:19,
> Guido Draheim <guidod-2003-@gmx.de> disait:
>
>
> > I have those buffer overruns as well, the problem however seems to be
> > deeper as I can not find a relation to the cpu pressure ("high charge")
> > but instead there is a statistic peak around 2gb boundaries of data
> > reads (kernel 2.4 system). Since highlevel video decoder tools can get
> > away with partial packet loss, one can recommend to modify the tool
> > chain to ignore the eoverflow diagnostic.
>
> If it was the case, I suppose the problem would be cyclic, but with
> some tools (vls), it appears all the time. While with others, it never
> appears (dvbstream).
I dunno whether dvbstream does cover up this problem somehow. I can
sometimes provoke an eoverflow with switching channels or enable/disable
tuner on one of the cards in the system. That's all part of the idea that
it is really some timing hickup, and I suppose the data streaming does
something add to that on its own at around 2gb points.

> > If you do have some time, may be you could play a bit with the ring
> > buffer implementation in dmxdev_buffer_write. Personally I'd love to
> > see a module option to set the ring buffer size to a higher value and
> > then see what happens. Perhaps the interrupt hickup can be covered
> > up with that as long as we don't get to the real cause.
>
> There is a ring buffer implementation in dmxdev_buffer_write ? I see
> one in dvb_frontend_add_event. This one seems to be fine (the
> EOVERFLOW never comes from this one).
Sure there is a ring buffer - members ..pwrite and ..pread of the struct
dmxdev_buffer are the read-point / write-point and the implementation
of dmxdev_buffer_write dmxdev_buffer_read ensures a wrap around
possibly cutting an incoming data block into two partial writes (split).
The ..pwrite pointer will always be ahead or equal to ..pread (the fill
state of the buffer is ..pwrite-..pread). The ..size of the ring buffer seems
to be set really in dvb_dvr_open via #define DVR_BUFFER_SIZE which is
hardcoded to (10*188*1024). I wonder very much why that is not really
sufficient and the buffer gets really filled up to merily one 188 block left.

Of course, the reasons may be manifold - the first target is always a
user appliation being starved on the read() or its own writeout. Yet I do
not have any time to check another theory with packets from the hard-
ware coming in in quick bulk groups. As far as I understand the dvb cards
have an internal buffer as well that can hold ts packets being moved from
there to the vmalloc'd ring buffer for direct reads via the device file handle.

Sorry that I can not give much help to it, I am verrrrrry low on time, - so far
I can live with ignoring eoverflow diagnostics in user land. It's just not nice
to see and I suppose a real problem for people doing network streaming
which I do not even attempt.

cheers,
-- guido                                  http://google.de/search?q=guidod