On Jul 3,  4:51pm, David Kelly wrote:
} 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:

     Last I checked, this was port-sun3@netbsd.org...  Anyways, I am
aware of userland PPP implementations.  Just because they exists
doesn't mean that they don't suffer from performance issues.

} m
} 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).

     And, this is exactly the problem.  You want to send some data, so
you pass it to the kernel.  It sees that the data is supposed to be
routed via a tunnel, and passes it to the process attached to the
tunnel.  This process does some work then passes it back to the kernel
to be sent out the serial port.  And, finally the kernel returns to
you, saying the data is being sent.  That is a total of four context
switches.  With an in-kernel PPP stack, you pass the data to the
kernel, it does all the processing, then returns to saying that the
data is being sent, which is only two context switches.  That is much
more efficient and when you multipy it by a lot of packets, it can make
a difference.

} > } > 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.

     This is fine if the only thing it has to do is to send those
packets; but, if you want the system to do anything else, then you want
every part of the system to operate as efficiently as possible.  Just
because machines are getting faster, that doesn't mean you can excuse
sloppiness.  We expect these faster machines to do more.  Therefore,
everything has to be done efficiently or the effective speed of the
system will decrease.

} > } 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 

     TCP/IP has to deal with all sorts of things, such as sattelite
links.  Tuning it to make it deal with this as well can only make it
better.

} 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.

     This is a datalink protocol.  Something like BPF, which is used to
send raw ethernet packets should do the trick for an API here as well.

} > } Routing is quite another issue.
} > 
} >      Why?  Routing is well establish.
} 
} Clearly you are not a ham and/or have not used AX.25.

     No.  But, that doesn't mean I don't have an interest in it, or a
perspective on how best to implement it.  I actually did have a
potential project for it, but that is on the back burner for now (yes,
I'm aware that there are licencing requirements).

}-- End of excerpt from David Kelly