Talk:Semi Automatic Ground Environment

From Wikipedia, the free encyclopedia

This is the talk page for discussing improvements to the Semi Automatic Ground Environment article.

Article policies
MILHIST This article is within the scope of the Military history WikiProject. If you would like to participate, please visit the project page, where you can join the project and see lists of open tasks and regional and topical task forces. To use this banner, please see the full instructions.
Start This article has been rated as Start-Class on the quality scale.

Actually, SAGE was a centralized, automated air defense system developed by the U.S. in the 1950s to counter a perceived (but largely imaginary) Soviet strategic bombing threat. The BOMARC antiaircraft missile was only one of the weapons systems included in the SAGE system.

By the time it was fully operational the Soviet bomber threat had been replaced by the Soviet missile threat, for which SAGE was entirely inadequate. Nevertheless, SAGE was tremendously important; it had an immense influence on the development of interactive computing, computer networking, and computer hardware and software.

IBM's role in SAGE was the design and manufacture of the AN/FSQ-7 computer, a vacuum tube computer with ferrite core memory based on the Whirlwind. This experience was an important factor leading to IBM's domination of the computer industry.

Contents

[edit] USENIX: SAGE: System Administrator's Guild

Do we need a disambiguation page to refer to the USENIX special technical group SAGE? (As a computer nerd this was my first associate with the link I saw RecentChanges).

[edit] collecting aircraft?

SAGE, the Semi Automated Ground Environment, was an automated control system for collecting, tracking and intercepting enemy bomber aircraft Is this the official description? If not, it should be rewritten- surely the USAF aren't collecting bomber aircraft - they're much too large to keep on a closet shelf. -FZ 13:17, 31 Aug 2004 (UTC)

Sage tracked all aircraft in the Conus.Dcstu41 02:23, 6 September 2006 (UTC)Dcstu41

[edit] Tube failure rate

Anyone know where the data in this text came from:

the daily failure rate was in the hundreds. Each center had staff dedicated to replacing dead tubes by running up and down the racks of machinery with shopping carts filled with replacements.

The reason I ask is that one of the articles in the Annals of the History of Computers special issue on SAGE (which I just added to the article) says (pp. 349 if anyone wants to go look) that the measured MTBF on the tubes (during March 1978 - February 1980) was 50K-100K hours - with each FSQ-7 having about 50K tubes, this gives a failure rate of about 1 tube/hour, hardly the "daily ... hundreds" in the article. Noel (talk) 03:44, 31 Jan 2005 (UTC)

The text in question I found in a description of of the system in a book I read many years ago. I believe your number is correct, however, and a combination of poor wording and unintensional inflation has led to the number I posted. What I remember in particular was that the machines included self-test systems that could spot tubes that were about to burn out. Every so often (once a day?) they would run the test, write down the soon-to-fails, and then run around with the shopping carts full of tubes. It's very likely the carts contained hundreds, but only used a small fraction. Maury 13:14, 31 Jan 2005 (UTC)
Yes, that was the "voltage margin" system, something the FSQ-7 copied from Whirlwind. Quoting from another article in that issue (by Jay Forrester, pp. 400-401) a marginal checking system in which one could, under the control of the machine itself, [! - JNC] alter the voltage of the screen grids of vacuum tubes that would vary the gain and move the particular set of vacuum tubs up or down with respect to their normal range of operation. He goes on to say that they could anticipate deterioration that was occurring gradually, which was about 90% of all ultimate failures, so it gave them a factor of 10 in reliability.
The one comment you make I'm not sure about is the reference to tubes. The FSQ-7 was built around 6- and 9-tube pluggable units (pp. 345), and I suspect it was more likely those that they swapped. Do you happen to remember the name of the book? Noel (talk) 14:54, 31 Jan 2005 (UTC)
BTW, I notice that the test run is very late in the program -- they were taking them out of service at this point in time. Is it possible the 100's figure isn't that innaccurate for early tubes? Maury 13:16, 31 Jan 2005 (UTC)
Yes, I wondered about that too. However, Forrester's comments about reliability (above) explicitly refer to the Whirlwind (and he refers to a computer with '20,000 tubes' - clearly not the FSQ-7). He says tubes 'were thought to have about a 500-hour life', which would have been 'quite intolerable', and goes on to say they identified a material processing fault (failure to remove silicon from the nickel of the cathode) which raised the tube life to '500,000 hours' (!). I'm a bit dubious of that number though, because this is from an interview in 1975, and he may have added an extra "0" through a memory glitch. Removing it puts at the lifetime number I quoted in my original note. However, in any event it's clear that tube lifetime had been greatly improved prior to the FSQ-7. Also, with the shift to transistors, I doubt people put a lot of work into improving tube lifetime in e.g. the 1970's. So my presumption is that the number from earlier in the FSQ-7's life would have been similar. I looked for an earlier definite number, but didn't find one, alas. Noel (talk) 14:54, 31 Jan 2005 (UTC)

