michael@fgh.fgh.oz.au (Michael Coyne) (01/23/91)
I am using UUCP between two 4800 baud MNP4 modems - one in Holland, and the other in Sydney, Australia. My effective throughput is only about 2400 baud. I suspect that this is due mainly to UUCP using a small packet size, with relatively frequent pauses to wait for acknowledgments which have to travel halfway around the world. Examination of the TD/RD lights on my modem seems to confirm this - with a short burst on TD, followed by a longish pause, then a flicker of RD. The remote machine is a mostly idle Tower 650, but even it should be able to respond to UUCP fairly quickly :-). Has anyone had a similar experience, and able to offer me any advice about how to improve my throughput? At $1.60/minute, and with Megabytes to ship, every little bit helps. The sort of areas where I am hoping I might be able to do something are: 1. Tell UUCP to increase its packet size. With a reliable modem connection, acknowledgements could be sent much less frequently. I know there are e, f and g protocols for UUCP, but I am not which is good for what - or even how to activate them. 2. Use a completely different file transfer protocol. Does GNU have a UUCP look-alike? Thanks in advance. -- Michael Coyne FGH Decision Support Systems P. L. ACSnet: michael@fgh.fgh.oz Suite 101, 77 Pacific Hwy, Internet: michael@fgh.fgh.oz.au Nth. Sydney. 2060. Australia. UUCP: uunet!fgh.fgh.oz.au!michael PHONE: +61 2 957 4224
merce@iguana.uucp (Jim Mercer) (01/24/91)
In article <267@fgh.fgh.oz.au> michael@fgh.fgh.oz.au (Michael Coyne) writes: >I am using UUCP between two 4800 baud MNP4 modems - one in Holland, and >the other in Sydney, Australia. My effective throughput is only about >2400 baud. I suspect that this is due mainly to UUCP using a small >packet size, with relatively frequent pauses to wait for >acknowledgments which have to travel halfway around the world. >Examination of the TD/RD lights on my modem seems to confirm this - >with a short burst on TD, followed by a longish pause, then a flicker >of RD. The remote machine is a mostly idle Tower 650, but even it >should be able to respond to UUCP fairly quickly :-). > >Has anyone had a similar experience, and able to offer me any advice >about how to improve my throughput? At $1.60/minute, and with Megabytes >to ship, every little bit helps. > >The sort of areas where I am hoping I might be able to do something are: > >1. Tell UUCP to increase its packet size. With a reliable modem connection, >acknowledgements could be sent much less frequently. I know there are >e, f and g protocols for UUCP, but I am not which is good for what - or >even how to activate them. > >2. Use a completely different file transfer protocol. Does GNU have a >UUCP look-alike? i experienced the same type of performance loss when trying to get g protocol to work over X.25. is the link "transparent" or does it have an underlying protocol like X.25? here's a couple of things you can try: 1) make sure the "windows" variable is set higher than 3 (7 preferably) windows can be changed by examining the source (if you have it) or with a debugger (and some assistance from the tech people providing your unix binaries this is what i did for SCO Xenix 2.2.1) a low windows value means that the uucico's will wait for an acknowledge from packet n+1 after sending packet n+3. bumping it to 7 means more data is in transit and it can live with a longer acknowledge time. 2) use another protocol. if the link is kept clean by hardware (MNP?) you could use something like the x, f or e protocols that do less error checking and basically just stuff the file down the pipe with a checksum at the end of the file. hope this helps. -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "Clickity-Click, Barba-Trick" - The Barbapapas ]
igb@fulcrum.bt.co.uk (Ian G Batten) (01/24/91)
In article <1991Jan24.033322.7924@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: > 2) use another protocol. if the link is kept clean by hardware (MNP?) > you could use something like the x, f or e protocols that do less > error checking and basically just stuff the file down the pipe with > a checksum at the end of the file. Don't do this unless you have ``f''. ``e'' doesn't even send a checksum and relies on a TOTALLY reliable link layer. That means that the error rate in your modem<->host cables, UART overruns, etc become real issues. ``x'' requires the ability to send zerolength packets to reflect end of file. You may have trouble doing this over a modem (or indeed over BT's PSS or other X25 offerings). ``f'' does send a checksum, but you should be aware that it expands anything with the top-bit set to two bytes, being intended to work over 7 bit links. And you probably don't have it anyway. I get 700cps transatlantic with no fiddling with my trailblazer. ian
avg@hq.demos.su (Vadim Antonov) (01/24/91)
In <267@fgh.fgh.oz.au> michael@fgh.fgh.oz.au (Michael Coyne) writes: >I am using UUCP between two 4800 baud MNP4 modems - one in Holland, and >the other in Sydney, Australia. >Has anyone had a similar experience, and able to offer me any advice >about how to improve my throughput? At $1.60/minute, and with Megabytes >to ship, every little bit helps. Buy Telebits! Saving some 50 hrs of communication time (a couple of months of work) will cover your expences for these devices. These beasts are really wonderful! We're running an inernational link Moscow-Helsinki over *extermely* terrible phone line with an effective speed about 7000 bps (actually we have T2500 and TrailBlazer at the ends). Over quality lines it'll be much better. Telebits know UUCP and reassemble packets at the ends sending ACKs immediately (it's especially good for satellite links). The only drawback of using Telebits is rather small efficiency on small files - but it can be easily defeated using some batching scheme (say BSMTP; anyway batchers are rather simple and it's nothing more than a programming etude for a couple of days). T2500 is a good choice taking into account it supports V.21, V.22, V.22bis, Bell 103, Bell 212, V.32, V.42bis (LAP-M), MNP-5 and PEP (native mode protocol). The seventh relese of firmware contained a bug so I recommend you to use T2500 with a firmware rel. GE 6.00 (it does not support protocol spuffing over V.32, but it's nearly useless). Vadim Antonov DEMOS, Moscow, USSR
csg@pyramid.pyramid.com (Carl S. Gutekunst) (01/25/91)
>2) use another protocol. if the link is kept clean by hardware (MNP?) > you could use something like the x, f or e protocols that do less > error checking and basically just stuff the file down the pipe with > a checksum at the end of the file. Don't use 'e'; it has no error checking at all. Don't use 'x'; it just plain doesn't work (never has, and never will -- its design is flawed). 'f' is fine. Or use a TrailBlazer. On international links, it'll pay for itself quickly. <csg>
lancelot@spock.UUCP (Thor Lancelot Simon) (01/26/91)
In article <267@fgh.fgh.oz.au> michael@fgh.fgh.oz.au (Michael Coyne) writes: >I am using UUCP between two 4800 baud MNP4 modems - one in Holland, and >the other in Sydney, Australia. My effective throughput is only about >2400 baud. I suspect that this is due mainly to UUCP using a small >packet size, with relatively frequent pauses to wait for >acknowledgments which have to travel halfway around the world. If you're sending megabytes of data, I would assume you're compressing it. But MNP is not really 4800 bps. It is 2400bps with a data compression scheme which will get, *at best* 4800bps throughput. If you're sending data that is already compressed, throughput should drop to BELOW 2400 bps. The only reason it wouldn't is that MNP makes slight improvements on 2400 bps using a link scheme that eliminates stop bits. If you stop compressing your data on the sending host, throughput will rise, but the files will be proportionately larger, and your compression at the sending site is probably superior to the modem's. To me, MNP modems have always been a fairly obvious waste of money if used for file transfer - I can do far better compression before I send the data, and only have to buy a 2400 bps modem. >2. Use a completely different file transfer protocol. Does GNU have a >UUCP look-alike? There are other UUCP protocols. You'd probably want e or f protocol. x protocol, to my knowledge, doesn't work. One of e and f does NO error correction, and I wouldn't use it even over a reliable link unless I was sure that no data could get lost along the way. Berkeley t protocol is similar, because it depends on TCP/IP to keep track of the data. What I would suggest, however, is that you look into some of the less often used options on Chuck Foresberg's RZ/SZ programs, some of which can perform uux-like functions. If you can get it working, I think you'll far prefer Zmodem to any of the UUCP protocols. >Michael Coyne FGH Decision Support Systems P. L. >ACSnet: michael@fgh.fgh.oz Suite 101, 77 Pacific Hwy, >Internet: michael@fgh.fgh.oz.au Nth. Sydney. 2060. Australia. >UUCP: uunet!fgh.fgh.oz.au!michael PHONE: +61 2 957 4224 ******************************************************************************* *Thor Simon * Okay, just a little pin-prick...There'll be no more-* *lancelot@spock.UUCP * Aieeeeaaaugh!-but you may feel a little _sick_. * *uunet!hsi!yale!lancelot* ---Pink Floyd * *******************************************************************************
jonb@vector.Dallas.TX.US (Jon Buller) (01/29/91)
In article <1991Jan25.214706.185@spock.UUCP> lancelot@spock.UUCP (Thor Lancelot Simon) writes: >If you're sending megabytes of data, I would assume you're compressing it. >But MNP is not really 4800 bps. It is 2400bps with a data compression >scheme which will get, *at best* 4800bps throughput. If you're sending data >that is already compressed, throughput should drop to BELOW 2400 bps. The only >reason it wouldn't is that MNP makes slight improvements on 2400 bps using a >link scheme that eliminates stop bits. If you stop compressing your data on >the sending host, throughput will rise, but the files will be proportionately >larger, and your compression at the sending site is probably superior to the >modem's. To me, MNP modems have always been a fairly obvious waste of money >if used for file transfer - I can do far better compression before I send the >data, and only have to buy a 2400 bps modem. MNP class 4 does no compression, class 5 and class 7 do roughly 2 to 1 and 2.5-3 to 1 compression respectively. This is all independent of the transmission speed. Some Telebit modems (T2500?) can do MNP5 at 9600bps or do v42bis which is a superset of MNP with (your favorite and mine) LZW compression, very similar to what the 'compress' program does. So if you buy a 4800bps MNP4 modem, you will get (almost) 4800bps. A bit will be lost to packet overhead (about 10 bytes/packet in fact, but I don't have my docs & code at the moment... If you buy a 4800bps MNP5 modem you can get between 4800bps and 9600bps depending on your data. Don't tell the guy he doesn't know what he's saying UNLESS YOU ARE ABSOLUTELY SURE about it. Of course he may have a 2400bps MNP5 modem, in which case your statements would be correct. -- Jon Buller jonb@vector.dallas.tx.us ..!texsun!vector!jonb FROM Fortune IMPORT Quote; FROM Lawyers IMPORT Disclaimer;
lancelot@spock.UUCP (Thor Lancelot Simon) (01/31/91)
In article <1154@vector.Dallas.TX.US> jonb@vector.Dallas.TX.US (Jon Buller) writes: >In article <1991Jan25.214706.185@spock.UUCP> lancelot@spock.UUCP (Thor Lancelot Simon) writes: > >>If you're sending megabytes of data, I would assume you're compressing it. >>But MNP is not really 4800 bps. It is 2400bps with a data compression >>scheme which will get, *at best* 4800bps throughput. If you're sending data >MNP class 4 does no compression, class 5 and class 7 do roughly 2 to 1 >and 2.5-3 to 1 compression respectively. This is all independent of the >transmission speed. Some Telebit modems (T2500?) can do MNP5 at 9600bps >or do v42bis which is a superset of MNP with (your favorite and mine) LZW >compression, very similar to what the 'compress' program does. > >So if you buy a 4800bps MNP4 modem, you will get (almost) 4800bps. A bit >will be lost to packet overhead (about 10 bytes/packet in fact, but I >don't have my docs & code at the moment... If you buy a 4800bps MNP5 >modem you can get between 4800bps and 9600bps depending on your data. I've never seen a real 4800bps modem. I suppose one would use the V32 modulation but at 4800 rather than 9600bps? Is this really much cheaper? In any case, all the "4800bps MNP" modems I've seen always turned out to be 2400bps with MNP 5. You're right, I have no way of knowing that the modem in question isn't 4800bps and MNP4, or that compression is indeed being done at the transmitting end before data is sent. I also was under the impression that because start and stop bits are not needed during a MNP 4 transmission, throughput actually increases because there are more stop bits lost than packet overhead gained. Is that wrong? Anyway, I'm directing this to comp.dcom.modems as it's rather off the subject of mail or UUCP by now. >-- >Jon Buller jonb@vector.dallas.tx.us ..!texsun!vector!jonb >FROM Fortune IMPORT Quote; FROM Lawyers IMPORT Disclaimer; ******************************************************************************* *Thor Simon * Okay, just a little pin-prick...There'll be no more-* *lancelot@spock.UUCP * Aieeeeaaaugh!-but you may feel a little _sick_. * *uunet!hsi!yale!lancelot* ---Pink Floyd * *******************************************************************************