From owner-cvs-all Tue Sep 7 4:24:59 1999 Delivered-To: cvs-all@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.128.198]) by hub.freebsd.org (Postfix) with ESMTP id 2D39214FF0; Tue, 7 Sep 1999 04:24:53 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (root@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id MAA40528; Tue, 7 Sep 1999 12:24:51 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (brian@localhost.lan.Awfulhak.org [127.0.0.1]) by keep.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id MAA87364; Tue, 7 Sep 1999 12:29:11 +0100 (BST) (envelope-from brian@keep.lan.Awfulhak.org) Message-Id: <199909071129.MAA87364@keep.lan.Awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: "Rodney W. Grimes" Cc: brian@FreeBSD.org (Brian Somers), cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/ppp command.c ip.c ipcp.c ipcp.h ppp.8 In-reply-to: Your message of "Tue, 07 Sep 1999 01:21:44 PDT." <199909070821.BAA05060@gndrsh.dnsmgr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 07 Sep 1999 12:29:10 +0100 From: Brian Somers Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > > brian 1999/09/07 00:51:12 PDT > > > > Modified files: > > usr.sbin/ppp command.c ip.c ipcp.c ipcp.h ppp.8 > > Log: > > Introduce a forth IP packet queue. Urgent packets with > > ip_tos == IPTOS_LOWDELAY now get precidence over urgent > > packets with ip_tos != IPTOS_LOWDELAY and non-urgent packets > > with ip_tos == IPTOS_LOWDELAY. > > I'm getting a bit concerned here, what is the depth of these > queues? If it is the default of 50, then we now eat a lot > of mbuf space should the ppp interface stall (and, trust me, > they do stall). I'm not really worried about the memory, > thats cheap enough, I'm worried about the amount of time > it will take for the higher priority queues to drain so that > the low priority traffic goes out after a stall. (Note, these > stalls are usually cause on ISDN TA's with Additional Call Offering > or Additional Outbound Call features running in ISDN Bonding mode.) > > It may require me to retune some OSPF timing parameters... > or mark the packets high priority (which, they really aren't) Ppp will eat up to 30 packets from the tun device (if you're using MP, add (2 * links) to that). These packets will sit in one of the four IP queues. The highest priority queue is reserved for link level traffic. There's no such thing in terms of IP traffic, so I'm sure you'll now spot the deliberate mistake :-I The second highest is reserved for ``urgent'' packets that have the ip_tos also set to LOWDELAY. The third highest is reserved for both ``urgent'' traffic and traffic with the ip_tos set to LOWDELAY. The lowest is reserved for everything else. Once the total packets in these four (soon to become 3) queues reaches the above number, ppp stops reading stuff from the tun device. If nothing can be sent within the ``choked'' time (default 2 minutes), ppp dumps the packets and starts reading again. If any of the link descriptors become writable (as reported by select()), ppp pushes a packet from the head of the highest priority IP queue, resets the choked timer and read()s more from the tun device. There's no overhead (apart from the minor ``find which queue has data'' search) in these extra queues. The extra one (added with this commit) is there so that (for example) telnet trafic that's marked as LOWDELAY will actually skip other telnet trafic. I think the only point worth arguing over is the previous commit that changed the magic number of packets from 20 to 30. > > Enhance the ``set urgent'' syntax to allow for urgent UDP > > packets as well as urgent TCP packets. > > And is there a knob to turn this all off and go back to 1 or > 2 queues only? No. I don't think we need one. > -- > Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net > -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message