Club Amiga de Montreal

home *** CD-ROM | disk | FTP | other *** search

/ Club Amiga de Montreal - CAM / CAM_CD_1.iso / files / 510.lha / SPSTransfer_v1.01 / SPSTran.doc.pp / SPSTran.doc

Wrap

Text File | 1991-05-07 | 13.7 KB | 334 lines

------------------------------------------------------------ SPS UTILITIES - Transfer Rate Analysis ------------------------------------------------------------ SPSTransfer v1.01 ©1991 Silicon Prairie Software All Rights Reserved. Transfer Rate Analysis written by David Plummer. This software is not, nor has it ever been, public domain software. It is freely distributable software, with the following restrictions: It may not be distributed in disk collections or by similar method if the charge for distribution, including the media charge, exceeds seven (7) US dollars. It may not be included with other software materials as part of a commercial package without the express written permission of the author(s). This software and its documentation files must be distributed together, without modification. Explicitly, this software may be distributed in the Fred Fish software library. NOTE: These distribution criteria apply only to this particular product and are not indicative or applicable to any other product that may or may not be produced by SPS software or its agents. Changes v1.01 ~~~~~~~~~~~~~ - Changed parameter format to standard -option style. - Added support for explitly stating transfer block size. - Added support for devices that are neither OFS nor FFS. - Changed timing scheme slightly to provide more consistent results. - Multiple devices can now be tested without exiting the program and re-running it. What is SPS-Tran? ~~~~~~~~~~~~~~~~~ SPS-Tran is a transfer rate analysis program for the Amiga series of computers, and allows the user to determine the maxiumum data transfer rate for an AmigaDOS storage device, such as Hard Drives, Floppy Drives, CD-ROMs, or Virtual Ram Drives. The only requirements are: - The device must be block-addressabe. [ It used to be required that the device be OFS or FFS, which still applies unless the -f option is specified on the command line. See usage notes below. ] As you can see this includes pretty much every device currently available. A notable exception is the standard RAM disk, which does not employ the normal filesystem. Why SPS-Tran? ~~~~~~~~~~~~~ SPS-Tran does one thing, and does it well: it determines the maximum data transfer rate, REGARDLESS OF FILE SYSTEM. It goes directly to the device, independant of the file system, and reads blocks from the device. It does so in a system-legal way, but avoids the overhead of directories, hash tables, and the like. Why take this approach? Because many similar test programs on MS-DOS series computers take a similar approach, such as CoreTest by Core Laboratories. In order to make any form of valid comparison, some similar method must be available on the Amiga. Many other existing "hard drive speed" programs simply create a large file on the hard drive, seek into it, and repeatedly read it. The results are obviously dependant upon several other factors, such as the file system, drive fragmentation, and so on. SPS-Tran eliminates these factors, and tests reads only, "ceteris peribus" (the only Latin I know!). It gives you results based solely upon the CPU, controller, and drive. As an additional benefit, SPS-Tran does not need to create its own test file, and therefore can test read-only devices. SPS-TRAN NEED NEVER WRITE TO THE DEVICE BEING TESTED. If your drive is connected via a modern controller such as the A2091 from Commodore, SPS-Tran will generally also inform you of the make and model of the storage device. Using SPS-Tran ~~~~~~~~~~~~~~ To use SPS-Tran, simply type "SPSTran" at the command line prompt or double-click its icon from Workbench. Once SPS-Tran is running, select a drive from the available drive list. You may also select QUIT to exit the program. All valid OFS ans FFS drives will be available for your selection. As soon as you have selected the device to test, SPS-Tran will begin the testing. You will be shown all of the test data as well as a graphical display of the read and seek speeds. When you are done reviewing the information, you may exit the program by pressing the right mouse button. If you wish to run a more intensive test than the default four second read test, you may specify the time in seconds on the command line. Example: SPSTrans -s 60 (Runs a one minute read test) You may also force a specific transfer block size if you know your drive is doing sector translation (for example, you know your drive has 34 sectors but it reports 17). You can specify the transfer block size, in kilobytes, on the command line. Example: SPSTrans -t 64 (Forces a 65536 bytes block) For devices such as CD-ROMS that do not use the OFS or FFS filing systems, you can optionally specify the -f parameter, which will enable you to select from all available devices. Data Transfer Test ~~~~~~~~~~~~~~~~~~ The data transfer test determines the maximum data transfer rate between the physical media and the system RAM. The following factors will affect the maximum transfer rate: » Device Speed » Controller Speed » Computer Speed » Device Interleave » System Load as well as other possible factors. The test will run for four seconds, and the average continuous transfer rate will be displayed as a graph and in numerical form. Seek Test ~~~~~~~~~ The seek test is made up of two major portions: » Full Stroke Seek » Track to Track and Back Seek Many programs tend to perform a few 1/3 full stroke seeks and call it the average seek time. I find this test fairly meaningless, so I chose to combine the two above tests, repeated 4 and 50 times, respectively, and display the total time elapsed. It is _not_ a drive ms rating. If you need to know that, look in your drive documentation: they'll gladly give it to you, plus or minus the time for the head to settle, etc. Obviously, the lower the number, the faster the seek mechanism. Note that nothing need be read in this test: it is purely a test of the seek time. Some devices do not support the extended device seek command and will therefore give erroneous results (ie: 0 seconds). These results should simply be ignored. Most devices, such as scsi.device and trackdisk.device, do support this command. Comparisons ~~~~~~~~~~~ The following results were achieved using SPS-Tran: SYSTEM DRIVE HDS SECS CYL SEEK READ --------------------------------------------------------- A500 DF0 2 11 79 5.0s 19.7 K/sec A500 EPSON DHM-755 2 34 614 2.6s 226.3 K/sec A2000 (A2090) 6 17 871 ---- 274.2 K/sec A500 ST157N-01 6 26 612 2.5s 593.2 K/sec A3000 QUANTUM LP52S 1 49 2085 0.5s 1919.2 K/sec A3000 RAD: 2 11 79 ---- 3779.1 K/sec Notes: - The A2000 controller did not report drive identity. - The Epson drive was connected via the A590 xt.device. - The Seagate drive was connected via the A590 scsi.device. - Your mileage may vary. Technical Notes ~~~~~~~~~~~~~~~ Because SPS Tran goes directly to the device without using a filesystem, it will provide true transfer speed tests. Because the filesystem overhead is removed, SPS Tran will provide results that are generally higher than other disk-speed-type products. The results are, however, completely valid in the context of device to memory transfer rates. The only major compromise I made, and I hated to do it, was to use the extended device command SEEK to perform the seek tests. I only have documentation for using this command for the trackdisk device. Rest assured it works equally well with the Commodore scsi device used for the A590, A3000, and A2091. It may even be documented as a standard device command, and I may not know it. In any event, if you should have a device that will not handle it, SPS Tran will detect this and skip the seek test procedure. In that event, you will likely receive a seek test duration of 0.0 or 0.1 seconds, and this result should be discarded. SPS Trans automatically selects the optimum transfer block size based on the geometry of the drive. This requires that the cylinder count from the mountlist or filesystem information be correct. A drive that lists itself as 1 head, 1 cylinder, and some extremely large sector count may not perfrom as well as if the sector count was "correct", because the transfer block size was incorrectly calculated. SPS Tran does its best to guess, however, and will usually select a good transfer block size. SPS Tran also reads the entire transfer block (up to the MAXTRANSFER rating of your device) as one contiguous unit, unlike some MS-DOS programs that must read on a track by track or even sector by sector basis. For that reason, the Amiga may read drives faster than MS-DOS systems, everything else being equal (ceteris peribus!). An additional factor to consider when comparing your read speed results to MS-DOS systems is that generally the maximum data transfer block for MS-DOS systems will be limited to 65536 bytes. The maximum SPS-Tran transfer block size is 4294967295, or the drive's MAXTRANSFER rating, whichever is the smallest. Accuracy ~~~~~~~~ System load will effect your results, such as moving the mouse around during the tests. I could do a Forbid() during the test, but I prefer to avoid that sort of thing. I could provide this as an option, if anyone feels the need. It's not that hard to resist the temptation to play with the mouse during the test... my results showed little difference during the forbidden state as compared to the idle state. Some may feel that 4 or 6 or 8 seconds is too short of a test to be accurate. As long as system load remains relatively constant throughout the test, the results will be very accurate. During development, two tests were tried: one for six seconds, the other for six minutes. In the six second test, on a stock 8 MHz Amiga, using the A2091 controller and an ST157N-01 drive, the sustained data transfer rate was 595722 bytes per second. On the six minute test, the rate was 596522. This is an accuracy rating of 99.87%. On a system such as the Amiga, however, all things are rarely always equal. For that reason, you may wish to run several tests and take the average of the runs, or better still, specify a longer test duration. There will be times when the timer device is pre-empted or the timer message does not make it through at the exact moment due to some other high-priority event occuring. You may validate your results by successive runs. On my system, unless something high-priority happens or the system is bogged down, the transfer rating is generally consistent down to the 10s of bytes. This version does its timing in a slightly different fashion. Version 1.0 simply sent a timer message specifying the duration (ie: 4 seconds) and kept reading until the message was returned from the timer. If the transfer block was large, it was possible that one extra transfer block could be read in some instances if it just came in under the wire. Version 1.01 does the same thing, but times the read from start to finish, via a seperate call, regardless of the test duration. Comments ~~~~~~~~ Your comments/criticisms/suggestions/donations are most gratefully accepted. I'd love to hear what you think of SPS Trans, both in terms of performance and user interface. I may be reached via the following: NON-US MAIL: David Plummer 2326 Francis Street Regina, Saskatchewan Canada S4N 2P7 INTERNET: PLUMMERD@MAX.CC.UREGINA.CA (Preferred) DAVID.PLUMMER@F70.N140.Z1.FIDONET.ORG FIDONET: David Plummer F70, N140, Z1 PHONE: (306) 352-0358 ============================================================ __ __ /// IBMUBMWEALLBM4IBM \\\/// \XX/ ============================================================