Return to BSD News archive
Xref: sserve comp.os.386bsd.bugs:2585 comp.os.386bsd.questions:14319 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!hpg30a.csc.cuhk.hk!news.hk.net!howland.reston.ans.net!europa.eng.gtefsd.com!library.ucla.edu!news.mic.ucla.edu!pita.cns.ucla.edu!scott From: scott@pita.cns.ucla.edu (Scott Burris) Newsgroups: comp.os.386bsd.bugs,comp.os.386bsd.questions Subject: PPP comments/observations NetBSD 1.0 Date: 8 Nov 1994 01:25:45 GMT Organization: UCLA Campus Network Services Lines: 38 Message-ID: <39mk2p$f7@news.mic.ucla.edu> NNTP-Posting-Host: pita.cns.ucla.edu 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