Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!ucsd!ucrmath!alchemy!bbs From: bbs@alchemy.UUCP (BBS Administration) Newsgroups: comp.unix.programmer Subject: Re: Connect Speed Message-ID: <422@alchemy.UUCP> Date: 30 Apr 91 02:36:09 GMT References: <1991Apr29.142635.20942@nstar.rn.com> <418@alchemy.UUCP> Reply-To: bbs@alchemy.UUCP (BBS Administration) Organization: Alchemy Software Designs Lines: 63 In article <1991Apr29.142635.20942@nstar.rn.com> larry@nstar.rn.com (Larry Snyder) writes: >bbs@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