shannon%datsun@Sun.COM (Bill Shannon) (09/07/89)
I've been evaluating V.32 modems and have run into a problem with MNP 5
operation. Talking to the modem at 19200, with the modem doing MNP 5
(error correction and compression), and using uucp with the 'g' protocol,
I expected to get 1200 - 1500 characters per second throughput. However,
what I'm actually getting is something like 450 cps. It turns out that
the problem is related to a clash between the uucp 'g' protocol and the
MNP protocol. uucp is sending 64 bytes packets and expecting a response.
MNP 5 sends 128 byte packets. If less than 128 bytes come in to the
modem, it waits a bit and then decides no more is coming and sends a
partial packet. Unfortunately, this wait is on the order of 20 milliseconds
and is killing uucp 'g' protocol performance.
Have any of you people using MNP 5 (or higher) run into the same problem?
In particular, I've seen some claims of fantastic throughput using the
Microcom modem at 38400 baud with MNP 9. Are people using uucp's 'g'
protocol in this configuration? Does MNP 9 not have this problem?
You might think that, since the modem is providing error correction, you
could use one of the uucp error-free protocols ('t' or 'e'). In fact,
using one of those protocols does give the expected throughput. However,
the modems only guarantee that the data makes it from one modem to the
other without errors; there is no guarantee that the data will make it into
the host without errors. While I'm not really worried about "line noise"
corrupting the data between the modem and the host, I am worried that the
host can drop data coming from the modem, for instance the familiar "silo
overflow" problem if the host gets too busy. As far as I can tell, the
uucp error-free protocols won't detect this condition, thus possibly
resulting in corrupted files being transferred. Has anyone else considered
this problem and perhaps dealt with it?
Thanks for any help.
Bill Shannonmacy@fmsystm.UUCP (Macy Hallock) (09/07/89)
In article <124236@sun.Eng.Sun.COM> shannon%datsun@Sun.COM (Bill Shannon) writes: > [description of MNP 5 incompatiblilty with uucp g protocol deleted] > >Have any of you people using MNP 5 (or higher) run into the same problem? Yes, I have run into this. You description is basically correct. >In particular, I've seen some claims of fantastic throughput using the >Microcom modem at 38400 baud with MNP 9. Are people using uucp's 'g' >protocol in this configuration? Does MNP 9 not have this problem? We are testing some error correcting V.32 modems at this time. It would appear that uucp g usually works on them, but there is still some delay added over using t or e protocol. >You might think that, since the modem is providing error correction, you >could use one of the uucp error-free protocols ('t' or 'e'). In fact, >using one of those protocols does give the expected throughput. However, >the modems only guarantee that the data makes it from one modem to the >other without errors; there is no guarantee that the data will make it into >the host without errors. While I'm not really worried about "line noise" >corrupting the data between the modem and the host, I am worried that the >host can drop data coming from the modem, for instance the familiar "silo >overflow" problem if the host gets too busy. As far as I can tell, the >uucp error-free protocols won't detect this condition, thus possibly >resulting in corrupted files being transferred. Has anyone else considered >this problem and perhaps dealt with it? You're right again. And I have found several versions of uucico that do not support t or e protocols (SCO comes to mind, for one). Unless carefully considered, the use of two error detection schemes on a datacom link degrades performance. Use of the Microcom V.32 with MNP 5 for SLIP seems to work well. Regards, Macy Hallock fmsystm!macy@NCoast.ORG F M Systems, Inc. hal!ncoast!fmsystm!macy 150 Highland Dr. uunet!hal.cwru.edu!ncoast!fmsystm!macy Medina, OH 44256 Voice: 216-723-3000 X251 Disclaimer: My advice is worth what you paid for it. Alt.disclaimer: Your milage may vary. Biz.disclaimer: My opinions are my own. What do I know?
mason@tmsoft.uucp (Dave Mason) (09/08/89)
In article <124236@sun.Eng.Sun.COM> shannon%datsun@Sun.COM (Bill Shannon) writes: >I've been evaluating V.32 modems and have run into a problem with MNP 5 >operation. Talking to the modem at 19200, with the modem doing MNP 5 >(error correction and compression), and using uucp with the 'g' protocol, >I expected to get 1200 - 1500 characters per second throughput. However, >what I'm actually getting is something like 450 cps. I've just started using a Microcom AX/96xxc. Sending compressed news batches we're getting about 600 cps. Using 9600 or 19200 is irrelevant. > It turns out that >the problem is related to a clash between the uucp 'g' protocol and the >MNP protocol. uucp is sending 64 bytes packets and expecting a response. >MNP 5 sends 128 byte packets. If less than 128 bytes come in to the >modem, it waits a bit and then decides no more is coming and sends a >partial packet. Unfortunately, this wait is on the order of 20 milliseconds >and is killing uucp 'g' protocol performance. The only thing that I've found that may help a little is setting the block size to 64 characters instead of the default 256 (the AT \A0 command). It doesn't make a huge difference, but it does (from my preliminary tests) help about 20% (I'm going to run 'week-on and week-off' tests to be sure). I tried 128 and 192 to no real advantage (over 256). What we really need is to be able to tell it 'if you don't see any characters for 1ms, ship off what you've got'. >Have any of you people using MNP 5 (or higher) run into the same problem? >In particular, I've seen some claims of fantastic throughput using the >Microcom modem at 38400 baud with MNP 9. Are people using uucp's 'g' >protocol in this configuration? Does MNP 9 not have this problem? This (600 cps) seems sort-of right: 1) the data compression of course won't help, and may hurt. I haven't tried turning it off yet to see what happens. These marvelous quoted speeds of >960cps of course assume that the data can be compressed. 2) on a telebit I usually see 1000-1100 cps which is on the order of 2/3 of the 'raw data rate' of 14400bps (max). 3) given that the MNP-5 is really only running at 9600, 600cps is on the order of 2/3 of the 'raw data rate' On the telebit, turning compression off appeared to gain me about 5% (again, shipping compressed -b 16 news batches). So after I've been using this long enough to get some useful stats, I'll try that. >You might think that, since the modem is providing error correction, you >could use one of the uucp error-free protocols ('t' or 'e'). In fact, >using one of those protocols does give the expected throughput. However, >the modems only guarantee that the data makes it from one modem to the >other without errors; there is no guarantee that the data will make it into >the host without errors. some of {f,t,e} protocols do error checking, but only on a 'whole-file' basis & reship the whole file if something went wrong. This is probably unlikely enough between the computer and the modem that file level checking is probably sufficient (if your silo overflows are frequent, I'd claim you had more problems than modem throughput). I don't know if anyone has tried running a telebit using these protocols instead of 'g'. It would be interesting to hear the results. The bottom line? From here, today, it's "get a Telebit" for 60-70% better throughput. But I'm using this Microcom because the person at the other end of the phone line found the Telebits to be a crock, so I guess it just goes to show you... ../Dave
ted@gouldnl.nl (Ted Lindgreen) (09/08/89)
>some of {f,t,e} protocols ..... ... >throughput). I don't know if anyone has tried running a telebit using >these protocols instead of 'g'. It would be interesting to hear the >results. > Yes, I have done some testing of the f and t protocols. It turns out that the throughput in terms of baudrate (how you use the line) is not very different. There is a difference in total throughput in terms of <number of bytes of the transfer>/<total connect time>. The 'f' protocol is a real lozer on compressed files, because the f-protocol only uses the characters between space and tilde in order to cope with those nasty PADs. All other data is turned into a double character. It means that a compressed transfer increases with some 75%. Switching on compression in the modem compensates somewhat, but the net result is still 25% to 40% less total throughput compared to the 'g' and 't' proto which use the full 8 bits of each byte. The t-protocol gave a minor improvement (5%) compared with 'g'. The f-protocol performs a sum check on the whole transfer, but I don't think that the t-protocol does that. For both f and t proto flow control is essential. For the f-protocol one can use X-on/X-off on most machines, on a few machines one can use hardware flow control as well. For the t-protocol one must use hardware flow control. With the g-protocol my advice is to switch off compression in the modem for compressed news batches, the difference is some 10% to 15%. My conclusion was: With the g-proto spoofing of the trailblazer one gets a nearly optimal througput with the easiest setup procedure for the g-protocol. The f-protocol is bad for non-ascii data. The t-protocol does not garanty the correctness of the transfer. -- | Ted Lindgreen ...!mcvax!hp4nl!gouldnl!ted | | Encore Unix Centre Europe ted@gouldnl.uucp | | Maarssenbroek, The Netherlands (USA) ...!gould!tlindgreen |
andy@acorn.co.uk (Andy Ingle) (09/08/89)
In article <1989Sep7.235838.11756@tmsoft.uucp> mason@tmsoft.UUCP (Dave Mason) writes: >some of {f,t,e} protocols do error checking, but only on a >'whole-file' basis & reship the whole file if something went wrong. >This is probably unlikely enough between the computer and the modem >that file level checking is probably sufficient (if your silo >overflows are frequent, I'd claim you had more problems than modem >throughput). I don't know if anyone has tried running a telebit using >these protocols instead of 'g'. It would be interesting to hear the >results. The 'f' protocol uses a checksum at the end of each file transfer. If it is wrong the file is sent again, if is wrong the second time uucico closes the call. A couple of years ago I bought a UK version of the Telebit Trailblazer to use on a uucp link between Cambridge, UK and Palo Alto, California. It didn't have the uucp protocol spoofing or compression but because it was self error-correcting I used the 'f' protocol. This worked quite well and was much faster than 'g', but I later obtained a ROM upgrade and found that using the 'g' protocol, with spoofing *and compression*, was faster still. --Andy Ingle
shannon%datsun@Sun.COM (Bill Shannon) (09/11/89)
In article <38@fmsystm.UUCP>, macy@fmsystm.UUCP (Macy Hallock) writes: > In article <124236@sun.Eng.Sun.COM> shannon%datsun@Sun.COM (Bill Shannon) writes: > >In particular, I've seen some claims of fantastic throughput using the > >Microcom modem at 38400 baud with MNP 9. Are people using uucp's 'g' > >protocol in this configuration? Does MNP 9 not have this problem? > > We are testing some error correcting V.32 modems at this time. > It would appear that uucp g usually works on them, but there is > still some delay added over using t or e protocol. "some"? for me, it's *a lot*. I get about 830 cps at 9600 baud using MNP 4 and about 450 cps at 19200 baud using MNP 5.
shannon%datsun@Sun.COM (Bill Shannon) (09/11/89)
In article <1989Sep7.235838.11756@tmsoft.uucp>, mason@tmsoft.uucp (Dave Mason) writes: > some of {f,t,e} protocols do error checking, but only on a > 'whole-file' basis & reship the whole file if something went wrong. 't' and 'e' don't do any error checking at all. > This is probably unlikely enough between the computer and the modem > that file level checking is probably sufficient (if your silo > overflows are frequent, I'd claim you had more problems than modem > throughput). oh, no doubt! but just because I have these other problems I don't want my files corrupted! it's not throughput in the face of errors I'm worried about, it's throughput in the normal case, while still being able to detect and recover from errors. Here's the problem. Both 't' and 'e' send a "byte count" before sending data, 't' before each block and 'e' before the whole file. if one byte of this byte count is dropped, the following bytes that are really part of the file will look like part of the byte count. similarly, in the case of 't', if bytes of the file are dropped the following byte count could be "sucked into" the file. this could easily cause uucp to read more or less data than is actually in the file. as far as I can tell, if this happens, this can go undetected and the file will be assumed to have been transferred successfully, but an error will likely occur *after* the file transfer has completed. > The bottom line? From here, today, it's "get a Telebit" for 60-70% > better throughput. But I'm using this Microcom because the person at > the other end of the phone line found the Telebits to be a crock, so I > guess it just goes to show you... Telebits are great, but they're expensive and likely to remain so. V.32 modems are cheap, and are getting cheaper all the time. Also, V.32 modems work much better for interactive use, and for SLIP. Telebits excel *only* for uucp transfers (ignoring the T2500 that also does V.32; it's far too expensive). maybe the answer is to build a uucp protocol that does error checking *and* compression and ignore MNP? is MNP just another case of a "smart" device doing a dumb thing? Bill