[plug] Burning DVD's Drifts Time

Sun Nov 5 08:39:24 WST 2006

On 11/5/06, Timothy White <weirdit at gmail.com> wrote:
> I think the issues has something to do with high interrupts. When I
> burn DVD's, my clock starts to slow down. And when I say slow down, I
> mean it looses 30 seconds a minute. (So a minute in the computer
> world, is a minute and 1/2 in the real world). Also, when I type, I
> occasionally get double or triple characters even when I'm typing
> normal, suggesting keyboard interrupts are being delayed. (II debated
> leaving all the doubles and triples in so you can get an idea of how
> annoyinggg it is!)
>
> I've been burning 40 DVD's from a master image, and at the start, I
> could get 8x burning speed (16x cheap media), but now, I've not been
> able to get above 4x as the initial start speed, which averages 2x
> actually burning speed.
>
> The computer is an Athlon64 3000+, with plenty of memory (1 Gb), and
> the DVD burner is on it's own IDE bus, as the master of the second
> channel. All on it's lonesome. I have 2 HDD's on the master bus, and
> 2 on the SATA bus. The DVD master image is on one of the SATA drives.
>
> Reading off the SATA drives isn't a problem or bottleneck.
> $ hdparm -tT /dev/sda
>
> /dev/sda:
>  Timing cached reads:   3968 MB in  2.00 seconds = 1982.95 MB/sec
>  Timing buffered disk reads:  162 MB in  3.01 seconds =  53.85 MB/sec
> $ hdparm -tT /dev/sdb
>
> /dev/sdb:
>  Timing cached reads:   3956 MB in  2.00 seconds = 1978.60 MB/sec
>  Timing buffered disk reads:  190 MB in  3.01 seconds =  63.03 MB/sec
>
> Memory isn't an issue
>
> $ free -m
>              total       used       free     shared    buffers     cached
> Mem:          1001        988         13          0          6        480
> -/+ buffers/cache:        501        500
> Swap:         4009          0       4008
>
> To give you an idea of the drift, at "1 second intervals" running
> ntpdate against a local time server, you can see when the DVD finished
> burning.
>
> 5 Nov 07:17:24 ntpdate[8651]: step time server 192.168.0.1 offset 0.663251 sec
>   5 Nov 07:17:26 ntpdate[8653]: step time server 192.168.0.1 offset 0.551902 sec
>   5 Nov 07:17:27 ntpdate[8655]: adjust time server 192.168.0.1 offset
> 0.455908 sec
>   5 Nov 07:17:29 ntpdate[8657]: step time server 192.168.0.1 offset 0.859248 sec
>   5 Nov 07:17:30 ntpdate[8659]: adjust time server 192.168.0.1 offset
> 0.483909 sec
>   5 Nov 07:17:32 ntpdate[8661]: step time server 192.168.0.1 offset 0.883246 sec
>   5 Nov 07:17:33 ntpdate[8663]: adjust time server 192.168.0.1 offset
> -0.000085 sec
>   5 Nov 07:17:34 ntpdate[8665]: adjust time server 192.168.0.1 offset
> -0.000049 sec
>   5 Nov 07:17:35 ntpdate[8667]: adjust time server 192.168.0.1 offset
> -0.000074 sec
>   5 Nov 07:17:36 ntpdate[8669]: adjust time server 192.168.0.1 offset
> -0.000052 sec
>
> $ uname -a
> Linux linjeni 2.6.18linjeni #3 SMP Wed Sep 27 21:13:32 WST 2006 x86_64 GNU/Linux
>
> So what I'm really asking, is firstly does anyone know how to stop the
> clock drifting during high interrupt periods (i.e. burning DVD's). ntp
> normally keeps it in sync fairly well once the DVD stops burning, but
> when doing 40 in a row, your quickly  more than a hour out!
>
> Also, does anyone have ideas to get it burning quicker. It was going
> at 8x, no idea why real speed isn't getting above 2x now :( It's made
> for a really long weekend.
>
> Thanks
>
> Tim
> --
> Linux Counter user #273956
> Don't email joeblogs at scouts.org.au
> _______________________________________________
> PLUG discussion list: plug at plug.org.au
> http://www.plug.org.au/mailman/listinfo/plug
> Committee e-mail: committee at plug.linux.org.au
>

I have a few pointers but nothing concrete (probably not what you
wanted to hear). Firstly, enabling DMA on the device if it isn't
already may help speed/interrupts issues. The only other idea I have
is to ensure you're using the correct kernel IDE driver for your
chipset, and not those horrible (but highly compatible) generic ones.
I had a laptop working horrible slow to due using the generic drivers
and had similar issues to what you're getting (except the mouse was
the bad boy in this scenario -- seizing etc for periods of time, no
clock drift though). I fixed it by custom compiling a kernel with the
ide drivers for that chipset built in (the older Sarge kernel didn't
support this chipset variant at the time) and suddenly speed picked up
by magnitudes. You may try that.

Tomasz