Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: VDR recording glitches



To support Ralph's idea, this is one of my computers used for VDR test:

CPU: Pentium 100
RAM: 84Mbyte
Disk: Quantum 6.4G Udma2 (old).

The PC is running a 0.06 driver with buffer of 8Mbytes and *all* the
optimisations of hdparm (32bit io, dma, unmask irq, write-caching enable,
multisector reads of 16 sectors).

I have absolutely no problems recording/playback (actually there's a minor
unrelated issue when using pause in playback).

BTW: On another application (huge file server) I'm running a brand new
PIII800 with 20Gig Quantum hard disks and the disk access will kill the
processor and the rest of the computer if I don't turn on hard disk
optimizations. So... do your homework on optimizing you system :-))

Plamen.

> -----Original Message-----
> From: Ralph Metzler < [mailto:rjkm@netcologne.de]
> Sent: Wednesday, September 20, 2000 3:44 PM
> To: linux-dvb@linuxtv.org
> Subject: Re: VDR recording glitches
>
>
> Michael Holzt writes:
>  > On Wed, Sep 20, 2000 at 02:06:08PM +0200, Carsten Koch wrote:
>  > > So, I'd say we're seeing a driver bug (or at least a
>  > > driver weakness) here.
>  >
>  > I still recommend increasing the buffer size as suggested by
> Klaus. Fixed
>  > the problem 100% for me (even without DMA).
>
> There are still many explanations for this behavior.
>
> - a driver weakness, i.e. it blocks other (IDE) IRQs for too long
>
>   In the new version the conversion routines maybe should go into a
>   bottom half or tasklet. But they were not in the old version where
>   the problem already was present.
>   Before there only was a write to a ring buffer inside the IRQ
>   which should be fast enough.
>
>   The MMU of the SAA7146 might be used to make a very fast ringbuffer
>   which would reduce IRQ times to almost nothing.
>   But this will have to wait until after the API change.
>
> - other IRQs block the DVB IRQ which causes dropped AV_PES packets
>
>   This does not seem to be the case for you (Michael) since you have
>   no problems without DMA but with bigger buffers)  but it might be
>   for others.
>   Here setting the unmaskirq feature of hdparm (hdparm -u ...) might
>   help if no DMA is available.
>
>
> - disk caching
>
>   The disk might be fast anough but data is first written to the
>   buffer memory. When the cache is full it suddenly has to write very
>   much data and might not be able to free the MPEG buffer quickly enough.
>   Does VDR support uncached writing?
>
>
> Ralph



Home | Main Index | Thread Index