Date: Fri, 2 Feb 1996 17:19:44 -0600 (CST) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: curt@emergent.com (Curt Mayer) Cc: freebsd-hackers@freebsd.org Subject: Re: Watchdog timers (was: Re: Multi-Port Async Cards) Message-ID: <199602022319.RAA12386@brasil.moneng.mei.com> In-Reply-To: <199602020444.UAA00420@bluewhale.emergent.com> from "Curt Mayer" at Feb 1, 96 08:44:26 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Optional: NVram for acceleration of NFS &c. sockets > > > and a battery for 4-8 Mb ram. Possibly with a little > > > clock to do refresh so DRAM could be used. (cheaper) > > > > This is something we NEED, in order to do any sort of serious NFS service. > > PrestoServe style devices are handy in many scenarios in addition to NFS - > > news servers and other systems where lots of metadata updates are happening. > wrong. this is a trivial way to speed up metadata writes. there is a > software-only way called using an intent log. > > A once-boss of mine has a nfs fileserver that uses a homebrew filesystem > running in user space on a cluster of pc's running freebsd that eats an > auspex's lunch. how? logging. got parity protection, too.. I have yet to see any software-only mechanism (such as Sun's Online DiskSuite) keep pace with a PrestoServe. I would like very much to see a software-only mechanism that could. ODS manages about 60% of the throughput allowed by a PrestoServe, by my not-very-fair-or-impartial-just-off-the-top-of-my-head benchmarks. Looking back a half a year, we had the following benchmarks... Slowaris 5.4 - SS10/30 - 64MB RAM (SCSI II, Barracuda drive) 10000 files in 249 seconds - first run 10000 files in 13 !!! seconds - second run Slowaris 5.4 - SS10/30 - 64MB RAM - PrestoServe (SCSI II, Barracuda drive) 10000 files in 76 seconds - first run 10000 files in 12 seconds - second run FreeBSD 2.0.5R - ASUS SP3G AMD 486DX2/66 + NCR810 - 8MB (SCSI II, reasonable drive) 10000 files in 620 seconds - first run :-( :-( 10000 files in 310 seconds - second run :-( :-( :-( !! Now I did talk with some folks about this and it turned out that my test was close to a worst case scenario for FreeBSD... I was walking the directory tree in a most nasty manner and it was really grinding the system. To be fair let's re-examine those benchmarks of a half year ago on a FreeBSD-2.1.0R system... FreeBSD 2.1.0R - ASUS P54XE4??? Intel P100 + NCR810 + 96MB (SCSI II, Barracuda drive) 10000 files in 540 seconds - first run 10000 files in 98 seconds - second run, improvement! Okay, let's mount -o async and repeat.. 10000 files in 257 seconds - first run 10000 files in 97 seconds - second run Wellll. Interpretation: even with -o async we're as slow as molasses compared to at least one other contemporary OS. And -o async doesn't buy us anything apparent for the second run, as opposed to a sync mount... now of course my benchmarks may still unintentionally be a FreeBSD worst-case, so I'll invert the ordering so that it is more "system friendly": Slowaris 5.4 - SS10/HS11 - 64MB RAM (SCSI II, Barracuda drive) 10000 files in 288 seconds 10000 files in 23 seconds Slowaris 5.4 - SS10/30 - 64MB RAM - Online DiskSuite (SCSI II, Barracuda drive) 10000 files in 130 seconds 10000 files in 34 seconds Slowaris 5.4 - SS10/HS11 - 64MB RAM - PrestoServe (SCSI II, Barracuda drive) 10000 files in 83 seconds 10000 files in 26 seconds FreeBSD 2.1.0R - ASUS P54XE4??? Intel P100 + NCR810 + 96MB (SCSI II, Barracuda drive) 10000 files in 265 seconds 10000 files in 16 seconds FreeBSD 2.1.0R - ASUS P54XE4??? Intel P100 + NCR810 + 96MB (SCSI II, Barracuda drive, -o async) 10000 files in 159 seconds 10000 files in 17 seconds Some of the Solaris variance may be due to differing processor speeds. We should be able to come closer to the Solaris numbers. There is no unfair cache bashing going on or anything. > > I think it should probably be handled as a separate entity from the rest of > > this (it's not something everyone wants by a long shot). > agreed. the best reason for nvram is a persistent console log. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602022319.RAA12386>