John Nemeth writes:
> On Jun 23,  3:09pm, David Kelly wrote:
> } How much does it hurt for pppd(8) or ppp(8) to be outside the kernel?
> 
>      ppp(4) is inside the kernel.  pppd(8)'s job is to dial the modem,
> login,  and setup the connection.  Once the connection is established,
> ppp(4) in the kernel takes over and handles the actual data transfer.

FreeBSD's man says:

PPP(8)                  FreeBSD System Manager's Manual                 PPP(8)

NAME
     ppp - Point to Point Protocol (a.k.a. user-ppp)

SYNOPSIS
     ppp [-mode] [-nat] [-quiet] [-unitN] [system] ...

DESCRIPTION
     This is a user process PPP software package.  Normally, PPP is implement-
     ed as a part of the kernel (e.g., as managed by pppd(8)) and it's thus
     somewhat hard to debug and/or modify its behaviour.  However, in this im-
     plementation PPP is done as a user process with the help of the tunnel
     device driver (tun).

> } > You should also
> } > consider that many machines that run NetBSD are old and slow.  AX25
> } > in itself is not slow, it depends on the communication hardware being
> } > used.
> } 
> } 1200 bps is the definitive interface. 9600 can still be purchased out 
> 
>      Irregardless, you still don't want the system wasting time on
> needless overhead.  Not everybody uses lightning fast machines.  Come
> to think of it, this port-sun3, which means the machines we are talking
> about aren't exactly modern speed demons.

At the usual 1200 bps three packets per second is all we are talking 
about. The "definitive" implementation runs on a Z80 at 4 MHz. Classic 
Suns *are* speed demons.

Even at a blazing 9600 bps we're still not over 5 packets per second. 
The problem is the use of consumer grade voice radios converted to data 
use. The synthesizers involved are slow to stabilize so at 1200 there 
is usually a 300 ms burst of sync flags before data. At 9600 better 
radios are usually used and 100 to 150 ms is more common, sub-20 ms is 
possible but will cause bitching about retries by others on the same 
frequency with less capable radios.

Considering the way hams will scrounge for old radios and put them to 
use, this is quite appropriate for a list of classic Sun users.

> } A major problem with using kernel TCP/IP stacks is the very long delays 
> } which are typical of AX.25 RF links.
> 
>     So?  If there are problems, then the stack should be tuned.  TCP/IP
> was designed to work over all sorts of links.

TCP/IP is good, but not that good. Its currently self-adapting but 
AX.25 is an extreme not seen elsewhere. Am aware of work in Linux for 
an API to tune the timing parameters. But I stand by my statements that 
for AX.25 use an external protocol engine is the right way to go. 
Partly because TCP/IP is a minority on the airwaves, and to be useful 
one will have to speak the plain AX.25 protocol also.

> } Interesting that the entire 44.x.x.x net is ampr.org.
> 
>      Probably an artifact of history.  That net has been around for a
> long time and dates back to the early days of the general Internet,
> when it was still mainly educational institutions and the US military.
> Back then, it wasn't nearly as hard as it is now to get a "Class A"
> address.  Although, given that it is a worldwide semi-public network,
> they just might qualify by today's rules.
> 
> } Routing is quite another issue.
> 
>      Why?  Routing is well establish.
> 
> }-- End of excerpt from David Kelly

Clearly you are not a ham and/or have not used AX.25.

--
David Kelly N4HHE, dkelly@hiwaay.net
=====================================================================
The human mind ordinarily operates at only ten percent of its
capacity -- the rest is overhead for the operating system.