From owner-freebsd-hackers Thu Jan 11 10:16:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA08399 for hackers-outgoing; Thu, 11 Jan 1996 10:16:46 -0800 (PST) Received: from etinc.com (et-gw.etinc.com [165.254.13.209]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA08394 for ; Thu, 11 Jan 1996 10:16:43 -0800 (PST) Received: from dialup-110.cdmo.com (dialup-110.cdmo.com [204.141.95.167]) by etinc.com (8.6.12/8.6.9) with SMTP id NAA00389; Thu, 11 Jan 1996 13:15:01 -0500 Date: Thu, 11 Jan 1996 13:15:01 -0500 Message-Id: <199601111815.NAA00389@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Terry Lambert From: dennis@etinc.com (dennis) Subject: Re: pppd vs ijppp Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >Geeze, Dennis, and I usually agree with you because of your customer >perspective... > >> A good example is the routing function, which is in the kernel because its >> too damn inefficient in user space. > >PPP routing is a matter of poll retention time vs. transmissability, >since the interface PPP uses is generally several orders of magnitude >slower than that which it routes to/from. > >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. 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. 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. > >> Mr kendals example of "lets move tcp out of the kernel" was a good >> analogy to the kind of arguments we're getting on this thread. > >It's not as stupid as it sounds. There are some sound technical reasons >why you might want to do this, and if you used mapping tricks (or better, >page protection via page anonymity), you might even get better performance >out of your applications. I leave you to rummage papers on the topic >from ftp.sage.usenix.org. on second thought this is not a good analogy since TCP apps are out of the kernel as well, and they represent largely local processing rather than raw routing, as is the main issue with ppp here. There could clearly be gains and an actual increase in functionality by doing this. db ---------------------------------------------------------------------------- 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