peter@sugar.hackercorp.com (Peter da Silva) (09/02/90)
In article <558@DIALix.UUCP> bernie@DIALix.oz.au (Bernd Felsche) writes: > 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. Last time I saw any benchmarks, the Amiga *with equivalent hardware* was way faster than SunOS. Could you substantiate this claim with figures? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (09/03/90)
In article <6499@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >Last time I saw any benchmarks, the Amiga *with equivalent hardware* was way >faster than SunOS. Yes and no. The Amiga "with equivalent hardware" is faster with disk i/o. It is faster in that sense that it can move data faster into a processes address space. This is because the Amiga does not use a buffer cache and therefore does not need the extra copy operation involved in using a cache. This advantage becomes less when looking at small reads or writes, the filesystem overhead of the filesystem will make the cache overhead nearly invisible. On the other side, the Amiga (the filesystem) is very slow when dealing with concurrent tasks. The filesystem deals with requests in first-come-first-served order and concurrent accesses lead to heavy thrashing of the disk. This is because there is no buffer cache, no read-ahead and no "elevator"-algorithm. But it is not necessary most of the time since the Amiga is a single user system and only few users will put stress on the disk by loading several programs or files at once. And UNIX, it has to deal with multiple users and a lot of system tasks requiring disk access therefore it needs these mechanisms to improve _its_ average demands. Regards, -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."
bernie@DIALix.oz.au (Bernd Felsche) (09/03/90)
In article <6499@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <558@DIALix.UUCP> bernie@DIALix.oz.au (Bernd Felsche) writes: >> 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 ^^^^^^^^ I meant better than System V, not AmigaDOS >> all available RAM. > >Last time I saw any benchmarks, the Amiga *with equivalent hardware* was way >faster than SunOS. Could you substantiate this claim with figures? That's a tough question.... The only stat's I have are from diskperf > 4MB/sec - which is rubbish, because SunOS was caching the lot in RAM for normal disk I/O. AmigaDOS loses on that account. Raw I/O peak was close to ideal (UNIX is no good for timing things) and averaged at over 50% of disk specs for sustained throughput (approx 1.2MB/sec out of 1.8 for the drive). I don't recall actual figures, as I did the testing some 5 months ago (around Easter). Raw I/O is very CPU dependent (it surprised me too) because I was using "dd etc... >/dev/null", and you must consider the 33MHz SPARC chip grunts long at 22 MIPS, or thereabouts, on this sort of thing. I _do_ recall that throughput was very sensitive to input block size. I think somewhere around 8K - 16K was best. >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. Thanks for catching my earlier slip-up, comparing filesystems. I did not intend to mislead the reader. That is why I asked about stats for the A3000 with AMIX vs AmigaDOS. bernie P.S. The SunOS stat's were not run on a Sun.
jesup@cbmvax.commodore.com (Randell Jesup) (09/07/90)
In article <1159@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP (Michael van Elst) writes: >In article <6499@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >>Last time I saw any benchmarks, the Amiga *with equivalent hardware* was way >>faster than SunOS. > >Yes and no. The Amiga "with equivalent hardware" is faster with disk i/o. >It is faster in that sense that it can move data faster into a processes >address space. This is because the Amiga does not use a buffer cache >and therefore does not need the extra copy operation involved in using >a cache. This advantage becomes less when looking at small reads or writes, >the filesystem overhead of the filesystem will make the cache overhead >nearly invisible. True, but the filesystem overhead is lower also, due to faster context switches, etc. >On the other side, the Amiga (the filesystem) is very slow when dealing >with concurrent tasks. The filesystem deals with requests in >first-come-first-served order and concurrent accesses lead to heavy >thrashing of the disk. This is because there is no buffer cache, no >read-ahead and no "elevator"-algorithm. But it is not necessary most >of the time since the Amiga is a single user system and only few users >will put stress on the disk by loading several programs or files at once. >And UNIX, it has to deal with multiple users and a lot of system tasks >requiring disk access therefore it needs these mechanisms to improve >_its_ average demands. Elevator only helps in the case of 3 or more tasks making accesses at the same time. Read-ahead does help in multiple-access situations, but more and more SCSI drives have built-in read-ahead. Your points on single-user are on-target. Remember, though, that a lot of Unix machines are effectively single-user and rarely have multiple-accesses occurring (though more often than AmigaDos). Multiple track buffers in trackdisk can reduce thrash a lot (for floppies). LoadSeg uses larger internal buffers under 2.0 which will reduce thrashing (more data xfered per seek). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (09/08/90)
In article <14260@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: > Elevator only helps in the case of 3 or more tasks making >accesses at the same time. Read-ahead does help in multiple-access >situations, but more and more SCSI drives have built-in read-ahead. Your >points on single-user are on-target. Remember, though, that a lot of >Unix machines are effectively single-user and rarely have multiple-accesses >occurring (though more often than AmigaDos). Well, that's true, I wanted to tell what's the difference between single user and multi-user filesystems. But even if you think that Unix machines are single-user there are usually nonconsecutive disk accesses as program code is (hopefully) demand-loaded and larger program systems (should I say X-window servers :-)) will often page in and out while the user's program is running. Regards, -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."
jesup@cbmvax.commodore.com (Randell Jesup) (09/30/90)
In article <1169@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP (Michael van Elst) writes: >But even if you think that Unix machines are single-user there are usually >nonconsecutive disk accesses as program code is (hopefully) demand-loaded and >larger program systems (should I say X-window servers :-)) will >often page in and out while the user's program is running. That may well be true, though the paging allocation algorithms can help quite a bit here to improve performance, so that read-ahead doesn't hurt or helps. This doesn't have (much) effect on the issue of elevator algorithms. Another personal opinion: if you're getting a lot of real paging (as opposed to load-paging), then you need more memory. Note that different people may define "a lot" in different ways. I've noted that in every group I've been in using Suns or whatever, people manage to get enough memory to avoid signifigant paging in their normal use of the machine. In the latest Unixes, this may well mean 8 Meg if you want nice graphical interfaces. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (10/02/90)
In article <14736@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >Unixes, this may well mean 8 Meg if you want nice graphical interfaces. Well, our DECstations need at least 24 Meg when compiling FORTRAN programs from the X-Windows environment (which is the default). We started with 16 Meg machines and the optimizer run starts heavy paging activity. Suprisingly that wasn't the slowest operation but the linker that leaves the machine with a nearly idle CPU (20% loaded) when loading the libraries from the server which isn't slow for other common operations. Regards, -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."