Date: Wed, 10 Jan 1996 17:01:34 -0700 From: Nate Williams <nate@sri.MT.net> To: dennis@etinc.com (dennis) Cc: Nate Williams <nate@rocky.sri.MT.net>, hackers@freebsd.org Subject: Re: pppd vs ijppp Message-ID: <199601110001.RAA19534@rocky.sri.MT.net> In-Reply-To: <199601102345.SAA00248@etinc.com> References: <199601102345.SAA00248@etinc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >Do you have *any* idea what you are talking about? > Yes...actually i have a pretty good idea what im talking about..... This remains to be seen, but.. > >I doubt very much that 99.9% of the users notice the load difference > >between user-land ppp and kernel ppp. > > What i meant is that setup is not nearly as important as passing > packets, which is the bottom line here. The fact that most people feel > that they need 133Mhz pentiums to run a few modems over a 56k link > says something about the overhead in the software they're using, and > the importance of performance. Then what in the heck are you arguing about? You claimed that we should add all of the features in ijppp back into the kernel-mode ppp. If you *do* know what you are talking about, then why do you want to stuff all of the user-level stuff into the kernel, such as built-in dial capabilities, routing, dial-on-demand, etc...? Those + the ease of use are the differences between the user driver and nthe kernel driver, and one would assume you knew that given your desire to put things 'back' into the kernel. > >Downsides to adding the features to the kernel: > >1) It's always in memory even if the user doesn't want it. > >2) It's difficult to debug > >3) It doesn't belong in the kernel since it's not a 'kernel' type of function. > > 1 is not true Sure it is. The kernel is NOT pageable. It's in-core all the time, and therefore takes up memory even when the driver is not used. , 2 is true only because no one has added good debugging code, and Are you goin to change that problem? You're more than welcome to provide solutions, rather than complain about the state of affairs. Really! > 3 is simply wrong....very wrong. The code that exists in the user-land code which is not in the kernel code *DOESN'T* (!!) below in the kernel. Obviously, you don't know what you are talking if you think adding in dial capabilities would be a good thing in the kernel. > adding the couple of features that the user space implementation > offers is not a lot of code and the advantages would be tremendous. And these features would be? (I've already admitted that the kernel code would benefit from Predictor-1 compression, so you can't use that) > In another message you said something about "a half meg" memory penalty, and > on this > you are WAY off, nate! You wanted the features of ijppp in the kernel. We already have ppp in the kernel, so obviously we're not talking about the PPP protocol, so you must be talking about all of the user-land stuff. What else could there be to talk about? > And lastly, I think if you took a show of hands on providers and users > after asking them if they would mind using even 50k to get better > performance i think that I'd be surprised to see even 1 hand not > waving wildly in the air. Give them the whole picture. 'You can have this really cool package which integrates everything you want and is *really* easy to setup. However, it uses about 5% of your CPU. OR, you could have this other version which uses about 1% of your CPU, but it's alot harder to setup and doesn't have as many features.' Or, we could all of those features in the kernel, increase your memory use by a couple 100K (always, even if you don't use it), and it would take us 6 months to get it working. :)' Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601110001.RAA19534>