dias@eecs.ucdavis.edu (Gihan Dias) (02/02/91)
I have a general question on MNP, and a specific problem. In article <3760.27a77a47@hayes.uucp> tnixon@hayes.uucp writes: > MNP4 has a fixed maximum frame size of 256 bytes, but LAPM can > negotiate frame sizes from 16 all the way up to 4096 bytes. Does this mean that for an MNP4 modem, if the DTE sends <256 bytes and stops, the modem will time out and send a short frame, but if the DTE sends >256 bytes, the modem will send a 256 byte frame? When using a protocol like kermit on top of MNP4, what is the best packet size to use? Would just under 256 bytes be better or worse than just over 256? Now for my problem. I was trying to use two Everex 24+ modems connected at 1200 b/s in MNP4 mode for a kermit file transfer. I was running the modem-computer interface at 1200 baud with no flow control. As I assumed the modems will give me a clear channel, I assumed I would get best performance by using a large a kermit packet size as possible which would not overflow the modems' buffers. I tried a packet size of 512 bytes, (with a window size of 1) but it didn't work, the packets wern't getting through. With a 250 byte packet size, I managed to transfer data, but with lots of packet retries. Things were better when I reduced the packet size to 100. This seems to imply that the 24+ has an input buffer of <256 bytes when MNP4 is enabled. My question is, is this a known problem with the Everex 24+? (Everex technical support were friendly, but couldn't help). Or am I doing something wrong? Does anybody know what size buffer this modem has when MNP4 is enabled? (I did some tests and it seems to have about a 1k buffer when MNP is not enabled). Any help or suggestions would be appreciated. Gihan
tnixon@hayes.uucp (02/03/91)
In article <8294@ucdavis.ucdavis.edu>, dias@eecs.ucdavis.edu (Gihan Dias) writes: > In article <3760.27a77a47@hayes.uucp> tnixon@hayes.uucp writes: >> MNP4 has a fixed maximum frame size of 256 bytes, but LAPM can >> negotiate frame sizes from 16 all the way up to 4096 bytes. > > Does this mean that for an MNP4 modem, if the DTE sends <256 bytes and > stops, the modem will time out and send a short frame, but if the DTE > sends >256 bytes, the modem will send a 256 byte frame? You have it basically correct. It's difficult to predict how a particular error-control implementation will actually divide its frames, however. Hayes modems, for example, start off sending shorter frames, then gradually increase the frame size to the maximum if the DTE continues sending data. This significantly reduces the propagation delay associated with using protocols such as XMODEM and Kermit over and error-control modem link, since the entire protocol frame need not be received before it can begin to be delivered to the remote DCE -- while at the same time not impacting total overall throughput during long transmissions. I don't know whether any other manufacturer uses similar techniques. > When using a protocol like kermit on top of MNP4, what is the best > packet size to use? Would just under 256 bytes be better or worse than > just over 256? It is best to use the maximum frame size possible whenever using file transfer protocol on an error-control modem link. Since the modems take care of recovering from errors, you want to minimize the number of times the sender has to stop and wait for an acknowledgement from the receiver. Don't be concerned with the frame size being used in the modems -- you're not paying by the packet, after all. > I was trying to use two Everex 24+ modems connected at 1200 b/s in MNP4 mode for a kermit file transfer. I was running the modem-computer interface at 1200 > baud with no flow control. As I assumed the modems will give me a clear It is very bad to use any error-control modem without flow control! All it takes is a bit of line noise, and WHAMMO, you've lost data. An error control modem is pretty dang useless if you lose data anyway. > ... > This seems to imply that the 24+ has an input buffer of <256 bytes > when MNP4 is enabled. I don't know what size buffer they use, but it could be small. Error control modems provide flow control FOR A REASON, and you should use it. Hayes modems have 256-byte buffers in error-control mode. There are some modems that have much larger buffers, such as Microcom (I think). -- Toby Nixon, Principal Engineer | Voice +1-404-449-8791 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
root@zswamp.fidonet.org (Geoffrey Welsh) (02/06/91)
>From: tnixon@hayes.uucp >Hayes modems have 256-byte buffers in error-control mode. >There are some modems that have much larger buffers, such as >Microcom (I think). When I spoke to the technocritters at Telebit, they revealed that their PEP buffers are 1.75K. USR specs say that their HST's buffers are 1.5K, though bit 8 (I think) of S15 cuts that to 128 bytes if the modem connection is without error correction (you're stuck with large buffers if you're talking to another HST, or an MNP or V.42 modem). -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 The mile is traversed not by a single leap, but by a procession of coherent steps; those who insist on making the trip in a single element will be failing long after you and I have discovered new worlds. - me
ch@dce.ie (Charles Bryant) (02/07/91)
In article <3762.27aaeb7e@hayes.uucp> tnixon@hayes.uucp writes: [In error correctin protocols...] >... Hayes modems, for example, start off sending >shorter frames, then gradually increase the frame size to the >maximum if the DTE continues sending data. This significantly >reduces the propagation delay associated with using protocols such >as XMODEM and Kermit over and error-control modem link, since the >entire protocol frame need not be received before it can begin to be >delivered to the remote DCE -- while at the same time not impacting >total overall throughput during long transmissions. With MNP4 this is not the case. The optimal distribution of packet sizes is to start with big packets and finish with smaller ones. For example with a standard setup (MNP4, tty->modem at 19200, modem<->modem at 9600) the optimal distribution for sending 64 bytes is 45, 17, 2. The actual sizes should vary according to the amount of fixed packet overhead (e.g. MNP4 in use or not) and the amount of overhead that varies linearly with the number of bytes in a packet (e.g. MNP2 = 10, MNP3 = 8). If the terminal speed is less than the line speed, the packets might as well send all pending data since there won't be much. -- Charles Bryant (ch@dce.ie) -- /usr/ch/.signature: Block device required
larry@nstar.rn.com (Larry Snyder) (02/08/91)
root@zswamp.fidonet.org (Geoffrey Welsh) writes: > When I spoke to the technocritters at Telebit, they revealed that their PEP >buffers are 1.75K. USR specs say that their HST's buffers are 1.5K, though bit >8 (I think) of S15 cuts that to 128 bytes if the modem connection is without >error correction (you're stuck with large buffers if you're talking to another >HST, or an MNP or V.42 modem). the buffers are great for file transfers - but for interactive use with on-line hot keys - they can create problems. I wish there was a way on the fly to enable and disable the buffers from within the BBS hostware - without leaving the system open for users to play with the modem configurations (maybe there is such a way?) -- Larry Snyder, NSTAR Public Access Unix 219-289-0287 (HST/PEP/V.32/v.42bis) regional UUCP mapping coordinator {larry@nstar.rn.com, ..!uunet!nstar!larry, larry%nstar@iuvax.cs.indiana.edu}
root@zswamp.fidonet.org (Geoffrey Welsh) (02/11/91)
In a letter to All, Larry Snyder (larry@nstar.rn.com ) wrote: >the buffers are great for file transfers - but for >interactive use >with on-line hot keys - they can create problems. I wish >there was >a way on the fly to enable and disable the buffers from >within the BBS >hostware - without leaving the system open for users to play >with the modem configurations (maybe there is such a way?) Not that I know of. Certainly it helps to be able to cut the HST's buffers back to 128 bytes when not in MNP mode, as that cuts the hotkey response delay for 2400 and 1200 baud callers to less than a second; hopefully the data will move quickly enough at 9600 that the dumping of the buffer won't take long. Perhaps we can start a new trend in software: leave the modems set to clear the transmit buffer on reception of a BREAK signal (and, if possible, NOT to pass the BREAK on) and have the software send a BREAK as soon as it receives a hotkey response to a menu? That way, no matter what the buffer size there shouldn't be more than half a second delay in responding to user input. The Telebits aren't particularly well suited for this, what with their half duplex lines, etc... I remember Toby saying something about full-duplex PEP via echo cancellation promised but not forthcoming; the folks at Telebit might be better served trying to divide the existing scad of carriers between the two directions, dividing them 1:1, 3:1, 7:1, etc. as the volume of traffic in each direction warrants. (i.e., divide the number of carriers to accomplish full duplex, not time division on unidirectional broadcast). Thoughts? Geoff -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 The mile is traversed not by a single leap, but by a procession of coherent steps; those who insist on making the trip in a single element will be failing long after you and I have discovered new worlds. - me
tnixon@hayes.uucp (02/12/91)
In article <6779.27B72B77@zswamp.fidonet.org>, root@zswamp.fidonet.org (Geoffrey Welsh) writes: > In a letter to All, Larry Snyder (larry@nstar.rn.com ) wrote: > > >the buffers are great for file transfers - but for > >interactive use > >with on-line hot keys - they can create problems. I wish > >there was > >a way on the fly to enable and disable the buffers from > >within the BBS > >hostware - without leaving the system open for users to play > >with the modem configurations (maybe there is such a way?) > > Not that I know of. Certainly it helps to be able to cut the HST's buffers > back to 128 bytes when not in MNP mode, as that cuts the hotkey response delay > for 2400 and 1200 baud callers to less than a second; hopefully the data will > move quickly enough at 9600 that the dumping of the buffer won't take long. I'm confused as to what the issue is here. The size of a modem's TRANSMIT buffer has NOTHING to do with propagation of function key transmissions, etc., any more than it has to do with forwarding of single keystrokes in echoplex environments. All modem manufacturers optimize their implementations to handle interactive traffic as expeditiously as possible, since the typical user's tolerance for echo delay is very low (around 100 msec). All modems I'm aware of DO NOT use a "timeout" or wait for some minimum number of characters to be available, but use what is called "stream-mode packet forwarding". As soon as even ONE character is available for transmission, the modem begins transmitting a frame to contain that character; since the header is at least four octets long, it is possible that additional characters come from the DTE during this process. If so, these are added to the same frame. So long as additional characters come from the DTE, they will continue to be added to the same frame, until the maximum frame size is reached or the modem runs out of data and must close the frame. So, as I said, I don't understand the concern about buffer size. Large buffers do NOT increase propagation delay of small bursts of data. Their primary negative impact is when you attempt to _cancel_ a _long_ transmission. -- Toby -- Toby Nixon, Principal Engineer | Voice +1-404-449-8791 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
root@zswamp.fidonet.org (Geoffrey Welsh) (02/17/91)
>So, as I said, I don't understand the concern about buffer size. >Large buffers do NOT increase propagation delay of small bursts of >data. Their primary negative impact is when you attempt to >_cancel_ a _long_ transmission. That is precisely the issue at hand: what we're talking about is the flushing of the menu when the user hits a key. Worst case scenario: computer-modem interface locked at 19,200 (or 38,400); menu is a full screen long (2K), and the modem can hold that much in a buffer. A user calls at 1200 bps. The menu is sent to the modem (for all intents instantly). The user, familiar with the system, hits a key as soon as he sees the menu start. However, the computer has already sent the menu out and is now proceding to act on the user's command... while the user watches 2K of menu stream out at 120 CPS, resulting in an annoying delay. That's why we like to keep buffers down on public access systems. Geoff -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 The mile is traversed not by a single leap, but by a procession of coherent steps; those who insist on making the trip in a single element will be failing long after you and I have discovered new worlds. - me
tnixon@hayes.uucp (02/18/91)
In article <6819.27BE119B@zswamp.fidonet.org>, root@zswamp.fidonet.org (Geoffrey Welsh) writes: > Worst case scenario: computer-modem interface locked at 19,200 (or > 38,400); menu is a full screen long (2K), and the modem can hold that much in > a buffer. A user calls at 1200 bps. The menu is sent to the modem (for all > intents instantly). The user, familiar with the system, hits a key as soon > as he sees the menu start. However, the computer has already sent the menu > out and is now proceding to act on the user's command... while the user > watches 2K of menu stream out at 120 CPS, resulting in an annoying delay. Ahh! Now I understand! Since I never use a BBS with a low speed modem (heck, I get Ultra 96's for free, why should I? :-) it never struck me that this cancellation of a display would be a frequent occurrence. I generally think of ^C'ing something coming from a Vax, rather than interrupting a menu display. Now that you've explained it, it makes perfectly good sense -- and now I understand why it is such a concern! Yes, it _would_ be very frustrating, if you _knew_ that the menu display was _supposed_ to be interrupted when you pressed a key, but it didn't. Alas, there's nothing I can do about other people's modems but advise users to contact the manufacturers are suggest an S-register to control the flow-off threshold. I guess this is one more argument in favor of using Hayes modems, since we've kept the buffers small (256 bytes, with 192-byte high water mark) all along. -- Toby Nixon, Principal Engineer | Voice +1-404-449-8791 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
RAF@CU.NIH.GOV ("Roger Fajman") (02/19/91)
> Alas, there's nothing I can do about other people's modems but > advise users to contact the manufacturers are suggest an S-register > to control the flow-off threshold. I guess this is one more > argument in favor of using Hayes modems, since we've kept the > buffers small (256 bytes, with 192-byte high water mark) all along. The USR Courier 9600 bps modems have an S-register setting for this. Setting S15=8 reduces the buffer to 128 bytes (instead of 1.5K) for non-ARQ mode. The stated reason for the large buffer is the ability to do XMODEM and YMODEM file transfers without flow control (presumably with the RS-232 interface locked at high speed on a low speed call). Why one would lock the interface at high speed without flow control is not so clear to me. I suppose that one might want to do it on a machine that does not support hardware flow control, but then it seems like a larger buffer might be desirable. Perhaps 1.5K is big enough to hold most screenfuls of text encountered in practice. Roger Fajman Telephone: +1 301 402 1246 National Institutes of Health BITNET: RAF@NIHCU Bethesda, Maryland, USA Internet: RAF@CU.NIH.GOV
root@zswamp.fidonet.org (Geoffrey Welsh) (02/19/91)
>From: tnixon@hayes.uucp >Ahh! Now I understand! >I guess this is one more argument in favor of using Hayes modems, >since we've kept the buffers small (256 bytes, with 192-byte high >water mark) all along. I'd never argue against using Hayes modems on technical grounds (hey, my system uses a Smartmodem 2400!), but HST users can just set a bit in S15 (bit value 8, I believe) to cut buffers to 128 bytes... but only for non-MNP callers. <sigh> BTW, I would have thought that 256 bytes was not enough to allow decent MNP5 and V.42bis data compression. Am I really misunderstanding the process by a large margin? -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 The mile is traversed not by a single leap, but by a procession of coherent steps; those who insist on making the trip in a single element will be failing long after you and I have discovered new worlds. - me
tnixon@hayes.uucp (02/22/91)
In article <6831.27C20BB1@zswamp.fidonet.org>, root@zswamp.fidonet.org (Geoffrey Welsh) writes: > BTW, I would have thought that 256 bytes was not enough to allow decent > MNP5 and V.42bis data compression. Am I really misunderstanding the process > by a large margin? Yes, you are. The size of the DTE buffer has nothing to do with the amount of memory available for V.42bis dictionaries. Most modems provide room for at least 1,024 nodes [roughly 16K RAM], and many (including Ultra 96) provide for 2,048 nodes [roughly 32K RAM]. The minimum allowed by the standard is 512 nodes. There is very little performance improvement, and risk of performance DECREASE, from using more than 2K nodes in V.42bis. The amount of memory required by MNP5 is fixed, about 1.5K RAM. None of these figures have anything to do with the size of the circular buffer used for transferring data to/from the PC. -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net