Hello again !
Processing is done from the irq handler (well, actually from
a tasklet triggered by irq). For a 30Mbit/s stream
this buffer holds ~50ms worth of TS packets which are then pushed
into a larger ringbuffer where it waits to be picked up by read()
from the demux/dvr device. If the DMA buffer overflows you have
an irq/tasklet latency problem.
Now what I didn't say is that the buffer size is "on the edge", so there
are only spurios buffer overflows,
about 100 in 5 minutes - enough to have bad dropouts, though.
Maybe the buffer has to be increased just a little bit, to hold about
60ms ? I'll try it out this weekend.
When the system has no I/O load at all - except writing out six 3
Mbit-MPEG-2 streams to disk -
the DMA buffer usage is most time 327 or 348 TS packets - so about 33%.
I now changed my source to have a module option for setting the buffer size.
I will test this thing this weekend.
The second thing I'll try then is to re-enable my local APIC in bios,
maybe APIC will also work again if the DMA buffer is bigger.
If it works, I'll generate a patch.
When it works with a slightly bigger buffer, I'd change the default
value, too.
The most important change will be to issue a warning when the buffer is
used more than 90% - this should save people with similar problems
debugging time ...
the buffers following the DMA buffer actually do report overflows.
Regards,
Ingo Schneider.
P.S.: The weired thing is that my 400 Mhz K6 with 128 MB RAM never had
these problems with the same cards ...
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
