Date: Mon, 18 Dec 1995 17:22:55 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dennis@etinc.com (dennis) Cc: terry@lambert.org, hackers@freebsd.org Subject: Re: FBSD support inc. Message-ID: <199512190022.RAA13084@phaeton.artisoft.com> In-Reply-To: <199512182315.SAA22796@etinc.com> from "dennis" at Dec 18, 95 06:15:37 pm
next in thread | previous 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. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512190022.RAA13084>