Date: Thu, 21 Mar 2002 15:44:22 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Andre Oppermann <oppermann@pipeline.ch> Cc: Adrian Penisoara <ady@freebsd.ady.ro>, freebsd-arch@freebsd.org, freebsd-net@freebsd.org, jeker@n-r-g.com Subject: Re: Help needed: ALTQ integration into FreeBSD Message-ID: <3C9A7056.84A401EF@mindspring.com> References: <Pine.BSF.4.10.10203212217430.48394-100000@ady.warpnet.ro> <3C9A672C.F4A489AB@pipeline.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
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-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C9A7056.84A401EF>