Date: Mon, 5 Feb 1996 02:32:57 +1100 From: Bruce Evans <bde@zeta.org.au> To: curt@emergent.com, jgreco@brasil.moneng.mei.com Cc: freebsd-hackers@freebsd.org Subject: Re: Watchdog timers (was: Re: Multi-Port Async Cards) Message-ID: <199602041532.CAA02747@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>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.
My 1991 version of Minix beats it easily. Yes, it uses async metadata
writes. Don't complain.
Minix 1.6.25++ - 486DX/33 - 8MB RAM (slow IDE drive, fresh 137MB fs)
(2MB buffer cache)
10000 files in 17 seconds - first run
18.00 real 1.36 user 15.43 sys (time /tmp/prog)
3.00 real 0.00 user 0.80 sys (time sync)
10000 files in 11 seconds - second run
11.00 real 1.48 user 9.25 sys (time /tmp/prog)
0.00 real 0.00 user 0.03 sys (time sync)
>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
>...
>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
I thought -current would be much better with -o async. However:
FreeBSD-current - 486DX2/66 - 16MB RAM (BT445C Quantum Grand Prix drive,
1/3 full 1G fs)
(too-small buffer cache (nbuf = 247) + vm buffers that I don't understand)
10000 files in 468 seconds - first run
467.76 real 0.87 user 17.19 sys (time /tmp/prog)
0.33 real 0.01 user 0.03 sys (time sync)
10000 files in 295 seconds - second run
295.34 real 0.87 user 12.86 sys (time /tmp/prog)
0.33 real 0.02 user 0.02 sys (time sync)
>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":
>...
I don't think I have the benchmark with the inverted order.
Under Minix, the 10000 inodes and directory entries occupy about
(64 + 16) * 10000 = 800000 bytes = about 800 1K buffers. The disk isn't
touched for the rerun. Under FreeBSD, the cache(s) thrash despite the
system having twice as much RAM.
time find . >/dev/null # second run
Minix: 3.00 real 0.71 user 2.58 sys
FreeBSD: 18.80 real 0.54 user 1.33 sys
time du >/dev/null # second run
Minix: 8.00 real 0.88 user 7.20 sys
FreeBSD: 42.25 real 0.78 user 4.89 sys
No async metadata updates are involved here. Access timestamps are
delayed until the next sync for both fs's. FreeBSD is slower because it
has to physically reread all the metadata.
time rm -r *; time sync
Minix: 23.00 real 1.51 user 17.81 sys
3.00 real 0.00 user 0.60 sys
FreeBSD: 38.39 real 1.08 user 13.03 sys
0.86 real 0.00 user 0.03 sys
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602041532.CAA02747>