From owner-freebsd-hackers Wed Nov 29 00:59:39 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA22365 for hackers-outgoing; Wed, 29 Nov 1995 00:59:39 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA22358 for ; Wed, 29 Nov 1995 00:59:27 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA10586 for ; Wed, 29 Nov 1995 09:56:06 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA02676 for freebsd-hackers@freebsd.org; Wed, 29 Nov 1995 09:56:06 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id IAA14169 for freebsd-hackers@freebsd.org; Wed, 29 Nov 1995 08:55:45 +0100 From: J Wunsch Message-Id: <199511290755.IAA14169@uriah.heep.sax.de> Subject: Re: Anyone keen to help me get a Phillips CDD 521 Recorder working? To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Wed, 29 Nov 1995 08:55:44 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199511282345.PAA09388@cozumel.tcs.com> from "Douglas Ambrisko" at Nov 28, 95 03:45:16 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1293 Sender: owner-hackers@freebsd.org Precedence: bulk As Douglas Ambrisko wrote: > > So the data has to come from a hard drive > attached to the SCSI bus. A lot of burners use a separate SCSI bus for the > CD-R so it's doesn't have to worry about any other device holding the > bus. Also people use AV disks to eliminate the problem of thermal > recalibration. I think the problem with thermal recalibration is the biggest one. On the other hand, with something like `team' doing the data shuffling, you could use the RAM as an additional cache. One process in constantly reading the input file, and this one will choke when the disk performs a thermal recalib. Since the output process reads buffered data, it will not starve immediately. The only requirement is that the average CD burn rate is much slower than the average disk read rate, but with 600 KB/s for the burner, this doesn't seem to be a problem. Nevertheless, the driving process should run at rtprio, so its getting the highest probability of grabbing the CPU whenever it needs it (which is seldom anyway, since both of its sub-processes are i/o- bound). As always, crappy hardware will make you unhappy. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)