From owner-freebsd-isp  Thu Oct  3 08:43:55 1996
Return-Path: owner-isp
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id IAA03775
          for isp-outgoing; Thu, 3 Oct 1996 08:43:55 -0700 (PDT)
Received: from genesis.ximango.com.br (root@genesis.ximango.com.br [200.238.54.1])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA03760
          for <freebsd-isp@freebsd.org>; Thu, 3 Oct 1996 08:43:44 -0700 (PDT)
Received: (from jdt@localhost) by genesis.ximango.com.br (8.7.5/8.7.3) id MAA02110; Thu, 3 Oct 1996 12:33:31 GMT
Date: Thu, 3 Oct 1996 12:33:31 +0000 ()
From: Joao Daniel Togni <jdt@genesis.ximango.com.br>
To: "Graydon Hoare ()" <admin@multinet.net>
cc: freebsd-isp@freebsd.org
Subject: Re: FreeBSD as a PPP server
In-Reply-To: <Pine.BSF.3.91.961003095315.20647A-100000@house.multinet.net>
Message-ID: <Pine.BSF.3.91.961003123127.2072B-100000@genesis>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-isp@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Thu, 3 Oct 1996, Graydon Hoare () wrote:

> On Thu, 3 Oct 1996, Peter Childs wrote:
> 
> > In article <52uk4s$hms@al.imforei.apana.org.au> you wrote:
> > 
> > : 2. Is there a real difference between user-mode ppp (iijppp?) and
> > :    kernel-mode WRT performance?  I would think it would, especially as you
> > :    add more serial ports.
> > 
> >  I guess so... The userland ppp code is quite slick but i haven't used
> >  the kernel land stuff.
> 
> I can't argue with the case for uptime, but have you measured the data rate
> your clients are capable of using user mode PPP? I have no experience in this
> department cause there were already netblazers when I got here, but I'm
> hazarding a guess that it will frustrate users to have high-priority system
> management tasks taking user-mode runtime away from their traffic.  Doesn't
> it make better sense for Syslog, radiusd and getty to be scheduled around the
> packet flow, not in with it? I mean, bearing in mind that TCP has pretty
> hefty acknowledge cycles, and a "little delay" in the last mile can cut the
> effective throughput dramatically... Check it out, Unless the user code is
> vastly superior (and here again I profess ignorance. I haven't read it, and
> am not smart enough to know one way or another even if I had ;) I'll bet a
> carefully configured PPP-server-kernel will give you much nicer results. 
> 
	PPP is better than SLIP? Faster?

Thanks,

Daniel