[...]
> > Short of upgrading to gigabit, or trying to juggle 2+ NICs for one
> > NFS mount (can that be done?) on both ends, that's where it mostly
> > ends.
> 
> I'm not sure... would be interesing to know the answer tho.

It'd be cute, though by the time I stuff more cards in 2 or more
computers (then I guess I'd need a switch with more ports...(^&),
it might as cheap to just migrate to gigabit.  (The client machine
already has gigabit on the motherboard, so I'd need one card and one
switch to get started.)


 [...]
> > > For further giggles, try the benchmarks using just a single disk... 
> > 
> > Did that one, too.  Here's a sample:
> > 
> > wd1a, softdep mount
> [snip]
> > Some things are signiicantly lower.  Mostly it's about the same.
> 
> Ya...  one would hope that RAID 0/ccd would be quite a bit faster 
> than just a single spindle.

(^&


 [...]
> > I had actually tried at 64 stripe size.  In fact, reviewing, it seems
> > that one of those performed fairly close to ccd for seeks (a little over
> > 220 seeks/sec) and otherwise was about as good as I was going to get:
> > 
> > raid 0 (ffs; softdeps; 2 cables; 64 stripe)      
> > Version  1.03       ------Sequential Output------ --Sequential Input- --Rando
> > m-
> >                     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks
> > --
> > Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %
> > CP
> > cyclopes       300M 35343  89 39401  36 15060  16 27032  93 78939  54 223.5  
> >  2
> >                     ------Sequential Create------ --------Random Create------
> > --
> >                     -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete
> > --
> >               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %
> > CP
> >                  16  1176  97 +++++ +++ 14202  99  1171  95   959  99  3120  
> > 93
> > cyclopes,300M,35343,89,39401,36,15060,16,27032,93,78939,54,223.5,2,16,1176,97
> > ,+++++,+++,14202,99,1171,95,959,99,3120,93
> 
> Ya.. I suspect it'll take a bunch of work to get faster than this... 

I can do a little better on some of the numbers (e.g., 85MB/sec for
sequential input/block), but I'd have to check to see if that forced a
drop in other numbers.

In most ways, it's way better than I'll get over my network, though.
(^&


 [...]
> Where was the start of the newfs'ed partition?  I.e. did it start at 
> block 0 or block 63 or ??? in the disklabel?  If it didn't start at a 

No.  I originally had it at 63, but ccd complained about it when
I configured.  Looking around, I saw something about a *cylinder* of
reserved space, and the NetBSD (well, disklabel) concept of a cylinder
for that disk seemed to be 1008 blocks.  So I reserved 1008 blocks, but
either that still wasn't enough or my arithmetic was off, since I
still got complaints.  So I went with 1648, which was generous and
lopped off the lower 4 digits of the disk's size.  (^&  This made
the warnings go away.  (I think that I asked about this, or at
least mentioned it, in my initial post.  It's been mentioned before.)

Then when I went to try vinum (missing/unconfigured device,
even after building a kernel with vinum support), and RAID, I left
the disklabels alone (1648 offsets).

Should I tell disklabel to use a different cylinder size?  Or
should I have ignored ccd's complaints?

Or should/can I just tell raidctl to use /dev/wd1 as a whole?


> multiple of the stripe width (64), then move it to 0 or a multiple of 
> the stripe width.

I'll try that.  (^&


 [...]
> If you're going to be limited by network, "make it as fast as you can 
> without too much effort", and then not worry about it :)

Yeah.  I have been going along that track, and thinking that I've
about exceeded my budget for effort on this.  But I'm willing to
play a little more before I stop.


Thanks for the advice and help.

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/