Date: Mon, 2 Dec 1996 23:10:51 -0500 From: "David S. Miller" <davem@jenolan.rutgers.edu> To: avalon@coombs.anu.edu.au Cc: dyson@freebsd.org, dennis@etinc.com, kpneal@pobox.com, hackers@freebsd.org, sparclinux@vger.rutgers.edu Subject: Re: TCP/IP bandwidth bragging Message-ID: <199612030410.XAA18471@jenolan.caipgeneral> In-Reply-To: <199612030346.WAA13314@caipfs.rutgers.edu> (message from Darren Reed on Tue, 3 Dec 1996 14:46:56 %2B1100 (EDT))
next in thread | previous in thread | raw e-mail | index | archive | help
From: Darren Reed <avalon@coombs.anu.edu.au> Date: Tue, 3 Dec 1996 14:46:56 +1100 (EDT) Why is it that whenever you pop your head up onto NetBSD or FreeBSD you look like a jerk waving the Linux flag and trying to cause trouble ? I was CC:'d and critisized for benchmark numbers I claim in my signature, and I am defending my accomplishments. Tell me, does Linux implement STREAMS in the kernel with a properly stacked network implementation, using DLPI and TLPI with fine grain mutexes and locks ? Oh yes, then we'll have real performance. Take a look at how many fastpaths and shortcuts the Solaris folks have to do to overcome the performance problems assosciated with streams. The Solaris performance people are constantly breaking their necks to find new ways to overcome these issues. If Ritchie couldn't get it right, perhaps this is good enough cause that it isn't such a hot idea, and that the implementation needs to be done differently (see below) or the entire idea trashed. Streams can be done at the user level with minimal kernel support. The only reason it is completely in the kernel in most commercial systems is that someone let it in there in the first place. It is very hard to "take out" something like that once it is in, especially in a commercial source tree. Fine grained mutexes and locks, yes that will indeed get you scaling better than a master lock implementation (which is what Linux has at the moment). But it is not a reasonable way to implement scalable SMP systems. For how I think it should be done, investigate the numerous papers available on non-blocking synchronization and (harder to find) self locking data structures. ---------------------------------------------//// Yow! 11.26 MB/s remote host TCP bandwidth & //// 199 usec remote TCP latency over 100Mb/s //// ethernet. Beat that! //// -----------------------------------------////__________ o David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612030410.XAA18471>