|
Note 5
FROM: Ben Barker
One of the things that has struck me in retrospect about those days is
the extent to which it was a bunch of us kids who didn't really know
what we were doing fudging it while waiting for the "grownups" to tell
us what we were supposed to do.
Weeks before I joined BBN -- in late 1968 or early 1969 -- a trip was
planned to AT&T in downtown Manhattan to learn details of how they were
implementing their 50 kb model 303 modem which we were to use in
building the net. There was concern about whether there could be
slippage between the clock and the data. We understood that the clock
was phase-locked to transitions in the data, so if there were a very
long string of zeros or ones the clock might slip a bit and it would be
impossible to transmit the data successfully.
I was asked to attend the meeting. Crowther was told to wear a suit.
As I recall, he wore a tie and jacket -- and sneakers. We were ushered
into the fanciest meeting room I had ever seen. Surrounding the solid
oak conference table were plush leather chairs. At each place was a
pad, a set of pencils, and a roll of life savers or some such hard
candy. Oh my God was I impressed! It seems that AT&T (far and away the
world's largest communications company) was going all out on behalf of
their largest customer, the U.S. Government.
As the meeting progressed, we posed our question about clocks and were
told not to worry, they scrambled the data so that a long string of
zero's or one's would be turned into a pseudo-random pattern. We asked
what would happen if the scrambler got set to all-zeros -- then further
zeros would keep it at zero and the output would be zeros. This seemed
a plausible possibility if one were sending a core dump with lots of
zero data following random data. They told us that for this reason they
inverted the data so that all zeros would be turned into all ones. We
pointed out that this meant that all ones -- e.g. two's complement minus
1 -- would be turned into all zeros and the same problem would exist.
Not to worry, they assured us, they added a counter that checks for
zeros on the output of all that other circuitry and if it finds 31
consecutive zeros, it inverts the 32nd bit. But then a pattern of 31
ones and a zero (repeated) could cause problems. No, they insisted, it
couldn't. It really felt like the grownups were berating us.
Of course they were wrong, but the likelihood is very low and if it
happens on one packet, by the time the next packet came along there
would be enough other stuff in the control parts of the packet to reset
the scrambler and the packet would go OK next time around. Nonetheless
in my diagnostic I did everything I could with long packets to try to
induce the problem just to document that it wouldn't bother us.
Another example was Honeywell's implementing Severo's block diagrams
with no sense that they should understand what the stuff was supposed to
do or test to see that it did it. They were the gigantic global
technology corporation and we were just kids -- I was a Harvard
Chemistry & Physics undergrad. How could they be so lacking in
professionalism when we were so completely committed to building and
testing a system which would work predictably and reliably? When we
found the synchronizer problem in the central timing chain of the 516
they refused to believe us despite incontrovertible evidence. Even
after I designed and rewired a fix into their CPU less than 24 hours
before we shipped to UCLA and it fixed the crashes, they were unwilling
to accept that they had a problem. For a while we had to rewire each
machine as it came through.
It must have been hard on Frank's stomach lining that he was backing a
kid such as me against world-leading technology companies such as AT&T
and Honeywell. Part of what made him a great leader was his willingness
to do so.
/Ben
One of the things that has struck me in retrospect about those days is
the extent to which it was a bunch of us kids who didn't really know
what we were doing fudging it while waiting for the "grownups" to tell
us what we were supposed to do.
Weeks before I joined BBN -- in late 1968 or early 1969 -- a trip was
planned to AT&T in downtown Manhattan to learn details of how they were
implementing their 50 kb model 303 modem which we were to use in
building the net. There was concern about whether there could be
slippage between the clock and the data. We understood that the clock
was phase-locked to transitions in the data, so if there were a very
long string of zeros or ones the clock might slip a bit and it would be
impossible to transmit the data successfully.
I was asked to attend the meeting. Crowther was told to wear a suit.
As I recall, he wore a tie and jacket -- and sneakers. We were ushered
into the fanciest meeting room I had ever seen. Surrounding the solid
oak conference table were plush leather chairs. At each place was a
pad, a set of pencils, and a roll of life savers or some such hard
candy. Oh my God was I impressed! It seems that AT&T (far and away the
world's largest communications company) was going all out on behalf of
their largest customer, the U.S. Government.
As the meeting progressed, we posed our question about clocks and were
told not to worry, they scrambled the data so that a long string of
zero's or one's would be turned into a pseudo-random pattern. We asked
what would happen if the scrambler got set to all-zeros -- then further
zeros would keep it at zero and the output would be zeros. This seemed
a plausible possibility if one were sending a core dump with lots of
zero data following random data. They told us that for this reason they
inverted the data so that all zeros would be turned into all ones. We
pointed out that this meant that all ones -- e.g. two's complement minus
1 -- would be turned into all zeros and the same problem would exist.
Not to worry, they assured us, they added a counter that checks for
zeros on the output of all that other circuitry and if it finds 31
consecutive zeros, it inverts the 32nd bit. But then a pattern of 31
ones and a zero (repeated) could cause problems. No, they insisted, it
couldn't. It really felt like the grownups were berating us.
Of course they were wrong, but the likelihood is very low and if it
happens on one packet, by the time the next packet came along there
would be enough other stuff in the control parts of the packet to reset
the scrambler and the packet would go OK next time around. Nonetheless
in my diagnostic I did everything I could with long packets to try to
induce the problem just to document that it wouldn't bother us.
Another example was Honeywell's implementing Severo's block diagrams
with no sense that they should understand what the stuff was supposed to
do or test to see that it did it. They were the gigantic global
technology corporation and we were just kids -- I was a Harvard
Chemistry & Physics undergrad. How could they be so lacking in
professionalism when we were so completely committed to building and
testing a system which would work predictably and reliably? When we
found the synchronizer problem in the central timing chain of the 516
they refused to believe us despite incontrovertible evidence. Even
after I designed and rewired a fix into their CPU less than 24 hours
before we shipped to UCLA and it fixed the crashes, they were unwilling
to accept that they had a problem. For a while we had to rewire each
machine as it came through.
It must have been hard on Frank's stomach lining that he was backing a
kid such as me against world-leading technology companies such as AT&T
and Honeywell. Part of what made him a great leader was his willingness
to do so.
/Ben
Copyright 2012-2022 @ xbbn.org under a Creative Commons license.
