From: naddy@mips.ruessel.sub.org (Christian Weisgerber)
Newsgroups: comp.dcom.isdn
Organization: My Individual Private Site
Subject: Re: Asynchronous TAs
Keywords: RS-232 asynch synch 57.6K 56K
Summary: where are they?
Reply-To: naddy@mips.ruessel.sub.org
X-Software: HERMES GUS 1.10 Rev. Dec 18 1992
Date: Fri, 25 Dec 1992 23:26:42 CET
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

In <1992Dec23.192710.3006@xenitec.on.ca>, Vance Shipley writes:

> Of all the ISDN terminal adaptors I have seen very few provide asynchronous
> speeds above 19.2K.  None of the TAs I have seen provide faster than 38.4K.

See below.

[...]
> There is a popular misconception that asynch can only support 19.2K.  This
> is simply untrue, any lowly 16540 UART can handle 57.6, 76.8 and even 115.2K!

Yes and no. The electrical specifications for a standard serial port,
V.28 (->EIA232), set a maximum transmission speed of 20000bit/s. That's
also the reason that V.110 is limited to 19.2kbps. The CCITT can hardly
disregard its own recommendations.

BTW, if we take this approach, I would like to see it implemented this
way:
The connection DTE<->TA should run at a commonly supported speed close
to or higher than 64kbps, with hardware flow control i.e. RTS/CTS, the
TA should bidirectionally buffer the data, strip start/stop bits, and
run a standardized HDLC-type protocol (LAPB?) over the ISDN line, This
way we also have flow control DCE-DCE, and most important efficient
usage of the B channel. Basically the TA should just behave like a
modern high speed error correcting modem, only faster. Running V.42bis
DTE<->DTE would be an obvious extension.
I think this scheme is already included in CCITT recommendation V.120.

> This means that almost all PCs in use today can handle the speeds I suggest.
> The cost of doing synchronous on a PC today is astronomical in comparison.

Actually I think TAs are the least interesting for PCs. The PC market is
so huge that it can sustain simpler machine-dependend solutions. An
external 57.6/76.8kbps TA would be more appealing for other
architectures where the prices of machine specific ISDN devices
skyrocket. Not all the world is an "industry standard PC"

However, the overhead or "cost" of running high speed asynchronous
serial connections is rather high. If an interrupt is signaled for every
character you tie up a lot of CPU power. Even with buffered UARTs you
don't want to do this with a Unix system, do you? You can avoid this by
using intelligent I/O subsystems offering (multiple) serial ports
managed by a micro-controller of its own, but that's not exactly cheap
or simple either.

So, why go through the async-serial bottleneck at all? Especially with
PCs?

> Of course the other choice here is to get a TA which goes in the PC and
> eliminates the asynchronous problem.  This is only a solution for DOS users
> because of driver availability.  

The cheapest way to provide ISDN for a PC is a simple expansion card
with no intelligence of its own. Two chips by Siemens (AMD), some low
level stuff, that's it. About as difficult as a serial card. In quantity
of a few thousand production price should be about $70 and will become
cheaper when ISDN chip prices drop. Very competitive when compared to a
high speed modem.

Yes, most work has to be done in the driver or application layer. Yes,
this can be a problem with the multitude of operating systems around.
But not any more than with other high performance peripherals like hard
disk controllers, video boards etc. However, multi-layered drivers
should provide high portability between different platforms.

Within a few years ISDN will be everywhere. In Germany Telekom has
announced nationwide ISDN availability for the end of 1993. (We already
have urban availability.) From what I read in this group the U.S. seems
to be legging behind, but for how long?

I think it's time for some serious industry standards concerning ISDN.

-- 
Christian "naddy" Weisgerber, Germany           naddy@mips.ruessel.sub.org
Newsgroups: comp.dcom.isdn