Date: Wed, 03 Sep 1997 18:04:12 +0930 From: Mike Smith <mike@smith.net.au> To: Greg Lehey <grog@lemis.com> Cc: Mike Smith <mike@smith.net.au>, FreeBSD Chat <chat@FreeBSD.ORG> Subject: Re: Anyway to get connect speed with usermode ppp/tun0 device? Message-ID: <199709030834.SAA00360@word.smith.net.au> In-Reply-To: Your message of "Wed, 03 Sep 1997 17:54:18 %2B0930." <19970903175417.21095@lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >>> It is correct to specify the speed as "baud" in conjunction with a > >>> single-wire serial interface. > >> > >> I suppose you mean a two-wire interface. > > > > No. A two wire interface can transport four values per baud. > > That depends how it's modulated. Ok; you get to wear the pedant's hat this round. > >> Sure, you can use the term > >> baud if that's the speed talking about. Here we're talking about a > >> 2400 baud interface. It's transferring 38,400 bits per second. > > > > Not by any definition I can comprehend. You have a single wire serial > > interface, clocked at 38,400 transitions per second. > > Look down the wire. Huh? > > That is 38,400 baud no matter which way you look at it. To achieve > > 38,400 bps at 2400 baud you need a signalling mechanism with 65536 > > possible values, or 16 bits of significance. This puts you in the > > high-end trellis-encoding market, certainly not on good ol' EIA-232. > > In the context we're talking about, nobody's talking about good old > RS-232. We're talking about a modem link. The bauds only make sense > when they're not bits per second; otherwise they're just obfuscation. But you are. You are talking about the output from 'stty', which was applied to an RS-232 interface. If you want to know what the modem link is doing, ask the modem; there's no way in hell the host is going to know. > > I don't understand. stty can only report on the configuration of the > > serial port, and it does that correctly. > > But misleadingly. And for no good reason. In what way is reporting the current configuration of the hardware misleading? > > It has no way of knowing what the modem thinks its doing; as I have > > already pointed out it is impossible to know what the modem is > > "really" doing at any point in time anyway. > > You said that you didn't know a way to extract the information. > That's not quite the same thing. If I could dig my modem docco out of > one of this maze of twisted boxes, all alike, I could check on that, > but wasn't there an S register that contains this information? No. You are thinking "I will usurp communications with the modem, send the escape sequence to swap to command mode, send a modem command to extract the current link state, and return to connect mode". This will not work because : - You will inject the escape sequence into the outbound data stream, corrupting the traffic currently passing through. Depending on the application and the configuration of the modem at the other end, you may force _it_ into command mode as well, effectively killing the link. - While you are in command mode, the behaviour of the modem with regard to data coming from the other end is undefined; some will attempt to flowcontrol the link, others will discard data, still others will fail to communicate at all, causing the other end to drop the link. - If a retrain operation is in process, you may obtain stale data. - Modems do not generally maintain statistical information on things such as requested retransmission rates, which are necessary to obtain useful throughput figures. In some cases you can reliably extract the information you require; if the modem in question is "intelligently managed" and you can talk to the management module, ie. it is rackmounted or has separate command and data ports, you can talk OOB and sometimes obtain the data you require. Sorry. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709030834.SAA00360>