[comp.unix.xenix] X.25 Pad

dave@oldcolo.UUCP (Dave Hughes) (04/13/89)

What is the price differential between doing X.25 by
means of a X.25 external PAD, and by internal software?
Just a ballpark please.

-- 
Dave Hughes          Old Colorado City Communications
hplabs!hp-lsd!oldcolo!dave
"It is better to light one screen than cursor the darkness"
                                            Bill Robinson

derekv@dvlmarv.UUCP (Derek Vair) (04/21/89)

In article <151@oldcolo.UUCP> dave@oldcolo.UUCP (Dave Hughes) writes:
>What is the price differential between doing X.25 by
>means of a X.25 external PAD, and by internal software?
>Just a ballpark please.
>
We have a product, Netcom II, that is an X.25 communications controller for
SCO Xenix and UNIX on the AT-bus.  If you want specific information on it,
please contact me directly.

On the economics of PAD versus integrated X.25 controllers, the answers 
depend on your operating environment - essentially, how many users you're 
supporting, at what speeds, and how far you are from the nearest packet
network node.

In terms of capital investment, here's a brief analysis of costs:

    Our product costs $1950.00.  It is a coprocessor board that plugs
    into the PC, and allows the machine to connect directly to an one or two 
    X.25 links.  Each link can carry up to 32 simultaneous terminal 
    connections.  If you've got 64 users, this looks very good -  about 
    $30 per user.  For one user, it's very bad - $1950.00 per user.
    Reality is probably somewhere in the middle - say, 8-16 users per 
    link, or $60 - $120 per user. 

    Outboard PADs are available at a variety of prices, depending on the
    number of asynchronous connections and link speeds they support. 
    You can probably get outboard PADs cheaper than Netcom II, but then
    you've got to buy some kind of asynchronous communications
    controller board to provide a path for each of the terminals
    connected to remote PADs to connect to your host via the outboard
    PAD sitting beside your host.  For instance, if you buy an 8 port
    PAD, you will require at least an 8 port async card and need to run
    cables from the PAD to the card.  While individually each costs less
    than the integrated solution, the combined cost of asynchronous
    controller, ourboard PAD, and cables will probably exceed the Netcom
    II price. 

    For very small numbers of remote users (1-3), you can use an
    asynchronous PAD service from the X.25 common carrier - they can run
    an async line from their siwitch to your site for each terminal you
    want to support.  Operating cost will depend on geography and usage
    - but all you'll have to buy is the async ports and cables.  The
    carrier should do the rest. 

    If you're talking to a public packet network, your link speed will
    be limited to 19200 or 9600 bits per second, and pretty well all the
    PADs on the marketplace support those rates.  If you're using a
    private network, and can make use of 38.4 or 56 Kbit/second X.25
    links, you will have to select the PAD carefully, because a lot of
    them are limited to 9.6 or 19.2 Kbits/second. 
    
    Cost of operation will be the same, unless you get your PAD from a
    public network vendor.  Some public networks (Datapac, here in
    Canada, for example) charge a significant premium for PAD usage over
    the normal traffic charges.  If you've got a lot of traffic, network
    usage is a significant cost factor. 

Convenience may also be an issue:

    With a PAD connecting your machine to the network, you'll have some
    problems with terminal control.  For example, character echoing. 
    Either terminal traffic from remote users will be echoed by your 386
    (expensive in traffic terms, and also very poor perceived response
    time, as each character transits the packet network, gets processed
    by Xenix line discipline, and transits back to the terminal), or
    your users set their PADs up to do echoing and turn echo off in your
    Xenix application or shell (in which case, whenever they run an
    application that puts the terminal into raw mode - vi, for example -
    they have to manually change their PAD's echo control parameter to
    stop echoing the characters received). 
    
    On the other hand an integrated product should control the remote
    PAD's parameters automatically according to the termio modes of the
    "tty" that is attached to the virtual circuit. 

===============================================================================

Derek Vair				"I don't need a disclaimer - I'm
The Software Group Limited		 a principal"
#201, 4701 Steeles Avenue West
Weston, Ontario

phone: 416-747-9490
fax:   416-747-1471
email: uunet!dptcdc!lsuc!dvlmarv!tsgfred
===============================================================================