Glad to see this discussion! It turns out you can't use the MTBF of a tube to compute the overall reliability. Tubes have a high infant mortality, so the MTBF figures, for a "mean" tube, are useless. They found out in actual operation, once they had weeded out the early-dying tubes, the remainder would last much longer than the MTBF. So much so that it would actually DECREASE the machine's reliability to go around replacing "weak" tubes.

Now I'm sure the maintenance manuals spelled out that all weak tubes should be replaced, but I question if this was actually done in practice.


Re tube failure We ran margins to failure as a last resort. Most of the time we ran maint programs that were Cat (catastropic) at least we hoped so. We were so good after a year fixing the thing that we spent a lot of time playing hearts.Oh yes! We would put out the lights and walk down the frames looking for tubes with the filaments out.We could run a data pattern and put the acculmulator regester on the speaker. It made a tone.Then we would take a pencil and tap the tubes. when we got a shift in tone that tube was microfonic. In other words it had a loose element.You might say that we used all our sences troubleshooting the beast. We did use scopes and logic books also.Our scope probes were 15 feet long.The pluggable units were mostly 9 tube. A flipflop was a medium-nu twin triode. It was a bi-stable multivibrator.Dcstu41 02:38, 6 September 2006 (UTC)Dcstu41

... Having worked on the FSQ-7 in the late 70s, I never saw a shopping cart and we would go days and sometimes longer without a hard failure of a tube while under normal operation. On a regular schedule we would run margin testing. The voltage was raised or lowered on an individual bit of a register, the test program would run, if it past, the voltage was changed, if it failed a report would list the plugable unit that failed. This continued until failure or the maximum voltage change was reached. The frames out on the computer floor had switches that let us power down the frame so that we could pull the unit and install a spare unit. The original unit would be repaired and then usually on the midnight shift we would put the original unit back in and repeat the margin testing. The spare unit would not normally stay in the frame. A couple interesting points (at least they were to me). Since the cooling towers were outside the hardened building along the fence line a passerby could easily just toss in some dye into the water and likely we would have shut down until they figured out what was wrong. I always figured being in a hardened building was more for show than actual benefit since the cooling town would not likely survive. Another technology item is the printer was designed to run just about anywhere in the world since it had a generator in it run by a electric motor. To get it to run on a particular voltage all you needed to do was locate a motor that would run at the right speed and compatible with the local voltage. As the radar sites were upgraded in the late 70's the data stream was incompatible, we had a Data General Nova (sure about Data General not sure of model) that took the fancier data from the upgraded radar sites and reformatted the data so that the FSQ-7 could understand it. A problem early in the computer life was silver migration. The jumper pins on the frames were made of silver at first, but random errors started occurring. What was happening was the silver would migrate between the neighboring pins causing shorts. They looked like slug trails. A non-approved method of replacing rotating drum heads was to install them and then to adjust them down until they were close to the drum, then you put the handle of the driver in your ear and you slowly turned it down until you felt the vibration of the head touching the drum and backed off just a hair. As long as you took your time it worked quite well. We would do some tapping of tubes but rarely. What we would do is take the phone/intercom and hang it in front of the speaker that was hooked to MSB of the accumulator. Then put the phone on speaker out on the computer floor. A program running would have a pattern of noise and you would tap the tube, if the pattern changed or stopped you knew you found a tube with a problem. The live program would repeat its pattern based on the time it took a radar to rotate once. I don't recall the time but 12 seconds sticks in my head. You could sit and read a book and not need to watch much of anything, if the pattern of noise changed you looked up to see what was going on. As long as the second computer wasn't down for a major issue, we could switch over in less than 5 minutes from a cold start. A planned switch over was done with almost no interruption to the users. The control panels of the FSQ-7 computer appears in many movies due to the large number number of lights, there was a neon bulb for every flip flop on the computer plus lights for other indications. [[[User:75.183.54.57|75.183.54.57]] 22:29, 15 August 2007 (UTC)]

[edit] dab?

I just wanted to check if this is something that's been gone through before, but... would it be reasonable to have a disambiguating link, or a see-also, or something, to Sage, the plant genus, or to Sage (disambiguation)? -FZ 14:05, 16 Jun 2005 (UTC)

