Date: Wed, 29 Nov 2000 17:53:32 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dkelly@grumpy.dyndns.org (David Kelly) Cc: tlambert@primenet.com (Terry Lambert), questions@FreeBSD.ORG Subject: Re: ATAPI CD-RW drive: how? Message-ID: <200011291753.KAA18886@usr08.primenet.com> In-Reply-To: <200011291257.eATCutS56173@grumpy.dyndns.org> from "David Kelly" at Nov 29, 2000 06:56:55 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> > I think the lockup is starting up team and dd at rtprio 5 to > > keep the CDROM writer streaming, regardless of whatever else > > is running on the system. > > The lockup I was refering to was with cdrecord under Irix and FreeBSD, > without any external rtprio or dd or team or nothing. Cdrecord has to > run as root to access the kernel priority mechanism. And at least in > versions around 1.6 when the cdrecord starts on the recorder it locks > out everything (think under Irix 6.3 the mouse pointer would even stop, > but the network would still ping) at the start of the burn procedure. I can explain the mouse pointer stopping. The VM system and buffer cache on System V derived systems are cannibalistic; you will see the same lockup of your X server when linking a large program, if you are using the standard linker, since the standard linker will map all your object files, and seek around like a maniac. In UnixWare, this was combatted by putting in a new scheduling class called "fixed", which guaranteed the X server would get a certain percentage of the available time slices. This was a gross hack, since what it really ended up doing was giving the X server the necessary CPU cycles to thrash its own pages back into core, rather than preventing the thrashing in the first place. SGI actually produced the first "CD piracy system", in that it was the first shipment of a CDROM (Hitachi) in the US which could read audio tracks off as digital data. > I have never found a need for team. Burned over 100 CD-R's at 4x on an > overloaded SCSI P-133 w/24MB with X, Netscape, and exmh2 open. Back in > the days of FreeBSD 2.2.8. Often burned one on the Yamaha CDR-100 on > SCSI while verifying the previous with the built-in Gateway CDROM. And > often was reading data from 8mm and/or 4mm at the same time for the next > CD-R. SCSI is different; it doesn't have the problems that IDE has, since you can target a one track transfer, disconnect, and the drive can resynchronize as necessary (eat rotational latencies between seeks from one track to another, between intervening whole track writes). This is the same reason that floppy disk controller and IDE interfaced tape drives can have problems, while SCSI tape drives merely hack up and rescan (most of these drives are helical scan drives). The use of team is really a convenient kludge, since the data streaming assumption isn't really strictly valid. You probably don't need cdrecord to grab a high priority for burning data CD's, with SCSI, since some even multiple of the data block size will end up being your page size. The same is probably generally true of ATAPI, but IDE controllers are finicky, and I don't know that I'd trust them to not break things up incorrectly or introduce a latency, unless you had the ATAPI burner on its own controller so that it was not itself competing with reads from your IDE hard drive source data, which could introduce a latency in the middle of a transfer (no SCSI disconnect = no intereleaved IDE commands to multiple drives). The problem is that the latency could be unintentional, as a result of swapping or other processes doing disk I/O. You could probably deal with this by giving the CD burner carte balnche' on getting its I/O demands satisfied, and ensure that all I/O was either whole track units, or chained as whole track units. This would probably be best implemented with cooperation from the device driver. For audio and other data, you probably need the priority boost to ensure that when cdrecord writes data that straddles a page boundary, that all data is available, or that a fault can be processed in sufficient time. You actually don't need this, if you know that the pages are LRU managed, and you prefetch the pages by reading a byte before hand. Vadim Antonov did a similar trick with the 8k double buffering of the BSDi floppy tape driver, in the kernel: when a rewrite was called for, there was always data available. So properly engineered code probably doesn't need a raised priority in any case (it's not necessary to keep a CDROM recorder streaming, it's only necessary to ensure that (1) you are writing in track increments, and (2) the pages you are writing from won't result in a fault. To do this for ATAPI, and handle the "HD + burner, one a master, one a slave on the same controller" case, you'd need to ensure all burner writes were handled synchronously after forcing the reader pages into core, also synchronously. This could get real slow, real fast, but you could detect device major/minor, and at least put out a diagnostic message to the user as to why this was the case. > The only coasters I made had obvious optical defects from dust or > scratches. Learned to look for dust before burning. I've created a coaster or two (at work; not locally, yet) from use of inferior media, purchased in bulk. I mostly stick to the brand name stuff (Maxell, Teac, etc.) these days, and haven't seen a failure on a SCSI burner since. It's probably not worth bullet-proofing the recording process to function without the priority boost, at least on FreeBSD. On IRIX, it'd probably be worth it, but if the system were being simultaneously loaded with a link or other buffer-cache thrashing process, you'd have to expect the occasional coaster -- but with a sufficiently thrashed system, you'd have to expect that even with the priority boost, from the occasional inversion. If you were doing a lot of audio work, or CDI/VideoCD/DVD work, prefaulting and writing in track units would probably be a prudent precaution. Anyway, I'm entirely up and running now with burncd + rtprio, so I'm happily burning CDs with my internal laptop CD-RW drive. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011291753.KAA18886>