jhallen@wpi.wpi.edu (Joseph H Allen) (03/24/89)
In article <1257@houxs.ATT.COM> you write: > >In addition to delay line memory, some machines used magnetic drum memories >(e.g., IBM 650). The trouble with delay line memory and most drum memory is >-- Somewhere I heard that some of the high-end IBM mainframes use drum memory for swapping space. Is this true? And what is the advantage? I can imagen that drum memory might be quite fast since there is a head for every track and no moving parts except for the drum...
jamesa@arabian.Sun.COM (James D. Allen) (03/24/89)
In article <1487@wpi.wpi.edu>, jhallen@wpi.wpi.edu (Joseph H Allen) writes: > In article <1257@houxs.ATT.COM> you write: > > > > Somewhere I heard that some of the high-end IBM mainframes use drum memory > for swapping space. Is this true? And what is the advantage? I can imagen > that drum memory might be quite fast since there is a head for every track and > no moving parts except for the drum... This information may be almost a decade out-of-date: I was sort of a "370 repairman" in the 70's. Two types of drum were the 2305 Model I and the 2305 Model II. They looked about the same, but the former had twice the datarate, increased price and *half* the capacity. I don't remember why it had only half the capacity; there is some logical explanation. Guess: perhaps it was because of 2-heads-per-trk to get 180-degree maximum latency and therefore half as many tracks. IBM also offered mixed moving/fixed-head disks but let's talk about the 2305. The Model II was relatively common, but because of the high price-per-megabyte, very few Model I's were ever sold. The paging software could sense the 2305 angular position and used it to choose its allocation whenever data was swapped out. Thus the 2305 could be kept quite busy and was always attached, by itself, to the highest-priority channel. Many "370 repairman", after a tough installation, regarded 2305 activity as the ultimate test. With 3.0 Megabytes/sec, the 2305-I exceeded twice the speed of any other peripheral and used 16-bit data to the host channel (3 fat cables instead of 2.) IBM's attached floating-point unit was the next peripheral to use that interface. Since the 2305-I was incredibly expensive, STC competed with it successfully with their "6305 (?)" made from dynamic RAM. Intel tried also but was less successful, partly because their semiconductor "search latency time" wasn't much better than that of the 2305-I! (here "search latency" is the firmware overhead on their microprocessor controller.) Data-intensive applications often read their data in large chunks. A 64k chunk takes 22 milliseconds to read even at 3 MBS datarate. For this reason, datarate becomes as important as seek latency for these high-powered users and this tends to reduce the advantage of fixed-head disks. Bubbles and CCD's were designed into "drum replacements" in the late 1970's, but MOS RAM's are now so cheap, and conventional disks so fast and cheap, that the intermediate- performance technologies no longer seem to attract commercial attention. - James Allen
littauer@uts.amdahl.com (Tom Littauer) (03/24/89)
In article <95741@sun.Eng.Sun.COM> jamesa@arabian.Sun.COM (James D. Allen) writes: A good summary of the use of drums on 370-architecture machines. A minor nit: these "drums" were implemented as head-per-track disks for ease of manufacture (cost) and capacity. > Data-intensive applications often read their data in large chunks. > A 64k chunk takes 22 milliseconds to read even at 3 MBS datarate. > For this reason, datarate becomes as important as seek latency > for these high-powered users and this tends to reduce the advantage > of fixed-head disks. Correct. The need to improve on this is one of the things that drove us to introduce 4.5MB channels and a 4.5MB data rate on our solid-state "disk". -- UUCP: littauer@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ames,uunet}!amdahl!littauer DDD: (408) 737-5056 USPS: Amdahl Corp. M/S 337, 1250 E. Arques Av, Sunnyvale, CA 94086 I'll tell you when I'm giving you the party line. The rest of the time it's my very own ravings (accept no substitutes).
davidsen@steinmetz.ge.com (Wm. E. Davidsen Jr) (03/27/89)
In the late 60's GE had two projects running as possible replacements
for the GECOS o/s. These were the based on modified GE-600 computers.
The one here was a 605 (why the 605 came after the 635 I don't know),
and the one at MIT was the 645, running Multics.
The 605 had a drum which transferred a 72 bit double word in 7 us, which
was really brisk for those times. The Multics system used a faster drum
yet. I can't remember the model numbers, I think ours was an xxx-10, but
the code names were "garden hose" (ours) and "fire hose" (MIT's).
GE also made a head-per-track disk called the 270, which didn't have a
high transfer rate, but had a very good seek time. We also made a disk
with four arm assumblies, which could do seeks on three arms while doing
i/o on the other.
--
bill davidsen (wedu@crd.GE.COM)
{uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -memahar@attila.WEITEK.COM (Mike Mahar) (03/28/89)
Actually, there is a problem in C with changing the order of the elements in
a structure for optimization. Page 196 in Kernighan and Ritchie says:
"Within a structure, the objects declared have addresses which increase
as their declarations are read left-to-right."
This means it is illegal in C to change the order of the elements in a
structure.
--
"The bug is in the package somewhere". | Mike Mahar
- Anyone who has used Ada | UUCP: {turtlevax, cae780}!weitek!mahar