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 [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
