Date: Wed, 26 Apr 2000 09:21:16 -0700 From: Kent Stewart <kstewart@3-cities.com> To: Narvi <narvi@haldjas.folklore.ee> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Michael Bacarella <mbac@nyct.net>, Alfred Perlstein <bright@wintelcom.net>, Kevin Day <toasty@dragondata.com>, hackers@FreeBSD.ORG Subject: Re: Double buffered cp(1) Message-ID: <3907177C.5CFEC69A@3-cities.com> References: <Pine.BSF.3.96.1000426165333.74116e-100000@haldjas.folklore.ee>
next in thread | previous in thread | raw e-mail | index | archive | help
Narvi wrote: > > On Sat, 22 Apr 2000, Matthew Dillon wrote: > > [snip] > > > disk itself is probably the bottleneck. Disk writes tend to be > > somewhat slower then disk reads and the seeking alone (between source > > file and destination file), even when using a large block size, > > will reduce performance drastically verses simply reading or writing > > a single file linearly. Double buffering may help a disk-to-disk > > file copy, but I doubt it will help a disk-to-same-disk file copy. > > > > Wouldn't coping the file to another disk and then back to the original one > than just a simple copy in some cases be faster then? > > After all, you are saving a lot of head seeks. The problem is that if they are on the same data channel then you have conflicts for access to the data bus. Some products like SCSI are better suited for that environment but data still only flows one direction at a time. On the old ISA bus, you could just about watch data flow with an analyzer plugged on to a new interface card. We had one interface card that the data ready went true before the data was stored into the on_card memory. The cpu was fast enough that I could watch the bits in the memory change. I couldn't get good data until memory had stablized. Cray's were really good at handling data in 1988 because they had 100MB/s + 1000MB/s data channels. I'm not sure how wide the data channels were. It seems like the 100MB/s was 16 bytes wide and the 1000 MB/s was 32 bytes wide. Their high speed disks were striped to provide 20MB/s continuous transfers. Getting data off of the disk was far more important to throughput than writing the data. The queued read/write ability of the scsi drives made life better but the disk was still the bottle neck to high speed data. The PCI bus probably shares that honor on the modern PC. It is only 4 bytes wide and relatively slow. The new 64bit PCI bus will help but that is a long way from the 256 bit or 512 bit wide Cray data channels that Cray was using in 1988. A while back I was given some parameters that could change the time required for a 4.0-Stable buildworld. The only option that improved my buildworld time was "CFLAGS= -pipe". It saved about 140u seconds. The option "-Os" made a buildworld take 1/3 longer. I also did an installworld (and kernel) of a -Os system and that really didn't change the times. The jump for version 4.0 on a Celeron 433a was 3560u + 800s to 4950u + 800s. There are still some options to try but "softupdates" didn't help. The buildworld using an UW scsi for /usr/obj was actually a little bit longer than using a UDMA66 ATA HD. The scsi was flat out at 8MB/s where as the UDMA HD was capable of 12-14MB/s. The Maxtor UDMA drive had a 2MB cache and the IBM uw was much smaller. Kent -- Kent Stewart Richland, WA mailto:kstewart@3-cities.com http://www.3-cities.com/~kstewart/index.html FreeBSD News http://daily.daemonnews.org/ SETI(Search for Extraterrestrial Intelligence) @ HOME http://setiathome.ssl.berkeley.edu/ 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?3907177C.5CFEC69A>