Date: Wed, 31 Jan 1996 23:30:57 +0800 From: Peter Wemm <peter@jhome.DIALix.COM> To: Poul-Henning Kamp <phk@critter.tfs.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Multi-Port Async Cards Message-ID: <199601311531.XAA09606@jhome.DIALix.COM> In-Reply-To: Your message of "Wed, 31 Jan 1996 12:46:03 %2B0100." <4563.823088763@critter.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> We (the company I work for) use Stallion's sync cards on our SVR4 machines. >> It does most the HDLC framing and cooking on-board. In that particular >> case, we hacked pppd so that it didn't push the asyhdlc STREAMS module >> onto the stack, and fed the hdlc frames _directly_ into the ppp module >> with no encoding/decoding required at all. It's really cool when STREAMS >> works the way it was intended to. ;-) > >And that is exactly what it's meant for: async character based io. Well, not necessarily.. :-) In this case, it all fell into place because of the modularity. There was no async character based io at all - I was mentioning the Sync cards. The ppp protocol stack is particularly well suited to a layered approach.. ie: ppp is layered over hdlc, and for async IO there is a module to convert character IO to hdlc. The problem with streams is that it's doing huge amounts of queueing and dequeueing at every layer, killing performance. In contrast, the monolithic BSD networking "protocol engine" generally queues things once each way. One of the Linux ISDN projects built a simple streams implementation for this purpose. They had a streams "interface" that was wired to their tcp/ip implementation. They pushed/popped modules on top of their ISDN card drivers to implement the ISDN protocol layers, eventually arriving at a HDLC frame interface. They used ppp as a streams module on top of all that and linked it under the "interface". By doing this, they ended up with a modular implementation that coped fairly nicely with the difference hardware that had different amounts of "intelligence". Right from dumb boards that give you the raw bit stream, through to boards that implement some of the higher layers in hardware/firmware. I dont recall where the source for this was though... I looked at this a year or two ago. With the radically differing amount of hardware support in the ISDN offerings, this seems like a sane way to do it, at least for slower speed stuff (ie: 64K/128K). Cheers, -Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601311531.XAA09606>