Date: Fri, 23 Feb 2001 09:39:43 +0200 From: Peter Pentchev <roam@orbitel.bg> To: Torbjorn Kristoffersen <sgt@netcom.no> Cc: "Michael C . Wu" <keichii@peorth.iteration.net>, FreeBSD-Hackers <hackers@FreeBSD.org> Subject: Re: IOmega ZIP problem Message-ID: <20010223093943.A1899@ringworld.oblivion.bg> In-Reply-To: <20010222131933.C20955@peorth.iteration.net>; from keichii@iteration.net on Thu, Feb 22, 2001 at 01:19:33PM -0600 References: <Pine.BSF.4.30.0102221930510.685-100000@hal.netforce.no> <20010222131933.C20955@peorth.iteration.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 22, 2001 at 01:19:33PM -0600, Michael C . Wu wrote: > On Thu, Feb 22, 2001 at 07:40:16PM +0100, Torbjorn Kristoffersen scribbled: > | Hi I'm using 4.2-RELEASE, with a parallel port ZIP drive (100M). > | Whenever I copy a large file from the zip drive (for example /dev/da0s1), > | the "cp" process eats 98% of the system resources. What's behind all this? > | Is there a way to fix it? > | > | 711 root 54 0 280K 168K RUN 0:45 93.87% 93.21% cp > | > | A 'renice' won't help. > > > That's natural with "parallel". No way around it. To clarify a bit, parallel port hardware depends on the system processor doing all the data transfers, every single byte, and spending even more time checking if it's time for the next byte to go. There's no DMA, there's not even a controller you can tell 'here's a 512-byte block, let it fly'. There's no way around it indeed. G'luck, Peter -- This would easier understand fewer had omitted. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010223093943.A1899>