Data communications over telegraph circuits 1911

Floyd L. Davidson

... and making sure that happens requires designing basic circuits much differently than most other electronic design practices.

To put it in allegorical terms: A naive view of a computer controlled smallish telephone switch might imagine a program loop - reading an A-D converter attached to each line; - looking up in a connection table where the call is connected to - storing the value into the D-A converter attached to the other line

But such a system will not retain calls during a reboot, even if the connection table is preserved: The loop will not be running.

Computer engineers want to se every component on the board be reset to a known initial state during initialization (as part of the reboot); otherwise we are open to a mulbreastude of untestable special cases where corners of the circuit have gone into states that can't happen due to electrical glitches, and there may be no simple way to get them unstuck. I have great respect for the engineers that can build computer systems that do not have such problems despite those design constraints.

A former boss had worked on the 1ESS team, and he told the store of one of the early demonstrations of the prototype system to management. Not unsurprisingly, the system rebooted in the middle of the demonstration, clearing all calls. And the big boss turned to the team boss and asked "What complete IDIOT designed a system that clears calls when it crashes?"

This is the foundation of the big divide between circuit thinking and packet thinking. Circuit thinkers are not stupid, they were just raised differently. Ironically, the packet switches deep in the Internet backbone have adopted many of the design elements of the circuit switching fabric; with switching paths hardware controlled by tables that are occasionally refreshed from computations on s specialized routing computation server board in the multiprocessor complex.

Lars Poulsen