From owner-freebsd-net Thu Mar 21 15:45:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 6F0D637B400; Thu, 21 Mar 2002 15:44:55 -0800 (PST) Received: from pool0042.cvx21-bradley.dialup.earthlink.net ([209.179.192.42] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16oCEd-0000UD-00; Thu, 21 Mar 2002 15:44:44 -0800 Message-ID: <3C9A7056.84A401EF@mindspring.com> Date: Thu, 21 Mar 2002 15:44:22 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Andre Oppermann Cc: Adrian Penisoara , freebsd-arch@freebsd.org, freebsd-net@freebsd.org, jeker@n-r-g.com Subject: Re: Help needed: ALTQ integration into FreeBSD References: <3C9A672C.F4A489AB@pipeline.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Andre Oppermann wrote: > The plan is to first research and identify all issues with the currect > networking stack in FreeBSD (1 month). Here are some that I think need to be addressed. o Can't make more that 64k outbound connections, without heroic measures, even with multiple IP addresses. o Exponential slowdown because of in_pcblookup_hash, at some "cliff" equalt to the number of buckets (should use a btree or some other scalable structure) o TCP/IP timers go into timeout wheel out of expiration order, so expiration has to traverse entire list; as most expire before they are e3ver called, this is all dead weight. Should use a per interval list for some small number of granular intervals; adding adds to the end of the list, so expiration can limit traversal to the first entry where the timeout is not expired, and not examine the rest of the outstanding timers. o Jon Lemon's patches don't deal with receiver livelock in the case that the livelock occurs higher in the stack (e.g. in the accept of connections). LRP, per Peter Druschel @ Rice University, is a better approach, overall. o Luigi Rizzo's patches only deal with fixed interval scheduling when polling is on, and so degrade radically with load outside the prediction parameters (e.g. NFS processing vs. packet forwarding vs. user space app.). Using queue depth to user space, and weighted fair share is a better scheduling policy that assures better performance, per Jeff Mogul, DEC Western Research Laboratories. o Fast retransmit (ala TCP Reno) has a number of problems during Fast Recovery that lead to "yoyo mode" (peristaltic congestion). Rate Halving, per Hoe @ Pittsburg Supercomputing Center at Carnegie Mellon is a better approach. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message