Back before people used ASYNC, everything was synchronous.

Everything, almost everything, I should say, on long-lines is, synchronous. Error rates are orders of magnitude down from what they are on ASYNC, yet you seem to believe it's more reliable to waste tons of bandwidth using high data rates doing character-by-character i/o perhaps with parity, as opposed to synchronous block transmission with ECC. Error rates on ASYNC are managed by parity, in general. Just consider that parity NEVER catches two-bit errors, rare as they may be.

Just consider ETHERNET, or TDMA as used on the world-wide telephone network. What part of that do you think is asynchronous? Yes, you talk to a statmux via RS232, and probably at a rate far exceeding the RS232 limits, but what goes out the V.32 line is synchronous. That's because bandwidth is time and time is money. I know of no PPSN that uses async protocol, though x.25 allows you to talk to the interface in async.

No network with high-bandwidth and high traffic volume is going to waste even 1% of its stock-in-trade, which is bandwidth, because someone is wasting 3 or 4 bits per byte using ASYNC protocol.

It's true, synchronous data streams are long, but they are coupled with their clock, either by virtue, for short links, of the presence of a discrete clock line, or by virtue of the embedded clock in the data modulation. If you lose synchronization, the block is lost. That's why there are error recovery protocols. In some cases the use a retransmit, in others they use error correction, or a combination of the two. Just consider the satellite channel that routes your phone or internet connection. Do you really think they use async, even for an 8kbps control channel?

There's got to be a reason why smart data handlers operate with synchronous protocols. Async is used where the links are short, the bit error rate unimportant, and the data rates are low.

RE