Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Sep 1995 12:23:12 -0700 (PDT)
From:      "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com>
To:        bde@zeta.org.au (Bruce Evans)
Cc:        bde@zeta.org.au, current@freebsd.org, rkw@dataplex.net, wollman@lcs.mit.edu
Subject:   Re: Which SUP files are available and where ?
Message-ID:  <199509191923.MAA06086@GndRsh.aac.dev.com>
In-Reply-To: <199509191035.UAA04813@godzilla.zeta.org.au> from "Bruce Evans" at Sep 19, 95 08:35:03 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> 
> >> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509191923.MAA06086>