jonathan@dsg.stanford.edu wrote:
> 
> >We are trying to build the best File Server we can possibly make with
> >NetBsd on intel architecture. We built servers under FreeBSD but we are
> >not satisfied with the NFS perfs, and Free Bsd in general. (PIII 500, 4
> >U2W 18Go stripped HD, and 3coms/digital NIC).
> 
> The NFS implementation in both systems -- in any *BSD system, AFAIK --
> is derived from the 4.3-Reno NFS implementation, done by Rick Macklem
> and others.  I have not tried FreeBSD's NFS, but I wouldn't expect
> major gains going from one NFS implementation to the other.
> 

Actually, we could only use our disks as 80M/s on FreeBSD, with the U2W
Adaptec Card, 
cause we haven't got any card that works with Netbsd yet (we should get
Advansys', and Qlogic's soon).
On free BSD, we are faster than the NetApp on big files, but much slower
on small ones.
Thats why we think the problem comes from nfs or FreeBSD file system,
and why we want 
to try different file systems on NetBSD.

> >We are looking for the best U2W card and the bests NIC (Network
> >interface card) 100Mb available and supported under NetBSD.
> 
> >Adaptecs U2W aren't supported as far as we know.
> 
> Correct. It's on the TODO list for 1.5, but nothing there yet.
> 
> >Tekkrams and Intra-Server Cards (ncr) see our disks in 40Mb/s and spit
> >lots of errors while detecting the disks.
> 
> If the NCR-based hardare is supposed to support it, and you have the
> proper LVD cabling and termination, then that sounds like a bug.
> Please send a PR with complete version info. (SCSI is not my area of
> expertise, but someone should look at it before 1.5.).
> 
> >We aren't satisfied with 3com NIC too, we got lots of collisions. So we
> >are looking for good Ethernet Card, with big buffers, and good support
> >under netbsd.
> 
> First things first: getting lots of collisions sounds like you have a
> full-duplex mismatch between your cards, and the upstream switch/hub.
> What kind of switch are you using?  The early Cisco 10/100 ports
> have/had a real problem autosensing full-duplex.  The simple solution
> is to hardwire the ports at both end to 100Mbit, full-duplex.

We tried different configurations, we had to force the switch and the
NIC to 100Mb and 
tried Half-duplex and full-duplex, and had some times better perfs with
Switch in fullduplex and NIC in Half...
(Still on FreeBSD..)

> 
> Also, exactly which 3com card do you have? iirc, the early 3c905 cards
> had a 3com proprietary PHY, which wasn't handled as well as the
> mass-market MII-attached PHY chips.  I've used a 3c905B on NetBSD.
> Performance is comparable to an Intel Etherexpress Pro/100B.  The
> original 21140-AF and 21142 Tulip boards were also good performers,
> but hard to find these days.  The 21143 reportedly has a performance
> problem with the builtin PHY. Recent 2114x clones (NetGear?)  are
> reported to use a new Broadcom PHY chip, which NetBSD doesn't handle
> quite right, yet (though Jason has an evaluation board).
> 
> Last, Jason Thorpe recently rototilled the MII/PHY handling, to
> resolve some problems I (and others) had switching between autosense
> and hardwired modes.  Exactly which version of NetBSD were you running
> when you had these collisions? Does going to -current as of late
> November help?
> 
> >We are trying to beat a NetApp. We are close to the NetApps performance
> >with our free BSD PCs, wich are a lot cheaper, and that we know a lot
> >better. We know (at least hope) that we can do better with NetBSD.
> 
> Good luck, sounds like a cool thing to try.  But iirc, the NetApp
> servers started life as a NetBSD-derived OS on running on 21164A
> Alpha CPUs, so you should be able to get pretty close.
> 
> I just hope your FreeBSD performance didnt depend on using SMP,
> since NetBSD doesn't support SMP right now.

Not at all... We got only one PIII 500, and what slows us is not the CPU
its 
the NIC and the disks, so we dont plan on upgrading the cpu for now.

> 
> >If anyone can help us with good tips...
> 
> The mid-80s advice used to be, get an NVRAM board so the servers can
> log writes to NVRAM and reply, rather than waiting till NFS write
> requests go all the way out to disk before replying. I have no idea if
> the NetApps do that, but if they do, then write latency will be hard
> to beat.

I think the NetApp do that, but i'm not sure it helps a lot.
We think that we should get a NIC with bigger buffers so it interupts
the system 
less often and permits the OS process w/ larger data at each interupt.

sam.