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