luce@aurs01.UUCP (J. Luce) (02/18/91)
This filling of a buffer of a high speed modem is a bit of pain. The BBS
s/w that I use does not pause after each page or msg. You press P during
typeout to pause and any key to restart. Therefore, 9600+ callers still
get a boatload of msgs to pass by before the P takes effect.
I have gone so far as to limit the users to 2400 in interactive mode and
mailers to access via 9600. But the people who call direct and want to
d/l or u/l get hurt by this. ::sigh::
Any bright ideas running around about this (no, changing BBS s/w is
*NOT* an option)... :)
P.S. Would having the port run at 9600 (not 19.2 or 38.4) be feasible? I
realize that would counteract the use of V.42 and MNP-5 but 9600 is
still 4 times faster than 2400 :).
-------------------------------------------------------------------
John Luce | Life is the leading cause of death
Alcatel Network Systems | -----------------------------------------
Raleigh, NC | Standard Disclaimer Applies
919-850-6787 | Mail? Here? Try aurs01!aurw46!luce@mcnc.org
| or ...!mcnc!aurgate!luce
-------------------------------- or John.Luce@f130.n151.z1.fidonet.org tnixon@hayes.uucp (02/19/91)
In article <59581@aurs01.UUCP>, luce@aurs01.UUCP (J. Luce) writes: > This filling of a buffer of a high speed modem is a bit of pain. The BBS > s/w that I use does not pause after each page or msg. You press P during > typeout to pause and any key to restart. Therefore, 9600+ callers still > get a boatload of msgs to pass by before the P takes effect. > ... > Any bright ideas running around about this (no, changing BBS s/w is > *NOT* an option)... :) Well, when I'm reading messages online on a BBS, I start the messages coming at me, then use the Peruse Buffer in my program (Smartcom Exec) or the Scroll Lock key. This immediately stops the LOCAL program from displaying any more data. When the software's buffer fills, it flows-off the modem, which flows-off the remote modem, which flows-off the remote software. This is much more effective and immediate than depending on end-to-end "pause" schemes built into the BBS software -- assuming you're using error control modems (which most people do, at 9600). When viewing the Peruse buffer, data continues to be recieved in the "background", and I simply scroll down to look at it (hit the Page Down key a lot). That way, the data continues to be received full speed, but I can read it at my own pace. Much nicer. -- 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
kevin@msa3b.UUCP (Kevin P. Kleinfelter) (02/20/91)
luce@aurs01.UUCP (J. Luce) writes: >This filling of a buffer of a high speed modem is a bit of pain. The BBS >s/w that I use does not pause after each page or msg. You press P during >typeout to pause and any key to restart. Therefore, 9600+ callers still >get a boatload of msgs to pass by before the P takes effect. Remove the 'P' for pause completely (or ignore it, if you do not have source). Have the users configure THEIR modems to respect XON/XOFF flow control (&K4 on Hayes 9600 and compatible modems). Then have your users use ^S to stop and ^Q to start. Since the modem is local to the user, the data should stop immediately. -- Kevin Kleinfelter @ Dun and Bradstreet Software, Inc (404) 239-2347 {emory,gatech}!nanovx!msa3b!kevin Look closely at the return address. It is nanovx and NOT nanovAx.
luce@aurs01.UUCP (J. Luce) (02/20/91)
In article <3785.27c11588@hayes.uucp> tnixon@hayes.uucp writes: > >Well, when I'm reading messages online on a BBS, I start the >messages coming at me, then use the Peruse Buffer in my program [stuff about Smartcom deleted] > >When viewing the Peruse buffer, data continues to be recieved in the >"background", and I simply scroll down to look at it (hit the Page >Down key a lot). That way, the data continues to be received full >speed, but I can read it at my own pace. Much nicer. > > -- Toby > >-- >Toby Nixon, Principal Engineer | Voice +1-404-449-8791 Telex 151243420 >Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 Agreed that this is more elegant, but face it, most of the users don't want to be bothered with it. Will locking my port at user speed prevent this problem? ------------------------------------------------------------------- John Luce | Life is the leading cause of death Alcatel Network Systems | ----------------------------------------- Raleigh, NC | Standard Disclaimer Applies 919-850-6787 | Mail? Here? Try aurs01!aurw46!luce@mcnc.org | or ...!mcnc!aurgate!luce -------------------------------- or John.Luce@f130.n151.z1.fidonet.org
tnixon@hayes.uucp (02/22/91)
In article <59592@aurs01.UUCP>, luce@aurs01.UUCP (J. Luce) writes: > Agreed that this is more elegant, but face it, most of the users don't > want to be bothered with it. Will locking my port at user speed prevent > this problem? Well, it probably would solve the problem to lock your speed at the carrier speed. But then you defeat any benefit of data compression at the same time. Kind of cutting off your nose to spite your face. -- 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