Date: Mon, 18 Dec 1995 21:28:08 -0500 From: dennis@etinc.com (dennis) To: Terry Lambert <terry@lambert.org> Cc: hackers@freebsd.org Subject: Re: FBSD support inc. Message-ID: <199512190228.VAA23233@etinc.com>
next in thread | raw e-mail | index | archive | help
>> Your example is certainly not the rule here....most "standard" interfaces >> are inferior as a matter of compromise. NDIS, Packet Drivers, ODI >> (for example) enhance functionality and simplicity but are mediocre >> interfaces and inferior to most custom ones. Your passion is admirable, but I'm afraid that you've missed the point. the point is, that standard interfaces always make trade offs, and always leave a few things out. There's a price to pay for generality. The point that I was trying to make above, was that if you wanted to implement a single product for a specialized system you wouldn't use any of the standards above...because they basically suck. [Terrys stuff below] > >Actually, the ODI overhead in the UnixWare product is squarely in the >glue for the streams stack interface. It is a pretty big hit because >of the way streams is scheduled to run is very different from the way >ODI is run in the Native NetWare server. > >The ODI is actually vastly superior in that it does peek-ahead to know >the size of the read buffer prior to doing the transfer such that it >actually saves a copy (using Intel instructiong timing tools indicates >the majority of streams/DDI time is being spent in the rep: the bcopy). > >It's actually possible with a slight modification to streams to pass >around buffer pointers as references instread of entities and save the >initial copy until the copy at the DDI/DKI level, where a copy is needed >anyway to coalese the buffrs onto the stream tail (ie: in the card >memeory itself). > >We could do a hell of a lot worse than ODI. > >NDIS, on the other hand, is known to be buggy in a number of 16 bit >cases having to do with odd byte packet lengths backfilling the wrong >byte. > >> My personal opinion (please don't flame here...) is that most internet >> protocols are pretty awful (SNMP ala ASN1 is an obvious example) and >> the fact that they have gained widespread acceptance has much more to >> do with the failure of other standards to be widely implemented (due >> to commercial infighting) than their superior design. > >Like GOSIP? Sorry, FTAM still sucks... 8^). > >I agree that SNMP is a generally bad design from the trap level and >the reporting callback mechanism as it was typically implemented. SNMP II >solves some of this, particularly in the free IBM implementation (which >incidently also requires streams). > > >This all has little to do with the implementability of a more general >user interface soloution. Users are the slowest component in the loop, >so as long as you pay close attenton to appearance-of-speed issues, >there shouldn't be a problem. > >Suggesting a good implementation (8-)) has little to do with past bad >implementations. You can't be suggesting that nothing be done because >similar projects have failed therefore this one must too?!? > > > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. > > ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512190228.VAA23233>