Date: Thu, 18 Jul 1996 01:51:58 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: imp@village.org (Warner Losh) Cc: hasty@rah.star-gate.com, hackers@FreeBSD.ORG Subject: Re: Cygnus Engineering Talk on Linux Message-ID: <199607180651.BAA00222@dyson.iquest.net> In-Reply-To: <199607180544.XAA28329@rover.village.org> from "Warner Losh" at Jul 17, 96 11:44:45 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > : And things like lmbench don't help also :( > > :-). I just got asked in private mail how I could run a TCP/IP stack > on my machine with such horrible latency. I told them I ran a stack > that worked and it went down hill from there. > > What the heck is lmbench and why is it so wrong? > I am TRYING to choose my words very carefully, so please try to recognize that there are NO implications of putting down anyone elses work (flame avoidance :-).) This is all IMO. Actually, my measurements show that there is no difference in latency in the meat of the networking code. There might be a 20-30% additional latency with the driver interface. However, both FreeBSD and Linux have latency that is much better than acceptable. At this time, there is no need to worry, and like almost ANY micro-level benchmark, lat_tcp is good at measuring one, narrow aspect of performance. The latency figure measured is the latency under a very specific circumstance. Under heavier load, all bets are off on those results (for any OS.) Micro-level benchmarks are excellent tools for OS designers to help with quality control. However, the benchmark results are not good direct measures of quality, but are generally used to indicate potential problems. In this case, IMO, the biggest reason for improving our latency figures today is to make our lmbench results look better. I think that there are individuals looking at the issue, but I also don't think that it is identified as a 'problem.' It would be good to improve the latency, but to say that our network stack is broken because of this is laughable. Simply put, it works, and it works well. (If our latency was 700usecs and Linux was 300usecs, I would worry, but that isn't true.) Of course, if the problem was very bad, it would get fixed quickly. I don't think that we could find anyone who has used both networking suites who can provide hard numbers that the Linux networking code allows a large scale application to perform any better under real-world conditions, especially given a typical FreeBSD application of WWW servers or other types of Internet servers. Summing it up: I would not 'crow' over a performance difference unless it impacted system performance significantly for real world applications. In this case there is almost NO reason to 'crow'. BTW, there are areas where our network code is benchmarked by micro-level benchmarks as being faster, but I really don't think that they are worth bragging about either. Our networking code is well understood, and those who use it, know what to expect of it. Comparing it to other available TCP code, I don't think that people are often disappointed with FreeBSD. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607180651.BAA00222>