Geoffrey.Welsh@p0.f171.n221.z1.fidonet.org (Geoffrey Welsh) (09/19/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. I think I ought to explain MNP a bit here, as the above isn't quite accurate. I'm familiar with MNP up to level 5, so the following may not reflect reality in some of the higher versions. Basic MNP covers levels 1 through 3; 1 implements an error- correcting protocol much like XMODEM or KERMIT; 2 is referred to as "full-duplex" and uses a "sliding windows" technique; 3 removes start & stop bits to make up for lost performance due to protocol overhead. In order for modems from USR, Telebit, or ATI to operate with MNP, *one* of these base levels must be selected. MNP4 is an optional add-on feature; once modems have agreed to use any one of MNP1 thorugh MNP3, they may also agree to use MNP4, which increases the block size used. This may be part of your problem; perhaps you should call the manufacturer to see if MNP4 can be selectively disabled. There will be a pause/delay caused by MNP no matter how large or small the packet is, however. MNP5 is also an optional add-on. It can be added as long as one of levels 1-3 have been negotiated, regardless of whether MNP4 has been added. I strongly advise DISABLING MNP5 when transferring compressed data because, unlike the upcoming V.42bis standard, MNP5 will not compare the 'compressed' data to the original and send the smaller of the two (compressing compressed data sometimes expands it, and this is the case when .Z files are compressed with MNP5). Please also keep in mind that a Telebit can get 1400 CPS because it does not have a fixed carrier speed and can, on ideal lines, hit 18000 bits per second. V.32 uses a 9600 bit/second carrier and, even with the speed boosts offered by MNP3, will probably not exceed 1100 CPS on compressed files using ZMODEM (1160 with the MNP4 option enabled). >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? Just about every modem manufacturer claims incredible boosts with their compression algorithms, and there's a trick to how they do it: they test using spreadsheet files under protocols like ZMODEM. The files are mostly spaces and compress incredibly well, while ZMODEM squeezes every drop of performance out of a 9600 bps modem. No one in the real world gets performance like the ads claim, and much of that is because real users tend to compress their data first! >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? In the Fido world there are too few people who realize this and many 9600+ bps modems don't give error-free transfers for precisely that reason. However, I have found that I could always configure the software and modem to correct this. I do not have enough experience with Unix to tell you how to do so with your system, but I will reveal that the best results always came from using RTS/CTS hardware handshaking and not letting any characters (e.g. XON/XOFF, ENQ/ACK) get into the data stream. I'm afraid you'll have to deicde for yourself (1) how to get your OS to open a serial port using RTS/CTS but not XON/XOFF and (2) whether, under heavy load, it is capable of reacting fast enough with its RTS level (if not, you may have to cu down the port speed to guarantee error-free transfers; this may still INCREASE throughput, though...) If you're using an 8250-style UART (including NS16450), you might consider getting the NS16550A, which includes on-chip 16- byte FIFOs... but you'll have to patch your drivers to enable them... -- Geoffrey Welsh - via FidoNet node 1:221/171 UUCP: {{uunet!}watmath!xenitec!}zswamp!171.0!Geoffrey.Welsh ARPA: Geoffrey.Welsh@p0.f171.n221.z1.fidonet.org