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