Stumbled across:
<https://spectrum.ieee.org/cold-war-codebreaker-nsa-ibm>
Perhaps old news here.
David Lesher <wb8foz@panix.com> writes:
Stumbled across:
<https://spectrum.ieee.org/cold-war-codebreaker-nsa-ibm>
Perhaps old news here.
Even if it were old news here, that's the kind of subject that people
here would always like to talk about again.
David Lesher <wb8foz@panix.com> writes:
Stumbled across:
<https://spectrum.ieee.org/cold-war-codebreaker-nsa-ibm>
Perhaps old news here.
Even if it were old news here, that's the kind of subject that people
here would always like to talk about again.
Stumbled across:
<https://spectrum.ieee.org/cold-war-codebreaker-nsa-ibm>
Stumbled across:
<https://spectrum.ieee.org/cold-war-codebreaker-nsa-ibm>
Perhaps old news here.
On Thu, 1 Oct 2026 02:06:08 -0000 (UTC), David Lesher wrote:
Stumbled across:
<https://spectrum.ieee.org/cold-war-codebreaker-nsa-ibm>
It?s not made clear in the description, but that machine seems to be
more some kind of bulk text comparator, not a number-cruncher like the
Cray.
That would make sense if you consider that IBM machines were always
more about data processing than powerful computations. The STRETCH
machine was mentioned as failing to meet its performance goals; that
was part, perhaps even the start, of IBM?s long history of
overpromising and underdelivering.
On 10/1/2026 15:11, Lawrence D?Oliveiro wrote:
The STRETCH machine was mentioned as failing to meet its
performance goals; that was part, perhaps even the start, of IBM?s
long history of overpromising and underdelivering.
I feel there is a bit more snark here than I find justified. The
goal was a very large stretch, and the attempt to reach it did
indeed advance the state of the art a great deal, paving the way for
the 360 series.
On Thu, 1 Oct 2026 20:05:04 -0700, Lars Poulsen wrote:
On 10/1/2026 15:11, Lawrence D?Oliveiro wrote:
The STRETCH machine was mentioned as failing to meet its
performance goals; that was part, perhaps even the start, of IBM?s
long history of overpromising and underdelivering.
I feel there is a bit more snark here than I find justified. The
goal was a very large stretch, and the attempt to reach it did
indeed advance the state of the art a great deal, paving the way for
the 360 series.
That, too, led to another instance of overpromising and
underdelivering, with IBM?s FUD campaign to stop potential customers
buying machines from CDC.
On 2026-10-02, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
On Thu, 1 Oct 2026 20:05:04 -0700, Lars Poulsen wrote:
On 10/1/2026 15:11, Lawrence D?Oliveiro wrote:
The STRETCH machine was mentioned as failing to meet its
performance goals; that was part, perhaps even the start, of
IBM?s long history of overpromising and underdelivering.
I feel there is a bit more snark here than I find justified. The
goal was a very large stretch, and the attempt to reach it did
indeed advance the state of the art a great deal, paving the way
for the 360 series.
That, too, led to another instance of overpromising and
underdelivering, with IBM?s FUD campaign to stop potential
customers buying machines from CDC.
To be honest, though, this was standard behaviour throughout the
industry. I worked for Sperry->Unisys for four years, and saw many
instances of lowballing memory requirements to get a sale (the
customer would later have to spring for additional memory, but the
sale had been made by then). I finally left when I got tired of
keeping salesmen's promises for them.
IBM went much, much further. Remember, they pioneered the concept of
?FUD? (?Fear, Uncertainty and Doubt?) to scare customers off rivals? products, as notoriously happened with CDC. They didn?t have product superiority, but they had marketing superiority. Their products were
clunky, expensive and inflexible, as well as being outdated in many
ways, but they still dominated the market (at least for mainframes)
because ?nobody got fired for buying IBM?.
Amdahl won the battle to make ACS, 360 compatible ... and he left when
it was killed (folklore that they were afraid ACS/360 would advance the
state of art too fast and IBM woould loose control of the market). https://people.computing.clemson.edu/~mark/acs_end.html
the current ACS design needs 7 levels of logic per stage,
thus 12.5 nsec cycle time ...
I think IBM sought to make things difficult for these "lookalike" competitors.
This confuses me. The 370/168 -- dominant until the 3033 in the late 1970's -- had 80 nsec "cycle time", and logic gate delays
were about 2 nsec minimum even without considering line delays or anything more complicated than OR or NOR. Even the mini-"cycles" on the 370/135
were 55 nsec IIRC. What are these super-short "cycle times" repeated throughout that document?
James Dow Allen <user4353@newsgrouper.org.invalid> writes:
This confuses me. The 370/168 -- dominant until the 3033 in the late 1970's
-- had 80 nsec "cycle time", and logic gate delays
were about 2 nsec minimum even without considering line delays or anything more complicated than OR or NOR. Even the mini-"cycles" on the 370/135 were 55 nsec IIRC. What are these super-short "cycle times" repeated throughout that document?
165 370 microcode finished 370 instruction on avg. of one every 2.1
machine cycle.
Lynn Wheeler <lynn@garlic.com> posted:
Amdahl won the battle to make ACS, 360 compatible ... and he left when
it was killed (folklore that they were afraid ACS/360 would advance the
state of art too fast and IBM woould loose control of the market).
https://people.computing.clemson.edu/~mark/acs_end.html
That acs_end.html file, discussing designs of the late 1960's
contains many lines like
the current ACS design needs 7 levels of logic per stage,
thus 12.5 nsec cycle time ...
This confuses me. The 370/168 -- dominant until the 3033 in the late 1970's -- had 80 nsec "cycle time", and logic gate delays
were about 2 nsec minimum even without considering line delays or anything more complicated than OR or NOR. Even the mini-"cycles" on the 370/135
were 55 nsec IIRC. What are these super-short "cycle times" repeated throughout that document?
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 3 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 498023:38:41 |
| Calls: | 191 |
| Files: | 852 |
| D/L today: |
7 files (132K bytes) |
| Messages: | 67,724 |