*BSD News Article 47011


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!yarrina.connect.com.au!warrane.connect.com.au!godzilla.zeta.org.au!not-for-mail
From: bde@zeta.org.au (Bruce Evans)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: iijppp and kernel ppp device
Date: 20 Jul 1995 08:05:13 +1000
Organization: Kralizec Dialup Unix Sydney - +61-2-837-1183, v.32bis v.42bis
Lines: 46
Message-ID: <3ujvip$15j@godzilla.zeta.org.au>
References: <3u3co4$hur@Mars.mcs.com> <DBo868.802@net-tel.co.uk>
NNTP-Posting-Host: godzilla.zeta.org.au

In article <DBo868.802@net-tel.co.uk>,
Andrew Gordon  <andrew.gordon@net-tel.co.uk> wrote:

>There is no performance problem with iijppp on any reasonable hardware 
>configuration.  I have not measured the relative CPU usage of the two
>(not entirely obvious how you would go about making a meaningful 
>measurement of this!), but in practice (at modem speeds) this is not a 
>limiting factor.

I measured it.  For receiving at 115200 bps on a local line one a
486DX2/66/16550:

	protocol	overhead	throughput
	--------	--------	----------
	cat		 6.7%		11.25K/sec
	cslip		 6.7%		10.78K/sec
	ppp		 9.1%		10.74K/sec
	iijppp		11.3% (*)	10.80K/sec (+)
	zmodem		11.4%		10.73K/sec

(*) output overhead for iijpp is 100% due to a bug (fixed in FreeBSD-current).
(+) pred1 compression turned off.

All these overheads would scale to be very low for one line at modem
speeds, except possibly for bursts of compressible data.

>The one limiting case I have observed is on a machine here which is a 
>386SX/20, with not much RAM and a slow IDE disc (ie. a seriously slow 
>machine).  This machine is configured as a router between a dial-up line 
>with V.34 modem and a local Ethernet, and normally does this job 
>perfectly fine.  However, if I log into the machine and do somthing 
>aggressive, the ppp process can get swapped out and characters will be 
>lost if the buffers in the sio driver have been overrun before the 
>process is swapped back in.  With the kernel PPP, this would not happen 
>as most of the processing is done inside the kernel rather than in a 
>user-mode program that can be swapped out.  The overruns as such could 
>obviously be avoided by making inbound hardware handshake to the modem 
>work, but this would simply lead to a silent degredation in performance 

The kernel version actually has the same problem.  Processing of serial
input is done in timeout routines, and it can happen that all timeout
routines are delayed for several clock ticks while hardware interrupt
handlers are running.  Some buffers are sized assuming that the delay
is at most one full clock tick.
-- 
Bruce Evans  bde@zeta.org.au