Connect Speed

[BBS Administration]

In article <1991Apr29.142635.20942 at nstar.rn.com> larry at nstar.rn.com (Larry Snyder) writes:
>bbs at alchemy.UUCP (BBS Administration) writes:
>>The BBS program we're writing always reports the connect speed to be this
>>speed (19,200 bps) when appending a caller log file. We need to fix this
>>speed so that if a user calls in using some kind of compression protocol
>>we can take advantage of it by sending data to the modem faster than the
>>connect speed between modems, but at the same time, we'd like to know
>>what the >actual< speed is between the modems.

>why not modify (or replace) getty to accept the return rate from
>the modem (ie: CONNECT FAST, CONNECT 2400, etc.) and pass that to
>the BBS - while keeping the DTE locked at 19200?

Well, here's the deal with regards to what I've learned thus far (thanks to
all who have replied both publically and privately):

1) There is no consistent way of obtaining this information from an S
   register within the modem. Sure, it could be done for a >particular<
   modem, but it would not work for all modems.

2) Replacing the getty with one that parses the result code is a solution,
   but since many systems have rather intricate getty/login combinations
   these days (SCO ODT comes to mind as one) it doesn't appear to be an
   elegant solution either. Besides, when someone wants to install our
   system, I'm not so sure they'll be happy knowing that to obtain a
   certain functionality, they must >replace< certain portions of their
   system (I wouldn't want to do it).

3) Perhaps most importantly: even if this rate were known, it might not
   truly reflect the rate of data exchange between the two modems. One
   user might connect at 2400 bps and have 4:1 compression, another may
   not. The effective rate of compression varies a great deal depending
   upon the nature of the data being transmitted, so even then the rate
   might not be constant during the connection.

4) Finally, this data is somewhat trivial for my application (after some
   thought). I wanted to be able to generate a report that gave stats on
   what speeds comprised what percentage of connections. I also wanted to
   use this information to estimate how long downloading a file might
   take (but, as stated above, that varies on the data being sent,
   compression, etc.). Finally, we use curses to draw windows to alert
   the user and in the past, if the user connected at a "slow" speed
   or if a preference was set to >force< this action, these windows
   would not be used and a "hack-like" message would be printed at the
   bottom line of the screen (to eliminate refreshing the screen after
   the window was removed).

So, the solution seems to be: forget about this data, don't bother with
estimating how long a transfer will take because modem to modem transfer
rates are not as simple as they used to be, and if the user connects at
a "slow" speed, let them enable the preference to >not< display curses
windows.

Once again, thanks to everyone for providing some much needed insight into
this problem. What would we do without USENET? :)

-- John

John Donahue, Senior Partner | UUCP: ucrmath!alchemy!{bbs, gumby} | The Future
  Alchemy Software Designs   | INET: {bbs, gumby}@alchemy.UUCP    | Begins Now
-------------------+---------+------------------------------------+-----------
Communique On-line | +1-714-278-0862 {12, 24, 96v32, 19.2k} T2500 | Next Wave:
Information System |    Alchemy Software Designs Support System   | Communique