[edit] FAA use of SAGE?

I'd question the sentence: "This was not lost on the FAA, who used SAGE systems in their own automated control systems, many of which remained in service until recently." I'm not aware of any FSQ-7s used by the FAA. Perhaps the author was thinking of the FAA's IBM 9020s which were System 360 derivatives. --agr 15:45, 27 October 2005 (UTC)

[edit] Vandalism?

Quoting the article: "In later versions, the system could automatically direct aircraft to an interception by sending commands directly to the aircraft's autopilot."

This strikes me as being so wildly improbable that I question its authenticity. Electronics still used a great many switches requiring manual operation in those days that I have to wonder if it was ever even possible. I would be very surprised if it were possible to do such a thing today.

65.163.124.39Don Granberry.

Directing an aircraft to intercept an enemy target is not much different from directing a ground to air missile to do the same thing and this was being done by Project Nike in the 1950s. Radar fire control and air defense were big areas of development during WW II and it's not surprising that they would be combined in the post war era, especially once the Soviet Union had nuclear weapons. It's my impression that the designers of SAGE quickly realized the potential of digital computers and had very ambitious goals. How well things actually would have worked in practice, during a mass air attack on the U.S., as opposed to demonstrations involving a few aircraft, is another question. Of course the same debate is playing out today over missile defense. --agr 17:16, 7 June 2006 (UTC)
Actually in this case it was much easier than something like a Nike. Basically the pilot got the aircraft airborne and flew it into a pre-allocated racetrack. If there was an interception, the pilot could turn on the data link to SAGE, which would then send updates to the autopilot to fly it to a location "near" the target, within range of the interceptor's own radar. The pilot would then fly the interception as normal from that point on.
I believe the original poster (Don) may be confused because of the wording; SAGE simply guided the aircraft, everything else was done by the pilot -- even flipping all those switches. Maury 21:14, 28 August 2006 (UTC)
It was neither easier nor harder than Nike, it was the same system: the SAGE Time-Division Data Link (TDDL) system. The AN/FSQ-7 would send data over dedicated phone lines to a AN/GKA-5V at the Ground-to-Air Transmitter/Receiver (GATR) site nearest the interceptor, BOMARC or Nike being guided. In the case of an interceptor, the pilot only had to "fly the ball" on a scope in the cockpit.

Gatr 18:25, 21 June 2007 (UTC)

The soviet home defence fighter planes were almost all based on the fully ground-directed interception principle (they did not like the pilot think too much, because he may end up defecting to the free world). The ground controllers could beam up encrypted control info to the Su-9/15, MiG-25 and later model MiG-21 planes and it would display little tilting signal flags in the attitude indicator and turn the artifical horizon ball, which the plane followed either fully automatically or via the pilot obeying the commands. This is also what F-102/F-106 was about in America, but the yankee later decided to let their own pilots think for themselves and this paid well with Top Gun school and F-15/F-16 like autonomous planes almost always ending up victorious.

[edit] External Links - Update

  1. On Guard! The story of SAGE (12 minute film at the Prelinger Archives, currently mislaid)

I think that the clip that are you are referring to have been archived at http://www.archive.org/details/OnGuard1956

155.232.128.10 10:54, 6 April 2007 (UTC) Francois

[edit] Merge in from SAGE Long Range Radar Stations?

I came across SAGE Long Range Radar Stations a couple days ago. A lot of it is copied from this article, but there does appear to be some new stuff in there. Probably either worth considerable work, or merging into this article. Rtucker 01:09, 18 April 2007 (UTC)

Tried this twice but the radar site details (new stuff) was deleted. Therefore an entry for SAGE Long Range Radar Stations was created. Sgwxly 18:37, 27 April 2007 (UTC) sgwxly

With the exception of a link to a single radar site, there doesn't appear to be anything in this article that isn't already covered in the mainline article here. I'm going to PROD it. Maury 12:11, 14 May 2007 (UTC)
Actually, that site seems to be a bit of an issue too. It points to two articles, one one the site, and one on the unit that was stationed there. These could easily be merged. However does that suggest we should add a cat for SAGE radar sites? Maybe that would be the right way to proceed? Maury 22:23, 16 May 2007 (UTC)
Dunno... how many possible articles would there be for the category? If it's just one or two in the end, it's probably not worth the paperwork. If there are enough, though, I would probably advise spelling it out as "Semi Automatic Ground Environment sites", just to avoid confusion with other SAGEs. RTucker 23:21, 16 May 2007 (UTC)