bbs@alchemy.UUCP (BBS Administration) (04/29/91)
Here's the situation:
PC Clone running SCO Xenix v2.3.2 with a Telebit T2500 attached to a "dumb"
serial card and a fixed data rate between computer and modem set to 19,200
bps.
Here's the problem:
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.
Our current method of determining the connect speed is to do an ioctl ()
on the tty and examine the c_cflag element of the termio structure. This
worked in the past when we didn't fix the "baudrate", but no longer works
as we'd like.
Is there a solution that allows the computer<->modem speed to remain locked
at 19,200 but still permits our program to obtain the actual >connect<
speed between our modem and the callers' modem? The solution must be
hardware independent so examining some register of the modem is not a
viable alternative (unless there is some industry standard that places
this information in a consistent location; and even then, "peeking" this
out of the modem would be a project in and of itself).
Please email any suggestion you might have and if there is sufficient
interest in my findings, I'll post a summary. Thanks in advance!
-- 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 | Communiquelarry@nstar.rn.com (Larry Snyder) (04/29/91)
bbs@alchemy.UUCP (BBS Administration) writes: >Here's the problem: >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? We have such a getty here on nstar in our archives.. -- Larry Snyder, NSTAR Public Access Unix 219-289-0287/317-251-7391 HST/PEP/V.32/v.32bis/v.42bis regional UUCP mapping coordinator {larry@nstar.rn.com, ..!uunet!nstar.rn.com!larry}
bbs@alchemy.UUCP (BBS Administration) (04/30/91)
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
rahim@cse.uta.edu (Khalid Rahim) (05/03/91)
I have question for UNIX programmers !! I am working on developing a YACC specifications, and I am not sure how to invoke a file from the YACC code. I want to open up a file and should be able to read it from YACC code. If any of you have done it before or worked exclusively with YACC before, please do let me know the secret !!!! Thank you very much Emain to: rahim@evax.uta.edu
srodawa@vela.acs.oakland.edu (Ron Srodawa) (05/03/91)
In article <1991May2.233629.25541@cse.uta.edu> rahim@cse.uta.edu (Khalid Rahim) writes: >YACC code. I want to open up a file and should >be able to read it from YACC code. YACC code normally reads from standard input. It calls a routine named yylex to read each token. If you wrote your own, then the solution would be obvious. I assume you used lex to generate this. List the entries in the library gotten by -ll (the lex library). One of these will obviously be the read routine. Write your own with the same name. Now that can open your file. BTW, the source code for the -ll and -ly routines is quite trivial. Some of it is given in the lex and yacc documentation verbatim. You can also look at the lex documentation for a description of how lex reads characters. As a university, we have a source code license for Unix so we just modify the library code (a copy of it) when we need to do this. You might look to flex and bison for freely available equivalent code. -- | Ronald J. Srodawa | Internet: srodawa@vela.oakland.edu | | School of Engineering and CS | UUCP: srodawa@vela.UUCP | | Oakland University | Voice: (313) 370-2247 | | Rochester, Michigan 48309-4401 | |
martin@mwtech.UUCP (Martin Weitzel) (05/04/91)
In article <1991May2.233629.25541@cse.uta.edu> rahim@cse.uta.edu (Khalid Rahim) writes: >I have question for UNIX programmers !! >I am working on developing a YACC specifications, >and I am not sure how to invoke a file from the >YACC code. I want to open up a file and should >be able to read it from YACC code. I posted a long article which answered this and some more lex/yacc related questions around July 1990 to comp.unix.wizards. Sorry, but I have no other pointers than the subject - it was "Re: yacc & lex - cupla questions" I could repost a slightly revised version of this article, but I'm not sure if there's sufficient interrest. (To Khalid: If no kind soul mailed you my article and there's no way to get it from a local site that is archiving c.u.w, drop me a note.) -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83