I've got a few comments/observations about PPP.  I'm sending this to
both the netbsd-bugs list and appropriate newsgroups.

First, my hardware configuration:
486DX2/66 ISA 8meg, IDE and Buslogic SCSI, 15550 serial ports, USR V.34 modem.
Modem talks to serial port at 57,600.

Until this weekend, I had been doing PPP from a DOS based machine running
Novell's Lan Workplace for DOS and their windows PPP dialer to a Cisco
2500 series terminal server.  The Cisco is set up to put different kinds
of data into queues of different priority.  In particular, FTP traffic
gets the lowest possible priority, the idea being to preserve interactive 
traffic during FTP's.  Under this scenario, while FTPing big gziped files 
(part of the NetBSD distribution) in the directory from the terminal server 
to the local computer, I got FTP transfer rates of about 2700 bytes/sec, and 
telnet sessions still responded fairly well.  Pings to the terminal server 
would jump from about 140ms to 400 ms when the FTP was active.  

	I then set up NetBSD 1.0 and got PPP working.  Now when I do FTPs, my 
interactive traffic gets VERY slow.  I still get approximately the same 
transfer rate, however pings to the terminal server jump to about 6500ms (yes, 
that's 6.5 seconds).  No pings get dropped, the latency just goes through the 
roof.  Why such a big difference?  I find it hard to believe that NetBSD is 
pounding on the modem so much harder.  Could there be some sort of buffering 
problem in the kernel? 

	Secondly, I'm getting a few silo overflow messages every hour.  Is 
it known that NetBSD's com driver can't keep up at 57,600?  Since the port 
is set to do hardware handshaking, why am I getting the messages at all?  
When the FIFO is full, doesn't the serial port hardware automatically 
deassert CTS (or RTS, can't remember which one for this direction)?

----------
Scott Burris
UCLA Campus Network Services
(310) 206-4860 scott@pita.cns.ucla.edu