From owner-freebsd-current Sun Nov 12 14:08:01 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA06192 for current-outgoing; Sun, 12 Nov 1995 14:08:01 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA06180 for ; Sun, 12 Nov 1995 14:07:52 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id JAA24105; Mon, 13 Nov 1995 09:04:23 +1100 Date: Mon, 13 Nov 1995 09:04:23 +1100 From: Bruce Evans Message-Id: <199511122204.JAA24105@godzilla.zeta.org.au> To: dyson@freefall.freebsd.org, jgreco@brasil.moneng.mei.com Subject: Re: ISP state their FreeBSD concerns Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk >> > 8. File creation (particularly directories) appears to be slow compared >> > to other BSD-like systems. They say the stats for INN and CNEWS >> >... >> >> I am working on this stuff right now. Give me benchmarks!!!! I'll >> do what I can. Almost anything that creates files and writes to them takes several times longer to write the metadata than to write the files. E.g., (1) time cp -pR /usr/src /usr/src~ time rm -rf /usr/src~ (2) mount /dev/fd0 /mnt cp -pR /dev /mnt/dev >I have a little suite of programs I use for performance testing. The tests >are absolutely slanted towards news server type applications. The one in >particular I will quote is "small-file-write.c", a program that writes 10000 >files in subdirectories, creating the subdirectories if needed (much like a >news server would do). So the "first run" numbers include the time needed >to make dirs: >Slowaris 5.4 - SS10/30 - 64MB RAM (SCSI II, reasonable drive) >10000 files in 332 seconds - first run >10000 files in 20 !!! 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 :-( :-( :-( !! >FreeBSD 1026-SNAP - ASUS SP3G AMD 486DX4/100 + NCR810 - 48MB (SCSI II, SLOW >drive, fs mounted -o async) >10000 files in 569 seconds - first run :-( :-( >10000 files in 207 seconds - second run :-( :-( :-( !! You need fast drives to get such high speeds for the first run :-]. I tried with only 1000 files because 10000 would take too long and my file systems are small: FreeBSD current - no-name 486DX/33 + no-name IDE - 8MB (SLOW Samsung IDE drive): 1000 files in 161 seconds - first run (161.00 real 0.25 user 6.96 sys) :-( 1000 files in 19 seconds - second run ( 18.92 real 0.22 user 1.52 sys) :-( Same except mounted async: 1000 files in 66 seconds - first run (66.09 real 0.20 user 5.26 sys) :-( 1000 files in 20 seconds - second run (19.93 real 0.20 user 1.58 sys) :-( Same except running my 1991-ish version of Minix (fs last changed Dec 17 1994) (Minix v1 fs, inherently async) 1000 files in 4 seconds - first run (4 real 0.20 user 3.06 sys) :-> 1000 files in 1 seconds - second run (1 real 0.20 user 0.86 sys) :-> The times under Linux with the Minix (v1) fs should be similar. Linux 1.2.13 - unknown 486DX2/66 + unknown SCSI - >32MB (unknown drive) - ext2fs (inherently async), high load average: 1000 files in 16 seconds - first run (16.19 real 0.19 user 3.18 sys) :-| 1000 files in 2 seconds - second run ( 2.37 real 0.19 user 2.06 sys) :-| It's interesting that your times for the second run are relatively worse than mine. Perhaps the larger number of files makes the caches ineffective. --- Even for reading and writing normal files on a much better system, FreeBSD is slower than Minix :->. For reading and writing `bin', where bin is a copy of /usr/src/bin (created on a new file system in the case of FreeBSD): System Machine Bus/Controller Drive ------ ------- -------------- ----- FreeBSD-cur-a 486DX2/66 16MB VLB/BT445C SCSI Quantum XPG34301 (5.3MB/sec) FreeBSD-cur-b 486DX/33 8MB ISA/no-name IDE slow IDE (1.4MB/sec) Minix-old same as for FreeBSD-cur-b System fs fs state ------ -- -------- Minix-old Minix v1 48MB, old, nearly full FreeBSD-cur-a ffs 1.2GB, new, nearly empty FreeBSD-cur-a-a ffs async same except for mount option FreeBSD-cur-b ffs 75MB, old, nearly full FreeBSD-cur-b-a ffs async same except for mount option times and (data) throughputs (cold buffer cache) ------------------------------------------------ System cp -pR bin bin~ rm -rf bin~ tar cf /dev/null bin ------ --------------- ----------- -------------------- Minix-old 15 171K/sec 3 6 428K/sec FreeBSD-cur-a-a 17.04 150K/sec 2.58 6.54 393K/sec FreeBSD-cur-a 31.50 81K/sec 13.36 6.62 388K/sec FreeBSD-cur-b-a 31.76 80K/sec 1.97 8.68 296K/sec FreeBSD-cur-b 76.87 33K/sec 25.94 21.16 121K/sec (!!) I thought I left throughputs of 25K/sec on my XT with its 20MB hard disk and 105 ms seek time. Reading really is 2.5 times slower for the sync tar test. Something must be thrashing. Bruce