From: Alessandro Suardi <alessandro.suardi@gmail.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Mathieu Fluhr <mfluhr@nero.com>,
torvalds@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: 2.6.13 brings buffer underruns when recording DVDs in 16x (was Re: "Read my lips: no more merges" - aka Linux 2.6.14-rc1)
Date: Wed, 14 Sep 2005 13:12:11 +0200 [thread overview]
Message-ID: <5a4c581d050914041222b033cb@mail.gmail.com> (raw)
In-Reply-To: <20050914035840.3fbd6b95.akpm@osdl.org>
On 9/14/05, Andrew Morton <akpm@osdl.org> wrote:
> Mathieu Fluhr <mfluhr@nero.com> wrote:
> >
> > On Wed, 2005-09-14 at 01:30 -0700, Andrew Morton wrote:
> > > Mathieu Fluhr <mfluhr@nero.com> wrote:
> > > >
> > > > According to the MMC documentation, you can thoeriticaly send at most
> > > > 65535 (16 bits int) blocks in one WRITE(10) CDB. This would means
> > > > sending a buffer of ~127 MB on case of writing a mode 1 data track (2048
> > > > bytes per block)...
> > > >
> > > > Now, practically, it is really not safe to send more than 64 KB per CDB
> > > > (Mostly device related). And with such values, you have the following:
> > > > - at 100 Hz -> 64 KB * 100 = 6400 KB/s <=> ~4.62x DVD
> > > > - at 250 Hz -> 64 KB * 250 = 16000 KB/s <=> ~11.55x DVD
> > > > - at 1000 Hz -> 64 KB * 1000 = 64000 KB/s <=> ~46.20x DVD
> > >
> > > But that implies that there's some piece of code somewhere (could be
> > > userspace, could be kernel) which is doing a timer-based sleep() in between
> > > each CDB. It shouldn't do that - it should be using the disk
> > > controller's completion interrupt for synchronisation.
> > >
> >
> > Hummm... you are definitly right. So forget my calculations. I does not
> > mean anything. Honestly, I was just trying to find an explanation why it
> > was working with HZ set to 1000 and not with HZ set to 250 or 100.
> >
> > > What userspace application are you using to write the DVDs, and is it
> > > possible to test a different one?
> >
> > I am using NeroLINUX to make my tests. I also tried out
> > cdrecord/growisofs, but I was not even able to burn at 16x (I get some
> > error message that max speed is 10x... and nothing more).
> >
> > But there seems to be somehow some I/O limitation: I configured a pure
> > 2.6.13.1 to have HZ set to 100. I then made a 3 GB compilation with
> > small files (about 3 to 5 MB each).
> > - If you burn this directly without creating a temp ISO image in 4x
> > (5440 KB/s), you will get buffer underruns soon or later... (about 2%)
> > - If you create an ISO image out of the compilation (using mkisofs or
> > other tool), and then burn this image, then no buffer underruns occurs.
> >
> > After that, you speed up your recorder with this image (for example at
> > 8x), you will have these buffer underruns back again.
> > And as I tell you, no such stuff is happening when HZ is set to 1000.
> >
>
> OK, so you get underruns with NeroLINUX at 8x, and it should be possible to
> test cdrecord at 8x, yes? If that works then it's time to take a look at
> what NeroLINUX is doing..
>
> erp, it's payware. strace, maybe?
Data point... recent 2.6.13 (possibly after 2.6.13-final) allow
my puny K7-800 256MB RAM to burn DVDs with growisofs
at 8x, whereas earlier releases would peak at 8x then step
back to 4x. Currently burn starts at 5x and goes up steadily
to 8x in a couple of minutes, then stays there until the DVD
is done. I never tested 16x - actually I haven't yet owned a
16x capable DVD disc... but I doubt my system could burn
that fast - 8x is already a blessing ;)
--alessandro
"All it takes is one decision
A lot of guts, a little vision to wave
Your worries, and cares goodbye"
(Placebo - "Slave To The Wage")
next prev parent reply other threads:[~2005-09-14 11:12 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-13 3:34 "Read my lips: no more merges" - aka Linux 2.6.14-rc1 Linus Torvalds
2005-09-13 3:54 ` Alejandro Bonilla Beeche
2005-09-13 3:59 ` Keith Owens
2005-09-13 4:03 ` Alejandro Bonilla Beeche
2005-09-14 5:16 ` Alejandro Bonilla Beeche
2005-09-14 16:28 ` Jeff Garzik
2005-09-14 16:40 ` Alejandro Bonilla
2005-09-14 16:43 ` Linus Torvalds
2005-09-14 16:52 ` Alejandro Bonilla
2005-09-15 0:48 ` Alejandro Bonilla Beeche
2005-09-13 14:27 ` Linus Torvalds
2005-09-13 6:28 ` more fallout from ATI Xpress timer workaround (was: Linux 2.6.14-rc1) Cal Peake
2005-09-13 20:04 ` Jean Delvare
2005-09-13 6:33 ` "Read my lips: no more merges" - aka Linux 2.6.14-rc1 Sonny Rao
2005-09-13 7:04 ` Eric Dumazet
2005-09-15 4:06 ` David S. Miller
2005-09-15 4:22 ` Linus Torvalds
2005-09-15 20:13 ` Benjamin LaHaise
2005-09-15 20:32 ` Linus Torvalds
2005-09-15 21:08 ` Eric Dumazet
2005-09-15 20:41 ` Eric Dumazet
2005-09-13 7:34 ` Udo A. Steinberg
2005-09-13 10:40 ` Mathieu Fluhr
2005-09-13 11:15 ` Helge Hafting
2005-09-13 15:14 ` Linus Torvalds
2005-09-13 17:01 ` Mathieu Fluhr
2005-09-13 17:15 ` Linus Torvalds
2005-09-13 18:12 ` Mathieu Fluhr
2005-09-13 19:11 ` Linus Torvalds
2005-09-14 8:11 ` 2.6.13 brings buffer underruns when recording DVDs in 16x (was Re: "Read my lips: no more merges" - aka Linux 2.6.14-rc1) Mathieu Fluhr
2005-09-14 8:30 ` Andrew Morton
2005-09-14 10:32 ` Mathieu Fluhr
2005-09-14 10:58 ` Andrew Morton
2005-09-14 11:12 ` Alessandro Suardi [this message]
2005-09-14 15:04 ` "Read my lips: no more merges" - aka Linux 2.6.14-rc1 Bill Davidsen
2005-09-14 23:38 ` Redeeman
2005-09-13 18:34 ` Roland Dreier
2005-09-13 18:46 ` Linus Torvalds
2005-09-13 21:32 ` Horst von Brand
2005-09-13 19:57 ` Rafael J. Wysocki
2005-09-14 15:31 ` Bill Davidsen
2005-09-14 22:56 ` Matthew Garrett
2005-09-14 17:33 ` Bill Davidsen
2005-09-14 17:45 ` Bill Davidsen
2005-09-14 21:47 ` Henrik Persson
2005-09-14 23:20 ` Jesper Juhl
2005-09-16 19:51 ` Henrik Persson
2005-09-14 22:11 ` 2.6.14-rc1 on ATI hangs when executing _STA and _INI methods Peter Osterlund
2005-09-14 22:27 ` Linus Torvalds
2005-09-14 22:41 ` Peter Osterlund
2005-09-14 23:27 ` "Read my lips: no more merges" - aka Linux 2.6.14-rc1 Redeeman
2005-09-16 7:44 ` Tomasz Torcz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5a4c581d050914041222b033cb@mail.gmail.com \
--to=alessandro.suardi@gmail.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mfluhr@nero.com \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox