Date: Sat, 03 Oct 1998 01:08:39 +0800 From: Peter Wemm <peter@netplex.com.au> To: Marc Slemko <marcs@znep.com> Cc: Nate Williams <nate@mt.sri.com>, Zach Heilig <zach@gaffaneys.com>, Kris Kennaway <kkennawa@physics.adelaide.edu.au>, current@FreeBSD.ORG Subject: Re: fetch -p Message-ID: <199810021708.BAA24001@spinner.netplex.com.au> In-Reply-To: Your message of "Fri, 02 Oct 1998 08:42:34 MST." <Pine.GSO.4.02A.9810020841260.4587-100000@redfish>
next in thread | previous in thread | raw e-mail | index | archive | help
Marc Slemko wrote: > On Fri, 2 Oct 1998, Nate Williams wrote: > > > > I heard a rumor that the modem <-> phone <-> modem was a syncronous > > > connection. > > > > Whomever told you this rumor was confused. > > > > > In this case, there would be only 8 bits, no start or stop bits. > > > > See above. > > Huh? Are you trying to tell me there are start and stop bits (ie. 10 bits > for each 8 bits of data) on a modem? Sorry, with current modems that just > isn't true. There is some overhead, but it is more difficult to compute > than a simplistic start and stop bit. > > Sure, on the serial cable there is but that doesn't matter. Yes. LAP-M is a HDLC framing protocol. Incoming data is packetized (at 10 bits/char), optionally compressed, then sent via LAP-M which does error recovery over an 8-bit-per-byte sync frame. The on-the-wire encoding has natural bit clocking (as I understand it) so there is no need for start/stop bits to keep the bit timing straight. It's similar to ISDN. There, a 64K B channel is 64000 bits/sec on the wire. Data is synchronous and clock synchronized so there are no start and stop bits, just bit patterns for start and end of packets etc. This means that your 64K link gives you 8000 (theoretical) bytes/sec. There are losses because the HDLC frames have address/control data, CRC's, start markers, packet length (I think). So, in reality you get a smidge less than 8000 bytes/sec when you are using large packets. Here's the kicker.. If you feed one of these via an async serial line, your 64K sync ISDN line can carry approx 80,000 async bits/sec. Running a 128K link is 160,000 bits/sec. I've seen people saying '115,200 baud is close enough to 128K - I can live with that', but in fact they are only running at 115200/160000 efficiency (ie: only using ~72% of what they are paying for). Back to modems, the situation is similar, but the protocols are different. Async data comes in and when a packet is filled or a timeout is reached, it starts processing the packet. Many modems allow you to choose the packet size (64, 128, or 256 bytes). THis is the real cause of the large latency over a modem - the data has been arriving at the serial port for some time before the modem begins really transmitting it. It then has to go across the wire in full, and once it's fully arrived, it gets CRC checked, optionally decompressed and then starts being sent to the other computer. That's a lot of delay. Take a 28.8K connection. Telecommunications uses K = 1000, so that's a 28800 bits per second *line* speed. When running LAP-M, that's sync, so now allowing for CRC, framing, etc overheads, that's a theoretical limit of 3600 bytes/ sec. After doing 1024<->1000 conversion, that's a theoretical maximum of 3.515 "K"/sec - assuming no overheads. PPP/IP/TCP has to fit in as well. I recall regularly seeing 3.3/3.4K/sec reported download times over a 28.8K link (but it's been a while. they screwed up my lines so now I'm lucky to get 24000 noisy connects). Having compression turned on adds some extra overheads. LAP-M has (I believe) a protocol field in the packet header like PPP does, so theoretically it can just send a packet that's got zero compression as an 'uncompressed' frame. However, it'd be rare that there wasn't some form of compression with a FreeBSD machine since there are options present and VJ compression won't shrink the IP and TCP headers in the general case.. So there's scope for V42bis compression to shrink the PPP+IP+TCP headers a little. Modems often allow you to run at fixed speed without error correction, sync conversion, etc. Each bit is sent down the wire as it arrives (more or less, there could be some buffering). Theoretically there should be *much* less latency - but you'd also be sending 10 bits/byte down the wire too. Having the modems operate in sync mode is something that even less consistantly implemented. If we could pump out HDLC frames over clock synchronized serial ports, we'd get every last bit of throughput. Combine that with PPP with zlib compression and you've got some dynamite throughput with lower than the present latency (assuming you use small packets). However, at this point we're starting to sound an aweful lot like ISDN, routers (or smart TA's with sync/async ppp conversion and very high serial interface baud rates). At one time I had a specially constructed text file at one point that I used to demonstrate a ~4 megabyte/sec download over a compressing ppp link over a 28.8K modem. Fun, eh? Hopefully I've got my facts straight because I know there are a couple of comms people lurking here. I'm sure I'll get told off right away.. :-) Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810021708.BAA24001>