Path: utzoo!utgpu!watserv1!watmath!att!rutgers!usc!samsung!munnari.oz.au!uniwa!DIALix!bernie
From: bernie@DIALix.oz.au (Bernd Felsche)
Newsgroups: comp.sys.amiga.tech
Subject: Filesystem Speeds (was Re:  GVP Trade-in)
Summary: Any statistics available?
Keywords: SCSI, GVP
Message-ID: <558@DIALix.UUCP>
Date: 31 Aug 90 04:01:20 GMT
Expires: 31 Aug 90 00:00:00 GMT
References: <552@DIALix.UUCP> <14069@cbmvax.commodore.com>
Reply-To: bernie@DIALix.oz.au (Bernd Felsche)
Followup-To: comp.sys.amiga.hardware
Organization: DIALix Services, Perth Western Australia
Lines: 62

In article <14069@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes:
>In article <552@DIALix.UUCP> bernie@DIALix.oz.au (Bernd Felsche) writes:
[..quote about AmigaDOS FS deleted..]
>
>	Actually, it does far better at things like that than say, Unix, does.

I presume that you're talking about System V.x here.  Berkeley FFS
does heaps better, as does SunOS, which caches block disk I/O into
all available RAM.

>There's been quite a bit of discussion at times in comp.arch about filesystem
(I read that newsgroup as well.)
>speeds, and even a 68000 amiga with a DMA controller can keep up there with
>pretty high-power Unix boxes.  One of the reasons is that FFS allows us to do
>direct transfers to the end destination, instead of having to xfer to a buffer
>pool and then cpu copy to destination (like most unix implementations).

Direct transfer is a most efficient approach, and UNIX does allow 
this approach in limited circumstances (raw device i/o).  It is used
almost exculsively by high performance databases, not only for
speed, but also for integrity, as UNIX 'blocking i/o' is write-delayed,
and the application could never be sure if i/o was successful, and
when it actually happened.

>	If you want to see what they can do, check out floppies under 2.0
>trackdisk and FFS.  I've seen >20K/sec reads.  Note that the theoretical
>maximum is ~24K/sec, not including seek and settle times or any other overhead.
>Trackdisk does 22K/sec via the device interface (including seek/settle) under
>2.0.
How about hard disks?  CPU time will be a larger proportion of total
time, so it will be more significant.
>
>	Even on a 68000, sustained transfer speed is limited by disk speed
>in most cases, not processor handling of the data.  A 680{2,3}0 will improve
>rates, but not immensely.

Can you give some statistics on disk i/o for the A3000 running
AmigaDOS vs A3000 running UNIX V.4?  I'd prefer to compare apples
(ooops) I mean Amigas with Amigas.

Also, I'd be interested in how a well-worn filesystem performs; one
that has quite a lot of fragmentation (>10%), for both DOS and
UNIX.  Which UNIX filesystem does AMIX(?) use?
>
>	Unix FS's are faster at some things, like reading directories (assuming
>the directories aren't too large - for large directories, AmigaDos is faster
>at finding a file).  However, FFS is no slouch at this.  My directory listings
>are scroll speed limited.
>
>>bernie
>>(Real computers have flashing lights, front panel switches, 8K RAM  and
>>hard-sectored floppies - anybody recognize this?)
>
>	Yes, except that's randomly-accessible tape drives, none of those
>new-fangled disk things.  To boot them, you have to toggle in a boot
>module in octal and run it.  Also, they have 12-bit words. ;-)

Oh, I thought it was the one where you toggled in the boot code,
and then strapped the "OS" from paper tape. Much more
user-friendly. :-)

bernie