lee@rochester.UUCP (Lee Moore) (09/27/85)
I am considering running UUCP over Tymnet in async mode. I know
that I have to put the line into "transparent" mode (8-bits...) but
is there anything else to know? Has anybody else tried this?
Does the jerkiness of in the arrival rate of characters over
Tymnet make any difference?
thanks!
--
TCP/IP: lee@rochester.arpa
UUCP: {seismo, allegra, decvax, cmcl2, topaz, harvard}!rochester!lee
XNS: Lee Moore:CS:Univ Rochester
Phone: +1 (716) 275-7747, -5671
Physical: 43 01' 40'' N, 77 37' 49'' W
-- 11 months 'till I drop off the face of the earth.clewis@mnetor.UUCP (Chris Lewis) (09/29/85)
In article <11886@rochester.UUCP> lee@rochester.UUCP (Lee Moore) writes: >I am considering running UUCP over Tymnet in async mode. I know >that I have to put the line into "transparent" mode (8-bits...) but >is there anything else to know? Has anybody else tried this? >Does the jerkiness of in the arrival rate of characters over >Tymnet make any difference? You also have to turn off all control characters and make the timer (timeout before sending incomplete packets) as short as possible (I believe it's 50 Msec.). Unfortunately, that still has things very slow. We tried it on 9600 loopback to our local switching office, and the average effective transfer rate was about 1400 baud. (64Ms to load buffer, 50Ms to timeout and send the buffer, 50Ms for the other end to timeout on the buffer acknowledge). Yech. If you can try using an X.25 Pad and the 4.3 UUCP. 4.3 UUCP supports pads (protocol "f") directly. We are getting 5600 baud effective thru-put with it. The major problems with 4.3 is twofold: 1) Uses 7 bit mode, so binary files go up in size. 2) Assumes "error free" transmission, and only ships a checksum at the end of the file. In our case, one of the ends cannot guarantee reception of characters even at 2400 baud with flow control, so we die a lot. This shouldn't be a problem with a better UNIX machine (our Pyramid is not the problem) -- Chris Lewis, UUCP: {allegra, linus, ihnp4}!utzoo!mnetor!clewis BELL: (416)-475-8980 ext. 321
jordan@ucbvax.ARPA (Jordan Hayes) (10/01/85)
Yeah, I want to do this with telenet and I can't find any bloody docs for it ... anyone doing this? ------------ Jordan Hayes jordan@UCB-VAX.BERKELEY.EDU UC Berkeley ucbvax!jordan +1 (415) 835-8767 37' 52.29" N 122' 15.41" W
hamilton@uiucuxc.CSO.UIUC.EDU (10/02/85)
>In article <11886@rochester.UUCP> lee@rochester.UUCP (Lee Moore) writes: >>I am considering running UUCP over Tymnet in async mode. I know >>that I have to put the line into "transparent" mode (8-bits...) but >>is there anything else to know? Has anybody else tried this? > >You also have to turn off all control characters and make the timer >(timeout before sending incomplete packets) as short as possible >(I believe it's 50 Msec.). Unfortunately, that still has things very >slow.... If you can try using >an X.25 Pad and the 4.3 UUCP. 4.3 UUCP supports pads (protocol "f") >directly. We are getting 5600 baud effective thru-put with it. >The major problems with 4.3 is twofold: > 1) Uses 7 bit mode, so binary files go up in size. > 2) Assumes "error free" transmission, and only ships a checksum > at the end of the file. In our case, one of the ends cannot > guarantee reception of characters even at 2400 baud with > flow control, so we die a lot. >Chris Lewis, i had a similar problem trying to run uucp thru a mux that stole the parity bit and did it's own flow control. some colleagues here also needed to run uucp thru a sytek localnet. i also had chris's problem #2 -- even tho my muxes guaranteed error-free transmission 6 miles across town, i couldn't count on the 6 FEET from the mux to my 68000 box (it occasionally got overrun at speeds over ~2400 baud). so i cooked up a variation on the "f" protocol. i substituted a couple of routines for the "read" and "write" used by the code in pk1.c. these new routines do byte stuffing/unstuffing like the "f" protocol before/after calling the "real" read and write. in my case, i modified the stuffing to leave "benign" control chars (newline, tab, etc) alone; my problem was with ^S/^Q and anything >= 0200. the actual protocol is still "g" (renamed "h"), so you still get per-packet acks and checksums. thruput isn't too bad; the people using the sytek lan get 450 bytes/sec over 9600 baud for large, mostly text, files. if the pk1.c code does reads and writes of whole packets (i never really deciphered it), you could add an end-of-message character to each packet to avoid waiting for timeout (i'm pretty sure sytek has such a feature; maybe tymnet does also?). the biggest hassle with my solution is keeping 2 versions of uucico around, and arranging for the right one to be invoked when needed. one of these days i'll go back and make it use the "brand" field in L-devices or something like that. wayne hamilton UUCP: {ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton ARPA: hamilton@uiucuxc.cso.uiuc.edu CSNET: hamilton%uiucuxc@uiuc.csnet USMail: Box 476, Urbana, IL 61801 Phone: (217)333-8703
piet@mcvax.UUCP (Piet Beertema) (10/07/85)
....in my case, i modified the stuffing to leave "benign" control chars (newline, tab, etc) alone; my problem was with ^S/^Q and anything >= 0200. the actual protocol is still "g" (renamed "h"), so you still get per-packet acks and checksums. thruput isn't too bad As expected, on a local net. But don't try to use it over international X.25/PAD links: the throughput will go way down, the bills way up... ...if the pk1.c code does reads and writes of whole packets (i never really deciphered it), you could add an end-of-message character to each packet to avoid waiting for timeout That's the approach I took before writing the f-proto. It worked, but still was too slow because of the ack packets, and expensive: the g-proto writes 64 bytes + header (6 bytes), which is 2 (64-byte) segments, the X.25 accounting unit; the ack packet is another segment; so you pay for three segments to get one across..... -- Piet Beertema, CWI, Amsterdam (piet@mcvax.UUCP)