From owner-cvs-all@FreeBSD.ORG Wed Jun 30 12:33:29 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AA3616A4CE; Wed, 30 Jun 2004 12:33:29 +0000 (GMT) Received: from Awfulhak.org (awfulhak.demon.co.uk [80.177.173.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DE1243D48; Wed, 30 Jun 2004 12:33:28 +0000 (GMT) (envelope-from brian@Awfulhak.org) Received: from mail.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by Awfulhak.org (8.12.11/8.12.11) with SMTP id i5UCXSgV051146; Wed, 30 Jun 2004 13:33:28 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Wed, 30 Jun 2004 13:33:28 +0100 From: Brian Somers Message-Id: <20040630133328.071bc07b@dev.lan.Awfulhak.org> In-Reply-To: <200406301224.i5UCOuSc035406@repoman.freebsd.org> References: <200406301224.i5UCOuSc035406@repoman.freebsd.org> X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on gw.lan.Awfulhak.org cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/ppp acf.c async.c hdlc.c hdlc.h link.c link.h lqr.c lqr.h mbuf.h sync.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2004 12:33:29 -0000 On Wed, 30 Jun 2004 12:24:56 +0000 (UTC), Brian Somers wrote: > brian 2004-06-30 12:24:56 UTC > > FreeBSD src repository > > Modified files: > usr.sbin/ppp acf.c async.c hdlc.c hdlc.h link.c link.h > lqr.c lqr.h mbuf.h sync.c > Log: > Re-implement LQM, this time according to the rfc. > > PR: 11293 > MFC after: 4 weeks [.....] I'd be interested in peoples comments on the analysis that now turns up with ``set log +lqm''. My only real-world testing has been with my ADSL provider, and with output such as: LQM: ADSL: Input: LQM: Magic: 22264bc4 LastOutLQRs: 00000011 LQM: LastOutPackets: 0000267d LastOutOctets: 00ba1202 LQM: PeerInLQRs: 00000010 PeerInPackets: 02f31620 LQM: PeerInDiscards: 00000000 PeerInErrors: 00000000 LQM: PeerInOctets: bc00380e PeerOutLQRs: 00000010 LQM: PeerOutPackets: 4348204d PeerOutOctets: 4441502f [.....] LQM: ADSL: Input: LQM: Magic: 22264bc4 LastOutLQRs: 00000012 LQM: LastOutPackets: 00002a91 LastOutOctets: 00ce7585 LQM: PeerInLQRs: 00000011 PeerInPackets: 02f31a34 LQM: PeerInDiscards: 00000000 PeerInErrors: 00000000 LQM: PeerInOctets: bc14a3b9 PeerOutLQRs: 00000011 LQM: PeerOutPackets: 00000000 PeerOutOctets: 00004545 LQM: Analysis: LQM: Outbound lossage: 0 LQRs (0 en route), 0 packets, -2088 octets LQM: Inbound lossage: -1128801017 packets, -1145157573 octets LQM: Likely due to transport congestion I can only blame their implementation -- believe me, those PeerOutPackets/Octets are not for real!!! Perhaps they're including some L2TP header info or something with their PeerInOctets value... Cheers. -- Brian Don't _EVER_ lose your sense of humour !