sam@ms.uky.edu (Mike Mills) (06/16/90)
I recently bought a used Tiny Tiger hard disk with a ST157-N (48 meg) drive for my a500. I got a good deal on it, but I'm not impressed with its speed. Less than 50K/sec for reads and writes, no matter how big the buffer is. The Tiny Tiger plugs into the parallel port. I was wondering where the bottleneck is that makes it so slow; is it the parallel port, the scsi interface, or the x500.device driver? I was hoping that if it was the driver that a faster, more efficient version might be available somewhere? Thanks, -- | Mike Mills (aka "Sam") | sam@ms.uky.edu cn.mike@ukpr.uky.edu | | (606) 231-7933 | BIX: mike... | +-------------------------------------+---------------------------------------+ | "There is always an alternative." --Spock |
matth@extro.ucc.su.OZ.AU (Matthew Hannigan) (07/02/90)
In article <1227@metaphor.Metaphor.COM> djh@dragon.metaphor.com (Dallas J. Hodgson) writes: >In article <sam.645470800@s.ms.uky.edu> sam@ms.uky.edu (Mike Mills) writes: >>I recently bought a used Tiny Tiger hard disk with a ST157-N (48 meg) drive for >>my a500. I got a good deal on it, but I'm not impressed with its speed. Less >>than 50K/sec for reads and writes, no matter how big the buffer is. >> >>The Tiny Tiger plugs into the parallel port. I was wondering where the >>bottleneck is that makes it so slow; is it the parallel port, the scsi >>interface, or the x500.device driver? I was hoping that if it was the driver >>that a faster, more efficient version might be available somewhere? > >I've been happy with the Tiny-Tiger's speed; in real-world performance, I'm >amazed that it runs as fast at is does. I remember the MAST folks quoting >its xfer rate at 500KB/sec, raw. I'm not going to refute or support this >claim, but I do know this; the actual loop that performs the block transfers >is VERY tight. It goes something like this: > > loop: nop > move.b ciaaprb,(a0)+ > dbra d0,loop ... interesting stuff deleted ... >+----------------------------------------------------------------------------+ >| Dallas J. Hodgson | "This here's the wattle, | I have just bought a Tiny-Tiger 45Mb drive and had it diskperf'd at the shop before I took it away. At first it only gave 50k/sec. BUT there is a option in the mountlist for FFS called MaxTransfer. On some boot up disks supplied with the TT, Maxtransfer is set to 32. On others, it is missing. When booted with a disk with no Maxtransfer the transfers rates are as expected and are quite close to the A590's DMA figures. So, the conclusion is to either adjust upwards (say 128) the Maxtransfer figure, or remove altogether. Exactly what subtle interactions are going on here warrants further investigation. Could someone in the know tell us exactly what Maxtransfer is for? The 1.3 book is not particularly enlightening. Is it size or speed fr'instance? Regards, -Matt H PS. I have an Amiga 500 with PAL, 1.3 roms
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (07/03/90)
In article <1990Jul2.074747.19497@metro.ucc.su.OZ.AU> matth@extro.ucc.su.OZ.AU (Matthew Hannigan) writes: >Could someone in the know tell us exactly what Maxtransfer is for? >The 1.3 book is not particularly enlightening. Is it size or speed >fr'instance? Standard device drivers are not required to handle read and write operations with an arbitrary sized buffer. F.e. the trackdisk.device supports multiples of sectors only. Some drivers limit the maximum size of a single operation. With the old file system there wasn't a problem. It started only single sector operations for only part of the sector is used for data. The fast file system uses the complete sector for data and therefore can transfer multiple sectors from or into a larger buffer. In order to not hit the maximum transfer size limit of the driver, you can tell the fast file system a specific limit. This is the maxtransfer value. Common values are 0, 1, 65536 and 131072 for device drivers with no limit, operations limited to single sectors or with a 8 bit sector counter (signed and unsigned). Standard hard disk drivers are 'dumb' and will perform only the operations that are explicitly requested. So if you start smaller reads (or writes) these are single actions that will require a complete disk revolution for contigous sector accesses. The more operations are done the more revolutions of the media are needed. One could provide 'smarter' drivers that are using a caching scheme to provide a better average performance (and a slightly degraded peak performance). Future versions of the file system could handle this better inside the file system but todays file system does not. -- 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."