Date: Thu, 11 Jan 1996 12:48:59 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dennis@etinc.com (dennis) Cc: terry@lambert.org, hackers@freebsd.org Subject: Re: pppd vs ijppp Message-ID: <199601111948.MAA17847@phaeton.artisoft.com> In-Reply-To: <199601111815.NAA00389@etinc.com> from "dennis" at Jan 11, 96 01:15:01 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >What we are talking about adding is some propagation delay, and even > >then, it will be on the basis of system loading and user load (which > >may be zero) that determines if a context switch will actually be to > >anything other than the idle process. And if it's not, the majority > >of the protection domain crossing overhead is in the copy in/out, > >and that's recoverable based on implementation (see previous posting). > > From the inside looking out this may seem trivial, but the difference, > for example, of sync vs async response times at the same speed are > clearly user-noticable. I don't know about "inside looking out"... I have implemented a streams stack modification to Mentat Streams on VMS using multiple mapping of address ranges (code for VMS done by another Novell engineer when DEC argued that it wasn't possible because of resource tracking issues) and saved a total of 3 copies -- grand total, one less than the non streams implementation. Most of the time (and processor) will be spent in the bcopy's in all cases. You can't avoid the copy from the packet assembly area to the card memory, but almost all other copies can be avoided, if you are clever. I think this makes the issue not "is user space PPP less efficient than kernel space PPP", but "is the best possible user space PPP less efficient than the best possible kernel space PPP". I think the answer to that question is "no". > The issue here is that you NEED a pentium to get the performance > that you should get with a clunky old '386, which often goes > unnotices because most of us have a lot more power than we need. You only need the power if you ar going to burn cycles. In most cases, you will be I/O bound, even on 386 hardware, and it pays to burn *some* cycles to avoid the copies. That's why it pays to use a 50MHz processor with a 50MHz bus instead of a 66MHz processor with a 33MHz bus (and why I rail against clock doubling). In the examples I've cited, however, the cost is all paid up front at setup time and in the DDI in terms of down-copy buffer recovery, which in general is a single additional compare. Using the Intel ICE based protected mode profiling tools places the expense squarely on the instructions implementing the copy. It makes sense that if you avoid the copy by merging the protection domains, the argument goes away. > But (if) you were concerned about competing in a low-end or > embedded market (which is what I would do if i did), then those > delays become killers, not only to the ppp sessions themselves but > also to the overall system's performance. My concern in any software venture that I expected to make money on would be minimizing the support costs. This is one reason I am so anti-GPL, since it wants me to give away the software and charge for support. In a correct approach, your average calls-per-customer is some fraction smaller than 1. Many software comapnies intentionally consider support as a profit center, and obfuscation that requires going to a manual as an anti-piracy technique. This is quite bogus short term thinking. Getting "balls-to-the-wall" performance must come secondary after minimizing after market costs; it pays in both word of mouth and in repeat sales. Better to have "almost-balls-to-the-wall" and fewer support hassles... a hassle for you will always be a worse hassle for a customer, who is probably less familiar with your product than you are. To put it in a single aphorism: anything that works is better than anything that doesn't. You may recognize this as a reformulation of Occam's Razor, the guiding principle of "The Scientific Method". 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?199601111948.MAA17847>