stefan@mikros.systemware.de (Stefan Stapelberg) (07/28/88)
Hello world,
[I apologize if this question has recently been discussed here or if it
is the wrong place, but I am new to this group since a few weeks ago]
I am planning to replace my modem with a TrailBlazer and I would
like to know whether this will work OK with the UUCP left unmodified.
My system is a Siemens PC based on the braindamaged 80186 running
SINIX (derived from SIII). As far as I can tell, the UUCP version
available from Siemens will support 'g' and 'f' protocol.
Are there any restrictions concerning transmission speed and/or
error recovery with this antique version of UUCP?
How about 'f' protocol? Does it work reliable? (e.g. what happens
if there is noise on the line between the modem and the computer?)
I am very appreciated for any pointers/hints.
Thanks in advance & have a nice day
Stefan
PS: No flames on spelling/grammar please, I still write
better "C" than English.
--
MIKROS Systemware stefan@mikros.UUCP, {uunet,mcvax}!unido!mikros!stefan
Stefan Stapelberg stefan%systemware.de@uni-dortmund.de *TEST ONLY*
Phone +49 9352 5948 stefan@Germany.CSNETted@gouldnl.UUCP (Ted Lindgreen) (08/01/88)
In article <311@mikros.systemware.de> stefan@mikros.UUCP (Stefan Stapelberg) writes: >SINIX (derived from SIII). As far as I can tell, the UUCP version >available from Siemens will support 'g' and 'f' protocol. > >Are there any restrictions concerning transmission speed and/or >error recovery with this antique version of UUCP? If you use the standard setup (g-protocol) I don't see any problems. >How about 'f' protocol? Does it work reliable? (e.g. what happens >if there is noise on the line between the modem and the computer?) The f-protocol is usable as well, but you need to setup flowcontrol on both sides. The trailblazer is among the best modems there are to deal with noisy telephone lines. Normally we get speeds between 11 and 15 kbaud, I have seen this to drop to 7 kbaud on a really noisy line. The PEP protocol garanties errorfree data transmission. >I am very appreciated for any pointers/hints. OK, The g-protocol does not need flowcontrol. Hardware flowcontrol does not harm generally, but software flowcontrol must NOT be used. This is because the g-protocol uses full 8-bit characters. ^S or ^Q characters, produced by modems or terminal drivers will break the protocol. I have heard about situations where the full speed is not reached with hardware flowcontrol, but I have not seen that myself. Enable UUCP (S111=30) and turn off flowcontrol (S58=0 S68=255). For compressed news, I have seen an improvement of 10% if compression is turned OFF (S110=0). The f-protocol (switched on if the LINE field is PAD) needs error free transmission and perfect flowcontrol. Error free transmission is OK with trailblazers. Flowcontrol can be either hardware or ^S/^Q, but it has to be setup properly on both sides. The f-protocol maps all characters in the range of printable characters. Effectively, this means, that ASCII data (email) is almost unexpanded, but binary data (compressed news) is expanded with 50 to 75%. The raw speed with the f-protocol is a few percent higher than with the g-protocol (provided data compression in the trailblazer is enabled). So for email you gain a few percent, for netnews you loose a lot. The fastest protocol is the t-protocol (if you can switch it on, you need to change uucico to do that). This protocol sends 8-bit data in chunks of 1 kbyte. It will work only with hardware flowcontrol on both sides. You will gain a few percent on both binary and ascii data. However, the end of the uucico session may fail as a TCP connection is stopped in a different way. Concluding I would advice: use the standard g-protocol. The possible improvement with f- or t-protocol is only marginal. I use a fixed interface speed (19200) and hardware flowcontrol normally. To change the Trailbazer settings for a particular uucico session (we talk to different types of modems in various countries), I put the special settings in the L-dialcodes file and prepend the phone number in L.sys with the appropriate "dialcode" (this hack is needed, because our uucico refuses to use phonenumbers with letters in L.sys, using the dialcodes file one can get around that). Hope this helps, Ted. -- | Ted Lindgreen ...!mcvax!gouldnl!ted | | Gould European Unix Support Centre ted@gouldnl.nl | | Maarssenbroek, The Netherlands (USA) ...!gould!tlindgreen |
chris@mimsy.UUCP (Chris Torek) (08/02/88)
The g-protocol spoofing is neat, but here is a thought: Would it be worthwhile to write an `h' protocol, specifically designed for half-duplex high-speed not-necessarily-error-free modems? - large packets (perhaps 4KB); - a window of at least 256 packets; - checksums per packet, but - ACKs not required except at EOF or window edge - with NAKs accepted anytime; - characters ^Q and ^S reserved to the modem, with an escape encoding in the data stream I doubt it would make much difference on the TB+, but it might help other half-duplex 9600/19200/38400 bps modems. (And no, I do not volunteer to write it. :-) ) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
rpw3@amdcad.AMD.COM (Rob Warnock) (08/02/88)
+--------------- | From: chris@mimsy.UUCP (Chris Torek) | The g-protocol spoofing is neat, but here is a thought: Would it be | worthwhile to write an `h' protocol, specifically designed for | half-duplex high-speed not-necessarily-error-free modems? +--------------- Just for comparison, note that by diddling "max seg size" and "window" parameters on Phil Karn's (KA9Q) TCP/IP package, I was able to get FTP throughputs (disk to disk) of 875 bytes/sec (user data) between a PC/AT running KA9Q and a VAX 11/780 running SLIP (4.3 + recent Karels/Jacobson upgrades), with 9600 baud serial lines on both TB+'s. (Haven't tried 19200.) Note that when you count the 40 bytes of TCP/IP and the 1 byte of SLIP, it was getting 875*(512+40+1)/512 ==> 945 bytes/sec through the modems, which is over 98% of what a 9600 baud async line will do. Saying it another way, the data flow never stopped. (And you could see that on the breakout box I was watching. All the other parameter settings "stuttered" quite a lot more.) The params which got that 875 B/s throughput (VAX to PC) were MSS = 512, window = 4096 (i.e. 8 packets). Note that this equals or betters 9600 baud UUCP throughputs on the TB+, even with UUCP protocol turned on. (TB's don't have any SLIP support yet, and anyway it wouldn't have helped, as it was the RS-232 link which was saturated. You need SLIP header compression in the host, you really do.) The only trouble is, nobody (certainly not me!) has wrapped KA9Q/4.3BSD/ SLIP/FTP with the control software to let it autodial from one host to another and play exactly the sort of role uucico plays now. That would be a beginning to superseding UUCP. (Imagine, dialup SMTP, no "!" addresses...) But since you can have a Telnet session open at the same time, it *does* let me read news while I'm waiting for big files to move... Rob Warnock Systems Architecture Consultant UUCP: {amdcad,fortune,sun}!redwood!rpw3 ATTmail: !rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403
henry@utzoo.uucp (Henry Spencer) (08/03/88)
In article <311@mikros.systemware.de> stefan@mikros.UUCP (Stefan Stapelberg) writes: >I am planning to replace my modem with a TrailBlazer and I would >like to know whether this will work OK with the UUCP left unmodified. Yes. >Are there any restrictions concerning transmission speed and/or >error recovery with this antique version of UUCP? No. We ran a Trailblazer successfully with an even older uucp. >How about 'f' protocol? Does it work reliable? ... For talking to a Trailblazer, you want to use 'g' protocol, since the link from computer to modem is probably not a fully reliable path (especially if your serial i/o hardware isn't too good -- the high speeds will quickly expose any flaws there). As I understand it, the 'f' protocol was built originally for networks that didn't get along well with 'g' protocol (but provided fairly reliable flow-controlled transmission on their own); this situation is different. -- MSDOS is not dead, it just | Henry Spencer at U of Toronto Zoology smells that way. | uunet!mnetor!utzoo!henry henry@zoo.toronto.edu
les@chinet.chi.il.us (Leslie Mikesell) (08/05/88)
In article <12793@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >The g-protocol spoofing is neat, but here is a thought: Would it be >worthwhile to write an `h' protocol, specifically designed for >half-duplex high-speed not-necessarily-error-free modems? YES! But to make it really worthwhile, uucico would need to be changed to batch the files. > - large packets (perhaps 4KB); > - a window of at least 256 packets; > - checksums per packet, but > - ACKs not required except at EOF or window edge When sending small mail messages or the X.* files from uux, the file boundaries will be smaller than the window boundaries. Requiring an ACK at EOF (and one at the start) will defeat much of the gain if line turn-around is slow. The file handling should be windowed to match the packet window - that is, do not require any ACKs except at the window edge or at the end of the connection, when all files must be ACKed. > - with NAKs accepted anytime; > - characters ^Q and ^S reserved to the modem, > with an escape encoding in the data stream Why would anyone do it any other way? Les Mikesell
W8SDZ@SIMTEL20.ARPA (Keith Petersen) (08/08/88)
[a proposal from Chris Torek for a new uucp protocol which would have
long packets and no ACKs required from the receiver]
Chris, the protocol you propose is already written. It's called
ZMODEM (by Chuck Forsberg). It meets all the criteria you specified.
I've been using Zmodem to upload all the files I add to our public
domain archives at SIMTEL20. It's very robust - even allows picking
up "where you left off" if you get disconnected!
I wish the Usenet community would take a closer look at Zmodem. Chuck
has all the hooks in it for remote restricted shell logins for
up/downloading.
The most current version of Chuck's RZ/SZ program for Unix and VAX/VMS.
is kept in the PD1:<MISC.ZMODEM> directory at SIMTEL20.ARPA. The
files are updated whenever Chuck releases a new version.
--Keith Petersen
Maintainer of the CP/M and MSDOS archives at SIMTEL20.ARPA [26.0.0.74]
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {decwrl,harvard,lll-crg,ucbvax,uunet,uw-beaver}!simtel20.arpa!w8sdz
GEnie: W8SDZ
RCP/M Royal Oak: 313-759-6569 - 300, 1200, 2400 (V.22bis) or 9600 (USR HST)mangler@cit-vax.Caltech.Edu (Don Speck) (08/26/88)
In article <27022@oliveb.olivetti.com>, jerry@olivey.olivetti.com (Jerry Aguirre) writes: > The practical problem comes up when you try to tell the modem what > protocol to support. You probably don't know when you are initializing > the modem and dialing so you have to assume the 'g' protocol. Later, > UUCP will negotiate a protocol and decide that both sides support this > new protocol. Great! Now how do you tell the Trailblazer that you > changed your mind? This problem can be sidestepped by making the new protocol upward compatible. For instance, fix the packet size negotiation bugs in the "g" protocol, offer it as both the "g" and "G" protocol, and if the "G" protocol is chosen by the remote uucico (indicating that it too has the bug fixes), then negotiate a 128-byte or 256-byte packet size. This should be simple enough to implement that it could actually happen. N.B. Packet sizes larger than the tty input buffer won't decrease the read() overhead any further, and big packets are inefficient for small files, so you don't want to negotiate any higher than 256 bytes. Don Speck speck@vlsi.caltech.edu {amdahl,ames!elroy}!cit-vax!speck
jerry@olivey.olivetti.com (Jerry Aguirre) (08/30/88)
In article <7708@cit-vax.Caltech.Edu> mangler@cit-vax.Caltech.Edu (Don Speck) writes: >This problem can be sidestepped by making the new protocol upward >compatible. For instance, fix the packet size negotiation bugs in >the "g" protocol, offer it as both the "g" and "G" protocol, and if >the "G" protocol is chosen by the remote uucico (indicating that it >too has the bug fixes), then negotiate a 128-byte or 256-byte packet >size. This should be simple enough to implement that it could actually >happen. This sounds like a great idea. The small 'g' packet size is not optimal for present day line speeds. What would be even better is if the modem could spoof the packet size negotiation and repackage the packets for the remote end. That way I could take advantage of larger packet sizes even if the remote system hasn't upgraded his software. >N.B. Packet sizes larger than the tty input buffer won't decrease the >read() overhead any further, and big packets are inefficient for small >files, so you don't want to negotiate any higher than 256 bytes. So, I'll make the tty buffers bigger. There is a problem with reliability though. A one byte CRC(?) per packet isn't really enough when you get much larger packets.
hamilton@osiris.cso.uiuc.edu (08/30/88)
don speck(?) says: > N.B. Packet sizes larger than the tty input buffer won't decrease the > read() overhead any further, and big packets are inefficient for small > files, so you don't want to negotiate any higher than 256 bytes. [i hope i'm not putting my foot in my mouth by speaking before checking...] what would it hurt to negotiate a huge *max* packet size (say, 1024+), since you can always send smaller packets. every packet carries a size field; if the code is written correctly, packets only as large as needed will be sent. i modified my uupc to do this, but when my uucp neighbor sent me 256-byte "HY" messages, i took it out again. wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,seismo,pur-ee,uunet}!uiucuxc!osiris!hamilton ARPA: hamilton@osiris.cso.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%osiris@uiuc.csnet Phone: (217)333-8703
klg@njsmu.UUCP (Kenneth Goodwin) (08/31/88)
> In article <7708@cit-vax.Caltech.Edu> mangler@cit-vax.Caltech.Edu (Don Speck) writes: > >too has the bug fixes), then negotiate a 128-byte or 256-byte packet > >size. This should be simple enough to implement that it could actually > > could spoof the packet size negotiation and repackage the packets for > the remote end. That way I could take advantage of larger packet sizes > even if the remote system hasn't upgraded his software. > > > So, I'll make the tty buffers bigger. There is a problem with > reliability though. A one byte CRC(?) per packet isn't really enough > when you get much larger packets. This is getting to be really interesting. I had in fact made several suggestions to Telebit along these lines a while back when they posted a request for suggestions to the net. The basic idea was to use some of the apparently unused S registers in the modem to program the attributes of the protocol. You would set for UUCP, Kermit or Xmodem styles with one register, and with the others, select packet sizes, CRC or NO CRC checksumming, ACK or NO ACK's and what have you. Remember that IT DOES NOT MATTER what the TB+ at the other end of your connection is doing. The TB+ does protocol spoofing between your computer and your TB+ and transmit's PEP protocols to the other TB+. My understanding is that PEP does not contain any UUCP header information. ((Telebit?)) Ideally for TB+'s on a reliable comm port on your computer you could set the TB+ for: 1) 19.2 KB computer to modem transmission rates 2) UUCP Protocols 3) 256 byte input packet size (if you change the tty drivers to allow larger raw input limits then this number can be as big as needed....) 4) 16KB (or larger) output packet size (on the fly if necessary) (set to filesize if less than the largerst desirable packet size) 5) NO CRC checksum bytes, you probably don't need them because PEP takes care of the transmission, and CRC is only cuurently being used between the computer and the local TB+. the basic idea is that you can configure the TB+ AS YOU LIKE IT to maximize throughput between your computer and your TB+. If you CU (tip) out, you should be able to TURN off UUCP spoofing altogether and eliminate the PEP overhead.... NOT that all these will greatly increase uucico throughput unless the other end likewise configures it's TB+. Throughput will still be restricted to the weakest link in the chain.. One possibility of all this is that it may be possible for a UUCP site to talk to a Kermit site without "knowing" it, if both have the NEW TB+'s since it may be possible for the TB+'s to act as protocol converters. It would sort of follow this scenario: 1) System A open's it TB+ and configures baud rate (via autobaud) and desired protocol and protocol attributes. Say UUCP with 256 INPUT and 4 KB output packet sizes, NO CRC bytes in packet. (UUCP G+ protocol :-) ) 2) SYSTEM A calls SYSTEM B's TB+ and logs into an account that is attached to a kermit remote server program (the kermit uucico equivalent) System B configures it's TB+ for Kermit protocols with desired kermit packet attributes. 3) TB+ system A handshakes with TB_ System B and exchanges protocol information UUCP <-> KERMIT (NOTE PEP protocol must have protocol update control packets so when either system changes it's computer<->modem protocol the other end is immediately informed of the changes in protocol and changes it's behavior accordingly. If the protocols are the same, then nothing needs to be done. If the protocols are different, then the TB+ must reformat the packets from one format to another. ie. (turn a uucp S command packet into the kermit equivalent before (after) PEP transmission) actually it should be uucp <-translation to-> generic PEP <- translation to -> kermit in other words, take all the abilities of all known transmission protocols, (uucp, kermit, ?modem) and roll them into a superset PEP protocol structure. Have the TB+ translated from the spoofed protocol (ie UUCP) into PEP at the local end, transmit the PEP protocol to the other end, and have the remote TB+ translate from the PEP protocol to the remote spoofed protocol (ie, kermit). The TB+ may be doing something along these lines anyway (Telebit?) Ken Goodwin NJSMU.
les@chinet.UUCP (Leslie Mikesell) (09/02/88)
> actually it should be > uucp <-translation to-> generic PEP <- translation to -> kermit Given that kermit is available for most everything that uucp runs on (and is free!) why would anyone bother with this? My opinion is that the popularity of trailblazers on unix machines relates to the difficulty in switching to a better protocol for high-speed links with a turnaround delay. Dos users would just use Zmodem, sliding windows kermit, or a commercial alternative that will also work through packet switches or over satellite links regardless of the modem. What unix users really need is a replacement for uucico that can run in streaming mode. Les Mikesell
honey@umix.cc.umich.edu (Peter Honeyman) (09/02/88)
the tb knows 'g', but does not know the uucp transaction protocol (S, R, C, H, P, etc.). stripping the 'g' frame would require spoofing the upper level as well. this is hard, so the tb doesn't bother; it sends the 'g' frame intact and models the 'g' state machine. this rules out a uucp/kermit gateway. i echo les' question -- why would anyone bother? -- but not his other sentiments. peter
les@chinet.UUCP (Leslie Mikesell) (09/02/88)
In article <4560@umix.cc.umich.edu> honey@citi.umich.edu (Peter Honeyman) writes: [kermit <-> uucp] >i echo les' question -- why would anyone bother? -- but not his other >sentiments. OK, I'm open to suggestions. What is the best way to do file transfers over a satellite link? I will be working with a ku band system using a double hop (small dish <-> large hub <-> small dish) which will make at least a 2 second delay plus any internal packet contention. Physically, the connection looks like an X.25 pad. Preliminary tests showed throughput using 'g' protocol over a 2400 baud connection to be about the same as a 300 baud direct line. I will also be talking to non-unix machines over the same connections, some tty-like, some with an alternate protocol (probably kermit, using long packets and/or sliding windows depending on the remote). An alternative to 'g' protocol would help, but that would still have a large overhead on the upper level transactions when the files are small. Since mail files tend to be small and also generate an additional X file, perhaps they should be bundled together up to a certain size before transmission. Also keep in mind that I do not have uucp source so any changes will have to be a replacement for uucico rather than a modification. None of the remote sites are currently running SysVr3 which rules out the (perhaps best) solution of writing a STREAMS driver for the link and using 'e' protocol. I believe that I can compile code for all of the unix machines involved at present, but that may not always be true. These last difficulties are the reason I suggested that people are buying the 'g' spoofing trailblazers for unix machines rather than switching to a protocol that doesn't require any help. Les Mikesell
rpw3@amdcad.AMD.COM (Rob Warnock) (09/03/88)
In article <6469@chinet.UUCP> les@chinet.UUCP (Leslie Mikesell) writes: +--------------- | OK, I'm open to suggestions. What is the best way to do file transfers over | a satellite link? I will be working with a ku band system... at least a | 2 second delay plus any internal packet contention. Physically, the connection | looks like an X.25 pad... +--------------- You might seriously consider TCP/IP! That's right, TCP/IP with SLIP on the async line. I have benchmarked file transfers over a Telebit Trailblazer from a VAX-11/780 (standard Berkeley 4.3 w/ SLIP driver) to a PC with Phil Karn's "KA9Q" code and I found that by tuning the max-seg size and window size I got disk-to-disk rates slightly better than I was getting with UUCP over the same Trailblazer between two Unix systems. (The TCP/IP rate was 875 bytes/sec; UUCP was 820. The Telebit was configured to a "locked" 9600 baud, not 19200, as one of the UUCP sites had a rate limit. TCP MSS = 512, window = 4096.) By cranking up the window size, you should get acceptable results over your satellite link. After all, the ARPAnet uses TCP/IP over satellites... ;-} ;-} +--------------- | Also keep in mind that I do not have uucp source so any changes will have to | be a replacement for uucico rather than a modification... +--------------- The KA9Q source is available for non-commercial use, and can run both on a PC and in user mode on a Unix system that does not have any networking. (Phil Karn will negotiate commercial rights.) There are also other sources for TCP/IP software. But any Unix system that supports SLIP should be usable (with some tuning, to be sure). Rob Warnock Systems Architecture Consultant UUCP: {amdcad,fortune,sun}!redwood!rpw3 ATTmail: !rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403
duncan@comp.vuw.ac.nz (Duncan McEwan) (09/05/88)
In <4560@umix.cc.umich.edu> honey@citi.umich.edu (Peter Honeyman) writes: >stripping the 'g' frame would require spoofing the upper level as well. Why does simply stripping the 'g' frame from each packet mean that the tb has to know about the H, S, C, etc messages? What am I missing? >this is hard, so the tb doesn't bother; it sends the 'g' frame intact >and models the 'g' state machine. If full 'g' frames are sent intact, what exactly does the tb's 'g' protocol spoofing involve and what do you gain from it? I can see that if the tb generates ack's locally, the local uucico would not have to wait for a full round trip time to receive it, but that is what the send window is for isn't it? Answers by email would probably be best since I guess most readers of this group are familiar with the Trailblazer. They have only just become available in NZ, and all I know about them is what I have read in comp.dcom.modems and the advertising glossies. I haven't seen much about the 'g' protocol spoofing in either. Duncan
dave@arnold.UUCP (Dave Arnold) (09/06/88)
Peter writes: > the tb knows 'g', but does not know the uucp transaction protocol (S, > R, C, H, P, etc.). S - Send R - Receive C - Copy complete H - Hangup What is P? > stripping the 'g' frame would require spoofing the > upper level as well. Well... I though about this, and I don't understand Peter, why? If 'e' was used why would the tb+ have do do transaction protocol spoofing? -- Dave Arnold dave@arnold.UUCP {cci632|uunet}!ccicpg!arnold!dave
honey@umix.cc.umich.edu (Peter Honeyman) (09/06/88)
Dave Arnold writes: >What is P? select protocol. there's also X, but i honey danber doesn't support it. (and i forget what it did.) >> stripping the 'g' frame would require spoofing the >> upper level as well. > >Well... I though about this, and I don't understand Peter, why? your confusion is justified -- not even the higher-layer spoof can signal end of file. eof can probably be indicated with tb trickery, obviating 'g' framing, but read on. >If 'e' was used why would the tb+ have do do transaction protocol >spoofing? it wouldn't. but 'e' is a bad idea: a checksum is necessary to insure end-to-end reliability, and flow control (the window) is important to insulate against serial port overflow. i view with some skepticism the myriad proposals for high-tech spoofery. admit it: the existing uucp spoof gives stupendous throughput on voice-grade lines. 'g' imposes an overhead of less than 10%, and offers guaranteed compatibility with all known versions of uucp, for all time. sure, you can beat 'g', but i maintain that you shouldn't try. also, i have some idea what it takes to make the modem spoof. time and money, you are thinking, and you're right. lots of time, ergo lots of money. on the other hand, proposals to pack mail files into larger bundles appear fruitful, but this is necessarily a host concern. it seems unlikely to me that telebit will do much to improve the uucp spoof. telebit has captured the high-speed uucp market, and is proceeding to saturate it. i would guess that their next move will be to go after bigger fish. capitalism, ya know? peter
dave@arnold.UUCP (Dave Arnold) (09/07/88)
Peter writes: > Dave Arnold writes: > >What is P? > > select protocol. there's also X, but i honey danber doesn't > support it. (and i forget what it did.) I think that it was so obvious, it escaped me. Der... How many times have I run cico with -x 9 and seen the 'P' and 'U' messages?? I believe X means execute UUCP command, or something. Dave -- Dave Arnold dave@arnold.UUCP {cci632|uunet}!ccicpg!arnold!dave