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 ===============================================================================