Date: Fri, 1 Nov 1996 15:11:51 +0100 (MET) From: Greg Lehey <grog@lemis.de> To: kuku@gilberto.physik.rwth-aachen.de Cc: questions@FreeBSD.org (FreeBSD Questions), isdn@muc.ditec.de (FreeBSD ISDN Distribution List) Subject: Re: Any ISDN-BRI cards work under FreeBSD? Message-ID: <199611011411.PAA20388@freebie.lemis.de> In-Reply-To: <199611011304.OAA09714@gilberto.physik.rwth-aachen.de> from Christoph Kukulies at "Nov 1, 96 02:04:40 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Christoph Kukulies writes: >> Terry Lambert writes: >>>>>> done it yet. They currently only run single channel connections (you >>>>>> can have two different connections to different destinations). The >>>>>> theoretical maximum throughput is 8 kB/s (64,000 bps), which is >>>>>> somewhat less than the theoretical maximum of the 115.2 kbps lines >>>>>> (11.52 kB/s). >>>> >>>> Why do you divide by 8 in the one case and by 10 in the other? >>> >>> My guesses: >>> >>> 8) 8*8k = 64k; conversion is for sync framing >>> >>> 10) 1 start + 8bits + 1 stop = 10bits; conversion is for >>> async framing >> >> I'm surprised you need to guess. Yes, that's correct. People seem to >> have problems understanding this one, so I'll go into a little more >> detail: >> >> Synchronous transmission is block oriented. Various techniques are >> used to recognize the beginning and end of the block, and all the data >> in a block are sent without any delay between the bits. When >> transmitting 8 bit bytes (octets), there's a ratio of 8 bits per >> octet, so 64 kbps becomes 8 kB/s. > > But in HDLC you have bit stuffing (8th bit or nineth?). Doesn't > this have to be taken into account? Yes, HDLC inserts a 0 bit after every 5 consecutive 1 bits in order to distinguish from a flag, which contains 6 '1' bits in a row. Theoretically we should take this into account, just as we should take the protocol overhead (headers, etc) into account. But that makes it very much more complicated, and in particular bit stuffing doesn't make much difference. The headers can, of course: looking at a simple 'ping', which by default sends 56 bytes of data and 8 bytes of information. The ICMP overhead adds 20 bytes, so if you're using raw IP over ISDN, you'll send 84 bytes, so the throughput of the line, viewed as payload data, drops from 48.7 kb/s. If you use PPP over ISDN, as the Americans love to do, you'll add another 8 bytes of overhead, making a packet of 92 bytes and dropping your effective throughput to 44.5 kb/s. Bundle two channels and connect via async at 115.2 kb/s, and your effective throughput is 64.11 kb/s--only fractionally more than the "raw" throughput of a single B channel. This is only one example, of course, with relatively short packets. Take 1500 byte packets and things don't look nearly as bad. You'll be using TCP with this size packet, which adds 40 bytes of headers, so the maximum data you can transfer is 1460 bytes. With transparent IP, you'll get 62.3 kb/s. Using PPP, it's hardly any worse at 62.0 kb/s. On the other hand, take keystrokes (1 character), and send them via TCP, and you give your 64 kb/s line an effective throughput of 195 bytes per second. Use PPP, and your overhead goes to 48 bytes, and your effective througput drops to 163 bytes per second. By comparison, the penalty due to bit stuffing is independent of the length of the packet: assuming a random distribution of data, you'll get 5 consecutive 1 bits once in 32 times, so it will add 1 bit every 192 bits, or about 0.52 overhead. Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611011411.PAA20388>