>I've just set up a Quadra 950 I found at the town dump as our home server.
>It came with 24 MB of memory. I've added a 4GB Seagate Barracuda as the root
>disk and a 36GB Quantum 7200 RPM SCSI disk as the /Users disk.
>
>I hope to use this machine as the central repository for our MP3's, but I'm
>a bit worried about the performance of the Apple File Protocol in netatalk.
>When I did a finder copy of our MP3 collection to the NetBSD server, I only
>got a data-rate of about 333 KBytes/sec. The source machine was a PowerMac
>7200 with a 266 MHz G3 and 256 MB DRAM running OS 9.1, over 100baseT
>ethernet to a 10/100 switch, then to the Quadra 950 running NetBSD. Since
>the source machine was running OS 9.1, I presume I was running AFP over
>TCP/IP.

That would depend on whether you're using netatalk-umich or 
netatalk-asun. Adrian Sun's patches to netatalk are what gave it the 
AFP over IP capability. When you're connected to the server, click on 
the mounted volume & do a get info. That will tell you how it is 
connected.

>I had hoped to see something closer to the 1MB/sec theoretical maximum for
>10baseT ethernet. I'm a bit worried about trying to serve multiple MP3
>streams using AFP on this machine. The NetBSD machine seemed relatively idle
>during the transfer - CPU and memory utilization were low (single digits),
>and disk I/O's were steady at about 16 per second, which should be only
>about 15% to 20% utilization for the disk. Is the bottleneck in the 10 Mb/s
>ethernet port on the Quadra 950 - would I get substantially better
>performance if I hunted down a 100baseT Nubus card? Or is there a
>performance bug in the 1.5.2 NCR driver?

I don't know why you would have expected to get close to the 
theoretical maximum...100baseT didn't come built-in on Macs until the 
B&W G3's, to give you a perspective on wrt the "mediocrity" of the 
machines that you're using. Granted we're all using sub-par 
computers, this being the mac68k port...just don't expect them to 
perform like current. My Macintosh SE has a 10baseT card, but I don't 
expect it to be saturated ;-).

>Or is there some other bottleneck? I'm surprised the CPU utilization wasn't
>higher - maybe I misread the vmstat display.

It doesn't take much CPU to blindly hand data from the SCSI to the 
Ethernet...you're not computing or running anything.

>On another note, I had some difficulty installing 1.5 on this machine, as
>the Installer apparently doesn't support partitions greater than 500 MB. It
>will install on a 1 GB or a 2 GB partition, but running fsck after booting
>shows a terribly corrupted file system. The 1.5.1 Installer shows the same
>behavior. I ended up creating 500 MB partitions for root, /var, and /usr in
>order to install, and using the remaining 2.5 GB on the root disk for
>nothing in particular. Is this a well-known limitation of the Installer?

For installing on larger drives, it's generally best to use the 
installer to install ker.tgz, etc.tgz, and as much of base.tgz as you 
can. Then build devices. Then use the installer's minishell to cpin 
the rest of the tarballs (and the whole of base.tgz). Then you can 
boot into BSD to use "tar --unlink -zxpf yadda.tgz /" for the rest of 
the tarballs. This would also be the best way to upgrade...get the 
tarballs into the BSD filesystem & issue that command. The --unlink 
will let it overwrite even programs that are running, and the -p 
keeps the file permissions that they should have.

Hope this helps,
Mike
Bikers don't *DO* taglines.