From owner-freebsd-current Tue Sep 19 12:23:58 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA25592 for current-outgoing; Tue, 19 Sep 1995 12:23:58 -0700 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA25586 for ; Tue, 19 Sep 1995 12:23:54 -0700 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id MAA06086; Tue, 19 Sep 1995 12:23:13 -0700 From: "Rodney W. Grimes" Message-Id: <199509191923.MAA06086@GndRsh.aac.dev.com> Subject: Re: Which SUP files are available and where ? To: bde@zeta.org.au (Bruce Evans) Date: Tue, 19 Sep 1995 12:23:12 -0700 (PDT) Cc: bde@zeta.org.au, current@freebsd.org, rkw@dataplex.net, wollman@lcs.mit.edu In-Reply-To: <199509191035.UAA04813@godzilla.zeta.org.au> from "Bruce Evans" at Sep 19, 95 08:35:03 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2705 Sender: owner-current@freebsd.org Precedence: bulk > > >> I thought that the CPU ran out of power before the pipe was half full, > >> even doing raw data movement for nfs. > > >I have done iozones over NFS on 100BaseTx networking and seen numbers > >well in excess of 3MBytes/s reading (forget about writting, we all > >know sync nfs is dog slow at that). > > 3MB/s is less than half full. That was all the disk could do that I was using for the source :-(, the bottlneck was not the network, it was being 3/4 of the way out on a DSP3053L disk where the transfer rate of the disk is slighly over 3MB/s. > >> For sup it will have to traverse > >> file systems so it will be hard to get more than 1MB of throughput per > >> file system. > > >File system bandwidth is not a problem. Again, I can produce iozone > >results in excess of 6MB/sec quite easily on local fast disks. > > iozone is not representative of anything except huge sequential accesses > to huge sequential files. Which represents my install mode for cloning systems pretty well, cd /mnt; restore rf /SkyRsh/a/root.dmp;... and since that is a lot of what I do with my systems iozone is representative of what I do. > On a disk that has an iozone speed of 4-5MB/s > here, the throughput of `cvs -Q co bin' is 30K/sec (2562K, 85.05 real, > 12.69 user, 20.96 sys) (the cvs repository is on a separate disk). The > throughput of `cp -pR bin bin~' is 79K/sec (2562K, 33.41 real, 0.10 user, > 3.04 sys). The throughput of `cp -pR bin separate_slower_disk/bin' is > 56K (2562K, 46.50 real, 0.10 user, 3.50 sys). Abysmal results like this > are typical for accessing small files. Why is this? And what can be done to speed it up? Is this all Meta Data overhead? I think you are lossing on the write side here, not the read side. How fast does cp -pR go when the destination is a MFS? I don't use cp -pR, I use cpio -pdamu --block-size=16 and that cruzzes along pretty well, but I have never measured the speed, but I do know it is signifacantly faster than cp -pR. > > >> Is it as fast as cvs co ;-). > > >A _LOT_ faster when you are talking about the two running over local > >ethernet. NFS gets in the way a bit. Sup is slow over long RTT links > >due to the 2 RTT needed for many of the things it does, it is blazing > >fast on local networks (and smokes on 100Mb/s networks :-)). > > Cancel the previous `;-)'. sup should be faster than cvs co but it can > hardly be faster than cp -pR, and cp -pR is _slow_. Then some work should go into speeding cp -pR up, or atleast finding exactly what makes that so slow. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD