Date: Wed, 3 Sep 1997 19:12:00 +0930 From: Greg Lehey <grog@lemis.com> To: Mike Smith <mike@smith.net.au> Cc: FreeBSD Chat <chat@FreeBSD.ORG> Subject: Re: Anyway to get connect speed with usermode ppp/tun0 device? Message-ID: <19970903191200.16485@lemis.com> In-Reply-To: <199709030834.SAA00360@word.smith.net.au>; from Mike Smith on Wed, Sep 03, 1997 at 06:04:12PM %2B0930 References: <19970903175417.21095@lemis.com> <199709030834.SAA00360@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 03, 1997 at 06:04:12PM +0930, Mike Smith wrote: >>>>> 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. Thanks. You can have it back later. >>>> 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? What do you see in that direction? >>> 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. No, but it shouldn't mislead by using terms which only make sense with modems. Do you use the term 'baud' with PLIP? Why not? The term 'bit per second' is the only one you need with RS-232. >>> 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? In the terminology. >>> 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". Well, not I. It wasn't my idea, and anyway it would be done by the PPP software, which can guess better when it's safe (sort of). I'm just the pedant of the day, pointing out one way that you can get some kind of data of dubious value. > 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. I don't see that happening. A couple of incoming packets might get munged, that's all. > - 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. Well, that's the risk you take. > - If a retrain operation is in process, you may obtain stale data. Yup. > - Modems do not generally maintain statistical information on things > such as requested retransmission rates, which are necessary to > obtain useful throughput figures. Reasonable. It's not much of an indication, anyway. Once a day you take a snap reading, and try to determine something about line quality as a result. Doesn't make too much sense. > 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. Sure, that's a whole different level of information. Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970903191200.16485>