Date: Wed, 10 Jan 1996 12:04:07 -0700 From: Nate Williams <nate@rocky.sri.MT.net> To: Jerry Kendall <jerry@border.com> Cc: hackers@freebsd.org Subject: Re: pppd vs ijppp Message-ID: <199601101904.MAA18446@rocky.sri.MT.net> In-Reply-To: <96Jan10.135034est.20483@janus.border.com> References: <199601101800.LAA18199@rocky.sri.MT.net> <96Jan10.135034est.20483@janus.border.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I doubt very much that 99.9% of the users notice the load difference > > between user-land ppp and kernel ppp. > > > > 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)Since most users will want access to the Internet AND most *people* compare > just about everything to what microsoft is offering(Win95), having it in > memory is not that bad, how much memory can it really take??? Well over a half a megabyte of memory. :( And, setting up the user-stuff is much easier than the kernel stuff, so it's more M$ like. > 2)Do you think it was easy for microsoft people to debug it... Huh? > Since this is *free*BSD, if some *people* want it, then why not have > it supported at the kernel level??? Because they *already* have it. > 3)That is like saying TCP does not belong in the kernel. It's nothing like that. Do you folks have any idea what you're asking about, or are you simply arguing cause you like to see your words over email? > > Upsides: > > 1) It's faster. > > > > Show me why your upsides is better than the downsides above? Show me > > that it negatively affects a significant # of users (not in your mind, > > in their mind). > > Getting 10% better throughput.. The user-land code puts more load on your computer because it is less effecient (kernel context switches etc..), hence it's 'faster'. But, the throughput of user-land PPP is the same since it's line limited, not CPU limited. The SAME throughput, no more. However, in actuality the user-land stuff gives better throughput simply because it supports Predictor-1 compression, which the kernel version doesn't (yet, I'm working on that). Maybe I should have used 'less CPU load' instead of faster in my arguements above. [ I don't have real numbers to back the below up, but I'm basing it on stuff Bruce has mentioned in the past. If necessary, I'll go look them up later. ] Now, if you've got ten outgoing (vs. incoming, more later) PPP lines which uses ijppp, you're going to saturate a 486/33 pretty much. However, if you are running ten outgoing PPP lines, you shouldn't be using a 486 box. :) Now, if you've got ten incoming lines, you don't need any of the feautures of user-land PPP, so using kernel ppp is quite adequate. Except for Pred-1 (I'm working on it), the kernel and user PPP stuff has the same functionality for incoming lines. Functionality that *belongs* in the kernel will get put in the kernel when folks take the time to do it. But dial-on-demand, phone numbers, routing table additions, etc. DON'T belong in the kernel. Even the kernel version doesn't add those, but requires you to do all of your own 'user-land' stuff by hand. The user-level driver does all of this in an integrated, easy to use package. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601101904.MAA18446>