cgwst@unix.cis.pitt.edu (Gray Watson) (11/08/90)
Howdy Netlanders: Here the situation. I have 4 Computer Peripherals 2400/MNP5 modems for dial-in purposes (plug: modems have been working like champs, I could not be happier). I initally did not have the MNP5 features enabled since I was never connecting that way, but I finally decided to set it up. When I finally tried a MNP5 to MNP5 connection I was disappointed at the little to no speed increase. It took me a couple of minutes to realize that if my Sparc -> modem serial connection was 2400 baud, there was nothing a MNP5 modem connection could do to overcome this restriction. All I had to do is up my Sparc -> modem serial speed to 9600 and voila: close to double speeds with the MNP5. Very nice!! Now the problem: users logging into my system at *normal* 2400 baud (1200 and 300 also) have their environment set to 9600 baud. The modem handles the speed mismatch so there is not a problem there, but anything that uses a termcap-like database (gnu-emacs for example) thinks you are on a 9600 baud line and sends 4 times the number of padding NULLs. I have tried to set my modems to auto-baud on the Sparc serial connection in parallel with the modem connection but I am finding that MNP5 connections get set to 2400 baud. Back where I started with no speed increase. Am I missing something? Do I have any bad assumptions/information here? thanks for any help, gray
s872007@otto.bf.rmit.oz.au (David Burren [Athos]) (11/08/90)
In <58217@unix.cis.pitt.edu> cgwst@unix.cis.pitt.edu (Gray Watson) writes: >Now the problem: users logging into my system at *normal* 2400 baud (1200 and >300 also) have their environment set to 9600 baud. The modem handles the >speed mismatch so there is not a problem there, but anything that uses >a termcap-like database (gnu-emacs for example) thinks you are on a 9600 baud >line and sends 4 times the number of padding NULLs. >I have tried to set my modems to auto-baud on the Sparc serial connection >in parallel with the modem connection but I am finding that MNP5 connections >get set to 2400 baud. Back where I started with no speed increase. >Am I missing something? Do I have any bad assumptions/information here? I've found the same thing. However, talking to the modem at a fixed 4800 bps instead of 9600 bps reduces the problem. It would be nice if the modem would tell the host "CONNECT 4800" if it gets an MNP connection, and "CONNECT 2400" if it got one at 1200 baud, but so far I haven't seen one that would, so I live with the problem. I've mentioned it to the manufacturers, but as yet it's just on the wish list. FYI, the MNP modems I use are Netcomm M4/M5s and Maestro 2400/DataOptimizers. Both Netcomm and Maestro are Australian manufacturers. _______________________________________________________________________ David Burren (Wookie Athos) Work: david@bacchus.esa.oz.au Software Development Engineer Home: athos%eyrie@labtam.oz.au Expert Solutions Australia School: s872007@otto.rmit.oz.au
root@zswamp.fidonet.org (Geoffrey Welsh) (11/08/90)
Gray Watson (cgwst@unix.cis.pitt.edu ) wrote: >Now the problem: users logging into my system at *normal* >2400 baud (1200 and >300 also) have their environment set to 9600 baud. The >modem handles the >speed mismatch so there is not a problem there, but anything >that uses >a termcap-like database (gnu-emacs for example) thinks you >are on a 9600 baud >line and sends 4 times the number of padding NULLs. FidoNet type folk have solved this problem rather neatly: the serial drivers we use support a 'locked' mode; that is, the driver will always communicate with the modem at a fixed speed (9600, 19200, 38400, whatever) regardless of what the application sets the speed to. In this way, a modem may report "CONNECT 2400/ARQ" (example: USRobotics Courier models w/MNP) and all software down the line knows that the connect is over a physical 2400 bps carrier, but the driver will continue to talk to the modem at the higher fixed rate. In this way, efficiencies of over 100% are sometimes reported... we *love* to see such reports. <grin> This, of course, would require an extensive patch to the serial drivers... they'd have to remember what baud rate they're logically operating at so that they can report it when queried, but the actual communication speed must be set separately and not be overridden by standard calls... >I have tried to set my modems to auto-baud on the Sparc >serial connection >in parallel with the modem connection but I am finding that >MNP5 connections >get set to 2400 baud. Back where I started with no speed >increase. Some modems (e.g. "ATI 2400etc" models) have a three-line connect report: CARRIER 2400 PROTOCOL: MNP CONNECT 9600 This, however, leaves you with your original problem. The partial benefit is that, for non-MNP callers, the CONNECT string reports 2400, not 9600. -- 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 MC Hammer, n. Device used to ensure firm seating of MicroChannel boards Try our new Bud 'C' compiler... it specializes in 'case' statements!
tnixon@hayes.uucp (Toby Nixon) (11/09/90)
In article <s872007.658066970@otto>, s872007@otto.bf.rmit.oz.au (David Burren [Athos]) writes: > It would be nice if the modem would tell the host "CONNECT 4800" if it gets > an MNP connection, and "CONNECT 2400" if it got one at 1200 baud, but so far > I haven't seen one that would, so I live with the problem. > I've mentioned it to the manufacturers, but as yet it's just on the wish list. Hayes has several features in their modems that may meet your needs. If you use the "W1" setting, instead of just the CONNECT result code, you get three lines: CARRIER <speed> PROTOCOL: <type> CONNECT <speed> where CARRIER gives you the actual data rate on the phone line, CONNECT gives you the rate between the modem and computer, and PROTOCOL tells you the protocol in use (NONE, LAP-B, LAP-B/HDX, AFT, X.25/LAPB, X.25/LAP-B/HDX, X.25/LAP-B/AFT, LAP-M, LAP-M/HDX, or ALT [referring to the V.42 "alternative protocol" which is MNP4 compatible]). In Ultra 96, if you set S95=32, you also get a fourth result code, after the PROTOCOL result code: COMPRESSION: <type> which can be CLASS 5 [MNP], V.42BIS, ADC [Hayes], or NONE. If you use W2, you get only a CONNECT result code (like W0). However, the speed indicated is the LINE speed, not the speed between the modem and computer (as in W0). But the modem DOES NOT change speeds to match what it says (as in W0); it leaves the speed the same between the PC and modem (speed remains locked). This might be just what you need. -- 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
larry@nstar.uucp (Larry Snyder) (11/11/90)
root@zswamp.fidonet.org (Geoffrey Welsh) writes: > FidoNet type folk have solved this problem rather neatly: the serial drivers >we use support a 'locked' mode; that is, the driver will always communicate with >the modem at a fixed speed (9600, 19200, 38400, whatever) regardless of what the >application sets the speed to. Here in nstar we lock all the modems at 19200 baud and enable hardware flow control. Then the modems all handle the stepping down to 2400 and 1200 baud - but the DTE is always set to 19200. This results in transfer rates in excess of the carrier (if both ends are using MNP5) - plus excellent transfer rates at high speed (1700cps on the HST, and 1400cps on the Trailblazers).. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, {uunet|backbone}!nstar!larry, larry%nstar@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
root@zswamp.fidonet.org (Geoffrey Welsh) (11/12/90)
Larry Snyder (larry@nstar.uucp ) wrote: >Here in nstar we lock all the modems at 19200 baud and >enable hardware >flow control. Then the modems all handle the stepping down >to 2400 and >1200 baud - but the DTE is always set to 19200. This >results in transfer >rates in excess of the carrier (if both ends are using MNP5) >- plus >excellent transfer rates at high speed (1700cps on the HST, >and 1400cps >on the Trailblazers).. This is fine & dandy, and in fact the person to whom I replied reported having tried this with unsatisfactory results. The problem is that software interrogating /dev/tty will probably be told that you're operating at 19,200 bps. If and when a user logs on at 2400 (or 1200... or 300!) and asks to perform a download, you want the estimate of the download time to be based on the modem's connect speed, not your locked port speed. This is the beauty of the driver-internal speed locking: as far as the software is concerned, it's talking to the serial port at the modem's connect speed. All estimates were based on connect speed, and stty < /dev/tty (actually, its DOS equivalent) would report the CONNECT speed, not the physical communication speed. I don't have to tell you this; you must have encountered it a couple of years back (I was network echomail co-ordinator for southwestern Ontario in '88 and I remember a regional echo co-ordinator named Larry Snyder. I thought it was rather silly of anyone south of Canada to call their system the "Northern Star"... alas, I stray from the conference topic. -- 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 MC Hammer, n. Device used to ensure firm seating of MicroChannel boards Try our new Bud 'C' compiler... it specializes in 'case' statements!
david@bacchus.esa.oz (David Burren) (11/12/90)
In <2766@hayes.uucp> tnixon@hayes.uucp (Toby Nixon) writes: >In article <s872007.658066970@otto>, s872007@otto.bf.rmit.oz.au (David Burren [Athos]) writes: >> It would be nice if the modem would tell the host "CONNECT 4800" if it gets >> an MNP connection, and "CONNECT 2400" if it got one at 1200 baud, but so far >> I haven't seen one that would, so I live with the problem. >> I've mentioned it to the manufacturers, but as yet it's just on the wish list. >Hayes has several features in their modems that may meet your needs. > >If you use the "W1" setting, instead of just the CONNECT result >code, you get three lines: > > CARRIER <speed> > PROTOCOL: <type> > CONNECT <speed> >If you use W2, you get only a CONNECT result code (like W0). >However, the speed indicated is the LINE speed, not the speed >between the modem and computer (as in W0). But the modem DOES NOT >change speeds to match what it says (as in W0); it leaves the speed >the same between the PC and modem (speed remains locked). This >might be just what you need. I think I didn't explain myself properly in my earlier posting. Either that or I've misunderstood your response. What I would like to see is a mode where (for example) the modem detects 2400 bps / MNP4, and talks to the host computer at 4800 bps. If 300 bps (poor sods) with no protocol was used, it would talk to the host at 600 bps. That is, don't have the host<->modem interface fixed, but let the link take advantage of the protocol's extra throughput. For dialin applications the verbose message returned to the host is not really important. What IS important is the data rate used by the modem. Any decent getty (or appropriate substitute) can handle it from there. For dialout, the same scheme would be used, but the CONNECT message is used by the dialler to switch line speed. Do you know of any modems that will do this? _____________________________________________________________________________ David Burren [Athos] Work: david@bacchus.esa.oz.au Software Development Engineer +61 3 819 4554 Expert Solutions Australia Home: athos%eyrie@labtam.oz.au Hawthorn, VIC +61 3 509 5775 - eyrie: Home of the Ninja Wookie -
larry@nstar.uucp (Larry Snyder) (11/13/90)
root@zswamp.fidonet.org (Geoffrey Welsh) writes: >Larry Snyder (larry@nstar.uucp ) wrote: > This is the beauty of the driver-internal speed locking: as far as the >software is concerned, it's talking to the serial port at the modem's connect >speed. All estimates were based on connect speed, and stty < /dev/tty >(actually, its DOS equivalent) would report the CONNECT speed, not the physical there are replacement gettys available which will accept the input from them modem telling the connect rate (ie: CONNECT 9600/ARQ) which could be put in a file with the port number, then the bbs could read this file and set the correct flags in the bbs.. > I don't have to tell you this; you must have encountered it a couple of >years back (I was network echomail co-ordinator for southwestern Ontario in >'88 and I remember a regional echo co-ordinator named Larry Snyder. I thought it >was rather silly of anyone south of Canada to call their system the "Northern >Star"... alas, I stray from the conference topic. I don't know why I picked that name - hmm.. I have several alias machine names here - and chances are one of those names will replace the name nstar sometime in the near future. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, {uunet|backbone}!nstar!larry, larry%nstar@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
s872007@otto.bf.rmit.oz.au (David Burren [Athos]) (11/13/90)
In <817@bacchus.esa.oz> david@bacchus.esa.oz (David Burren) writes: >What I would like to see is a mode where (for example) the modem detects >2400 bps / MNP4, and talks to the host computer at 4800 bps. >If 300 bps (poor sods) with no protocol was used, it would talk to the >host at 600 bps. ^^^ Make that 300. I wrote that at the end of a long day.. >That is, don't have the host<->modem interface fixed, but let the link >take advantage of the protocol's extra throughput. - David B.
vernon@hpcvaac.cv.hp.com (Vernon King) (11/21/90)
On Multitech modems you can tell from the front panel or the connect message
what level of mnp or lack of it that you are running.
connect 9600 9600 no mnp solid 96 light on modem
connect 9600 reliable 9600 baud mnp3,4 blink 2/sec on 96 light
connect 9600 reliable compressed 9600 baud mnp5 blink 1/sec on 96 light
This makes it easy to support people over the phone.
Vernon