home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.periphs.scsi
- Path: sparky!uunet!mcsun!Germany.EU.net!mpifr-bonn.mpg.de!specklec.mpifr-bonn.mpg.de!mlelstv
- From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
- Subject: Re: 1 GB 3.5" SCSI disks
- Message-ID: <1992Nov24.020035.18444@mpifr-bonn.mpg.de>
- Sender: news@mpifr-bonn.mpg.de
- Nntp-Posting-Host: specklec
- Organization: Max-Planck-Institut f"ur Radioastronomie
- References: <1992Nov11.175733.15236@b11.b11.ingr.com> <OD.6badnetOA92-901-302p0_53b52437@piraya.bad.se>
- Date: Tue, 24 Nov 1992 02:00:35 GMT
- Lines: 22
-
- In <OD.6badnetOA92-901-302p0_53b52437@piraya.bad.se> Roger_Nordin@atb.bbs.bad.se (Roger Nordin) writes:
- >If a cache had been involved, would the "CPU Available" not have showed lower
- >figures? Software caches always eats a lot CPU time when reaching from the
- >cache, since that is a 100% dependant CPU operation itself.
-
- No. It wasn't a cache on the host computer (i.e. an Amiga A3000) but the
- 512k cache memory on the drive itself. If the drive sends data in 5MB/s
- bursts (theoretical max of the A3000 hardware) the CPU is still idle
- during the transfer. The CPU 'availability' is mainly affected by file system
- overhead and the few stolen (DMA) memory cycles.
-
- >harddisks. Now, 1Gb 3.5" without zone recording?! Why waste so much disk space?
-
- Dunno. But tests with larger block sizes revealed that transfer speed has
- a constant maximum independant of what tracks where read.
-
- 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."
-