croley@walt.cc.utexas.edu (David T. Croley) (08/26/89)
I am currently trying to come up with a rule of thumb so that I can determine the relative speed of a hard drive. I have seen drives with fast access times and slow through-puts and drives with slow access times and high through-puts. Which is more important? Does anyone have any ideas? I would greatly appreciate any help. =============================================================================== David T. Croley The University of Texas at Austin croley@sleepy.cc.utexas.edu croley@(pick a dwarf).cc.utexas.edu "Don't believe everything you read." ===============================================================================
pmchen@sprite.berkeley.edu (Peter M. Chen) (08/26/89)
In article <17640@ut-emx.UUCP> croley@walt.cc.utexas.edu (David T. Croley) writes: > >I am currently trying to come up with a rule of thumb so that I can >determine the relative speed of a hard drive. I have seen drives >with fast access times and slow through-puts and drives with slow >access times and high through-puts. Which is more important? Depends on your workload. For workloads with large transfer sizes (or predominantly sequential accesses), throughput is more important (assuming your system above can handle all the throughput that's coming up at it). For workloads with small, predominantly random accesses, access time (seek + rotation) is more important. My guess is that, for Unix, access time is more important, since transfer sizes are pretty small (8K?). Pete
jc@odin.ucsd.edu (John Cornelius) (08/28/89)
In article <16567@pasteur.Berkeley.EDU> pmchen@mustard.Berkeley.EDU (Peter M. Chen) writes: >In article <17640@ut-emx.UUCP> croley@walt.cc.utexas.edu (David T. Croley) writes: >> >>I am currently trying to come up with a rule of thumb so that I can >>determine the relative speed of a hard drive. I have seen drives >>with fast access times and slow through-puts and drives with slow >>access times and high through-puts. Which is more important? > >Depends on your workload. For workloads with large transfer sizes (or >predominantly sequential accesses), throughput is more important (assuming your > . >My guess is that, for Unix, access time is more important, since transfer >sizes are pretty small (8K?). Swap devices should have the highest possible transfer rate since they're mostly sequential devices. File systems should have the highest possible access speed since their access is arbitrary. Note, however, that as the worst case seek time approaches the worst case rotational latency time, rotational latency becomes a significant factor in throughput if all other things are equal. Many disks available today have this characteristic. John Cornelius Andataco aka jc%andataco.uucp@ucsd.edu
henry@utzoo.uucp (Henry Spencer) (08/28/89)
In article <6987@sdcsvax.UCSD.Edu> jc%andataco.uucp@ucsd.edu (John Cornelius) writes: >Swap devices should have the highest possible transfer rate since they're >mostly sequential devices... Somebody's been reading old papers... Very few modern Unixes swap. Paging requests resemble filesystem accesses more: relatively small transfers (8KB or so, often) in quasi-random places. -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
sgf@brunix (Sam Fulcomer) (08/28/89)
In article <1989Aug28.050055.28526@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <6987@sdcsvax.UCSD.Edu> jc%andataco.uucp@ucsd.edu (John Cornelius) writes: >>Swap devices should have the highest possible transfer rate since they're >>mostly sequential devices... > >Somebody's been reading old papers... Very few modern Unixes swap. Paging In the modern Unixes which I know about processes are born with a swap. Other swapping (during normal scheduling) depends on the implementation of the scheduler, but they (as far as I know) all do it. Try running this shell script, called fubar, on your machine and tell me if it swaps: #!/bin/csh fubar & set history=5000000 while (1) echo 'SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS'\ 'WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW'\ 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'\ 'PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP' \ >>/dev/null end
sgf@brunix (Sam Fulcomer) (08/28/89)
In article <13700@brunix.UUCP> sgf@cfm.brown.edu (Sam Fulcomer) writes: >In article <1989Aug28.050055.28526@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >>In article <6987@sdcsvax.UCSD.Edu> jc%andataco.uucp@ucsd.edu (John Cornelius) writes: >>>Swap devices should have the highest possible transfer rate since they're >>>mostly sequential devices... >> >>Somebody's been reading old papers... Very few modern Unixes swap. Paging > >Try running this shell script, called fubar, on your machine and tell me if >it swaps: > >... text of painful shell script deleted... > The stupid news server wouldn't let me cancel the above, so... >>DONT DO THIS UNLESS YOU'VE GOT YOUR OWN PERSONAL MACHINE<< I posted before realizing that some people wouldn't know what the above shell script would do. It'll bring the system to a screeching halt. You probably won't even be able to tell if swapping's occurring (but it is...). The reason (in BSD) that this is so painful is the brain-damaged way that stuff is set up in param.c. Sam sgf@cfm.brown.edu fulcomer@jvncf.csc.org sgf%cfm@brownvm.bitnet
dold@mitisft.Convergent.COM (Clarence Dold) (08/29/89)
in article <13700@brunix.UUCP>, sgf@brunix (Sam Fulcomer) says: > In the modern Unixes which I know about processes are born with a swap. Other > swapping (during normal scheduling) depends on the implementation of the > scheduler, but they (as far as I know) all do it. > Try running this shell script, called fubar, on your machine and tell me if > it swaps: I didn't try the shell script, but I wonder if it's swapping that kills your system. The Bourne and Korn Shells both use tmpfile(3s) to create, and immediately delete, a scratch file, probably in /usr/tmp. Althought the file doesn't appear in an 'ls', since it's already deleted, you can see its former name with 'hd /usr/tmp'. A short shell script beats on this file system. Try a sh script: i=0 while : do i=`expr $i +1` echo $i done Not only is it slow as all get out, but the disk thrashes. sar -r ( a swap monitor on our UNIX ), shows no swapping. We don't swap to start processes anymore. Even if we did, the shell would already be there, and not cause a swap. Convergent/Unisys is primarily System V. -- Clarence A Dold - dold@tsmiti.Convergent.COM ...pyramid!ctnews!tsmiti!dold
henry@utzoo.uucp (Henry Spencer) (08/29/89)
In article <13700@brunix.UUCP> sgf@cfm.brown.edu (Sam Fulcomer) writes: >>Somebody's been reading old papers... Very few modern Unixes swap. Paging > >In the modern Unixes which I know about processes are born with a swap. Other >swapping (during normal scheduling) depends on the implementation of the >scheduler, but they (as far as I know) all do it. "What we have here is a failure to communicate." :-) The "swapping" that many modern Unixes do has little or nothing to do with the "swapping" that old ones did. Old-Unix swapping was moving the whole process to or from disk as a unit. Modern-Unix swapping is deciding that we aren't going to run this guy for a while so we'll let his in-core pages go. The terminology has remained although the implementation has changed. Old-Unix swapping put a premium on data-transfer rate but made seek time a secondary issue. Modern-Unix swapping has nothing in particular to do with disk i/o characteristics, since it's the paging subsystem that does all the actual disk i/o for memory management. I do not doubt that there are many vendors still shipping old Unixes. Utzoo ran such a system until last summer. That does not make them any less old or any more deserving of the adjective "modern". Kerosene lamps are still made, but they are not usually considered modern. -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
sgf@brunix (Sam Fulcomer) (08/29/89)
In article <1202@mitisft.Convergent.COM> dold@mitisft.Convergent.COM (Clarence Dold) writes: > >We don't swap to start processes anymore. >Even if we did, the shell would already be there, and not cause a swap. > I'm curious; when you do a fork where does the process address space get copied, or do you do copy-on-write?
jc@odin.ucsd.edu (John Cornelius) (08/29/89)
In article <1989Aug29.040250.23754@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <13700@brunix.UUCP> sgf@cfm.brown.edu (Sam Fulcomer) writes: >>>Somebody's been reading old papers... Very few modern Unixes swap. Paging >> >>In the modern Unixes which I know about processes are born with a swap. Other >>swapping (during normal scheduling) depends on the implementation of the >>scheduler, but they (as far as I know) all do it. > >"What we have here is a failure to communicate." :-) > >The "swapping" that many modern Unixes do has little or nothing to do with Well, yes! I have read the old papers, among others. I did not mean to start a religious war on the net. As Henry points out, the nature of swapping in systems with BSD ancestors is not really swapping. On the other hand, while that should be all of the Unices in existence it is not. The purpose of the comment was to point out the misplaced emphasis on transfer rate when evaluating disks and I stand by the comment. In the past 4 years we've seen average seek times drop from around 28ms to around 14ms and transfer rates increase from 2Mbps to 3Mbps. Rotational speeds, however, have remained at about 3600RPM giving a rotational latency of about 8ms. As seek times approach rotational latency the speed with which the data may be accessed will be dominated by rotational latency and controller behavior, not by seek times. John Cornelius Andataco aka jc%andataco.uucp@ucsd.edu
dold@mitisft.Convergent.COM (Clarence Dold) (08/31/89)
in article <6992@sdcsvax.UCSD.Edu>, jc@odin.ucsd.edu (John Cornelius) says: > In the past 4 years we've seen average seek times drop from around 28ms to > around 14ms and transfer rates increase from 2Mbps to 3Mbps. Rotational > speeds, however, have remained at about 3600RPM giving a rotational > latency of about 8ms. As seek times approach rotational latency the speed > with which the data may be accessed will be dominated by rotational > latency and controller behavior, not by seek times. Here the 'controller behaviour' is very significant. The SMD (and SCSI?) controllers from InterPhase even think ahead about latency. If a request is made for sectors 8-20 on a given track, and the first sector read is sector 12, the controller will start DMA, with the proper buffer offset, eventually finishing the DMA with the transfer of sector 11. I don't know if this is unique to Interphase, but I thought it was pretty clever. -- Clarence A Dold - dold@tsmiti.Convergent.COM ...pyramid!ctnews!tsmiti!dold
kc@hprnd.HP.COM (Kurt Chan) (09/01/89)
> As seek times approach rotational latency the speed > with which the data may be accessed will be dominated by rotational > latency and controller behavior, not by seek times. Disk manufacturers have come up with solutions to this exact problem. Some HP drives now spin at 4000 RPM, while Hitachi and Imprimis have drives which rev up to 4800 and 5400 RPM, respectively! Kurt.
seymour@blake.acs.washington.edu (Richard Seymour) (09/02/89)
In article <3170009@hprnd.HP.COM> kc@hprnd.HP.COM (Kurt Chan) writes: >> As seek times approach rotational latency the speed >> with which the data may be accessed will be dominated by rotational >> latency and controller behavior, not by seek times. > >Disk manufacturers have come up with solutions to this exact problem. Some HP >drives now spin at 4000 RPM, while Hitachi and Imprimis have drives which rev >up to 4800 and 5400 RPM, respectively! > And then there was DEC: in 1978 they wanted to put an 80mbyte CDC SMD drive on Unibus machines, but its data rate was too high for the Unibus. So they dropped the speed from 3600 rpm to 2400 rpm. And the RM-02 was born! (the RM-03 was the quick one...) There were a (very) few changes in the electronics to support the lower frequencies coming off the heads, but the disks were directly swappable with full-speed RM-03s. We had one... it ran just fine... -- dick
filbo@gorn.santa-cruz.ca.us (Bela Lubkin) (09/02/89)
In article <3170009@hprnd.HP.COM> Kurt Chan writes: >> As seek times approach rotational latency the speed >> with which the data may be accessed will be dominated by rotational >> latency and controller behavior, not by seek times. > >Disk manufacturers have come up with solutions to this exact problem. Some HP >drives now spin at 4000 RPM, while Hitachi and Imprimis have drives which rev >up to 4800 and 5400 RPM, respectively! Why not build a second set of heads radially opposite the first? This halves latency instantly (doubles RPM, if you wish); alternatively, it lets you play adaptive seeking games where the two sets of heads are stationed over different cylinders, etc. This can be extended to N sets of heads, N probably < 8 (you start running out of room...) Another idea is to put multiple heads on a single arm on each platter, so that while head 5A is over track 50, 5B is over track 600 (e.g.). This can halve your maximum seek distance (which doesn't halve your maximum seek >time<, but does lower it). I know heads are expensive. A drive built with some of these ideas would be damn expensive, but damn fast, too. >Someone< would be willing to pay for it... (One of these years nanotechnology will happen. We'll buy memory by the MOLE; no moving parts). >Bela< >Kurt. Bela Lubkin * * filbo@gorn.santa-cruz.ca.us CIS: 73047,1112 @ * * ...ucbvax!ucscc!gorn!filbo ^^^ REALLY slow [months] R Pentomino * Filbo @ Pyrzqxgl (408) 476-4633 & XBBS (408) 476-4945
terryk@pinocchio (Terence Kelleher) (09/04/89)
In article <19.filbo@gorn.santa-cruz.ca.us>, filbo@gorn (Bela Lubkin) writes: >>up to 4800 and 5400 RPM, respectively! > >Why not build a second set of heads radially opposite the first? This halves >latency instantly (doubles RPM, if you wish); alternatively, it lets you play >adaptive seeking games where the two sets of heads are stationed over different >cylinders, etc. This can be extended to N sets of heads, N probably < 8 (you >start running out of room...) The head arm assemblies are built with the idea in mind that, so long as the heads remain in relativly in the same position as compared to the servor head, the tolerance to build up each head are is not that important. If the head on one arm assembly is required to read data that may have been writen on the other assembly, then the position of the head must be correct when compared to either of the 2 servor heads. This is eliminated if embedded servos are used, but other problems arise, like limitations on the number of bytes per sector. Lots of systems use funny sizes here and would not be able to use a drive with restrictions on sector size. >Another idea is to put multiple heads on a >single arm on each platter, so that while head 5A is over track 50, 5B is over >track 600 (e.g.). This can halve your maximum seek distance (which doesn't >halve your maximum seek >time<, but does lower it). > If I'm not mistaken, the NEC 9 in drive does use 2 head assemblies on each arm. I'm not sure why, but its seek time does not look any better than other 9 in drives. -- Terry Kelleher, Encore Computer Phone: 508-460-0500 UUCP: {bu-cs,decvax,necntc,talcott}!encore!terryk Internet: terryk%pinocchio@multimax.ARPA
dold@mitisft.Convergent.COM (Clarence Dold) (09/04/89)
in article <964@multimax.Encore.COM>, terryk@pinocchio (Terence Kelleher) says: > If I'm not mistaken, the NEC 9 in drive does use 2 head assemblies on > each arm. I'm not sure why, but its seek time does not look any > better than other 9 in drives. Old CDC disk drives had two sets of heads per platter. They didn't actually read the same cylinders though. Physically, the drive had 10 recording surfaces, with ~1200 tracks, but it appeared to the controller as 20 heads X 623 tracks. It was cheaper to build than a 20 surface drive, but faster than a 1200 cylinder drive. -- Clarence A Dold - dold@tsmiti.Convergent.COM ...pyramid!ctnews!tsmiti!dold
seymour@blake.acs.washington.edu (Richard Seymour) (09/06/89)
In article <1213@mitisft.Convergent.COM> dold@mitisft.Convergent.COM (Clarence Dold) writes: (actually, in MANY articles MANY people talk about) > >> If I'm not mistaken, the NEC 9 in drive does use 2 head assemblies on >> each arm. I'm not sure why, but its seek time does not look any > >Old CDC disk drives had two sets of heads per platter. They didn't actually Well, the Fujitsu Eagle had two heads per arm per surface AND an option to have 60 (yes, sixty) fixed heads mounted on the top surface, giving you 60 tracks with no seek time (but still rotational latency) (then i remember our old SDS 256kw (24 bit) drum: a a conically-shaped magnetic surface with lots (128 or 256) of heads. when it spun up it would lift on the airflow -- it was the sizze of a refridgerator -- again, no seek time) (that was 1965 technology) -- dick seymour @ uwaphast.bitnet