Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site edcaad.UUCP Path: utzoo!linus!philabs!cmcl2!floyd!vax135!edcaad!dave From: dave@edcaad.UUCP Newsgroups: net.dcom Subject: Re: Anything done for uucp over X25? Message-ID: <537@edcaad.UUCP> Date: Sat, 16-Jul-83 09:10:38 EDT Article-I.D.: edcaad.537 Posted: Sat Jul 16 09:10:38 1983 Date-Received: Sun, 10-Jul-83 05:08:32 EDT References: <174@zti1.UUCP> Organization: Architecture, Edinburgh U., Scotland Lines: 31 We use UUCP over two different packet-switch nets, viz: 1. Edinburgh's RCONET - a pre-X25 net which IS capable of providing a transparent 8-bit path from a host to a terminal. This uses uucp with only one modification, a flag to halve the packet size so that a window of 3 packets fits in a PAD buffer. Performance is CATASTROPHIC (i.e. < 100 baud from a 1200 baud line). 2. BT's PSS (via a gateway from the RCONET). This, unlike 1, uses a uucp modified to use printing characters only (i.e. only 4 bits). We have tried various ways to get uucp through a less-than-8-bits path, and this is the only attempt that has even looked like it might work. It is still unusable. Performance is UNBELEIVABLY CATASTROPHIC (no figures yet). Basically, all attempts to add another layer under the packet driver are a waste of time. They almost always start from the availability of a reliable, flow-controlled path with less than 8 bits, and are trying to get to a reliable, flow- controlled path with 8 bits. If your path is already reliable and flow-controlled, you don't need the packet driver at all. The BERKNET encoding will do what you really want. If you must use a PAD, try to get one where the call setup is done via a different port from the data transfer (cf. using the DN11 ACU). I don't know of any that work this way, but talk to your supplier. It's just blowing a new PROM. David Rosenthal {mcvax|vax135}!edcaad!dave