From owner-freebsd-chat Thu Sep 4 09:52:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA10865 for chat-outgoing; Thu, 4 Sep 1997 09:52:23 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA10858 for ; Thu, 4 Sep 1997 09:52:15 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id JAA01485 for ; Thu, 4 Sep 1997 09:51:57 -0700 (PDT) To: chat@freebsd.org Subject: "Jordan K. Hubbard": http://techweb.cmp.com/internetwk/reviews/rev0901-3.htm Date: Thu, 04 Sep 1997 09:51:57 -0700 Message-ID: <1482.873391917@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-chat@freebsd.org X-Loop: FreeBSD.org Precedence: bulk My letter to the editor in response to the Internet Week article. Just FYI... ------- Forwarded Message Sender: jkh@time.cdrom.com Date: Thu, 04 Sep 1997 05:30:08 -0700 From: "Jordan K. Hubbard" Organization: Walnut Creek CDROM To: pbrown@cmp.com Subject: http://techweb.cmp.com/internetwk/reviews/rev0901-3.htm Dear Patricia, Sorry to write to you directly, but it's unclear just what Sean Fulton's email address is and I'm writing in regard to his performance review in this month's Internet Week under the title "OS Holy Wars". First, on behalf of the FreeBSD Project, I'd like to thank Mr. Fulton for what was an unusually balanced review, one which also took more time to delve a little more deeply under the surface issues than most reviewers are generally willing to take. Well done. We also appreciate the fact that each OS was tested in its "out of box" configuration and, while we would never dream of making excuses for FreeBSD's rather preciptious decline in performance in your tests, we merely wished to point out one small factor which may have been of strong relevance to your results. When IBM designed the PC BIOS, they made one rather glaring mistake in their choice of a 16 bit memory size register, the value therein representing the total memory size in kilobytes (they probably thinking that, like the 640K barrier, no one would ever have more than 64MB of memory in a machine). FreeBSD has, until very recently, suffered from the unfortunate shortcoming of blindly believing this memory size register and not probing anything beyond 64MB of memory. In the case of the 128MB Dell systems used in your testing, this could have been easily worked around by compiling a kernel with ``options "MAXMEM=(128*1024)"'' set in the kernel configuration file but, since it was also your goal to test out-of-box configurations, I can see where this step may have been simply skipped in the interests of avoiding a potential morass of customization details for each and every OS (in your place, I'd have probably done precisely the same thing). The dmesg output from the FreeBSD system, should it still be available, will, in any case, quickly tell the tale of whether or not the FreeBSD tests were, in fact, done in half the memory available to the other operating systems (and if you did not compile a custom kernel then that would actually be a certainty). It would certainly explain the sharp dip in performance as the FreeBSD machine began to swap where the other operating systems did not and, again, I raise it here merely for your information, not to make excuses for an aspect of FreeBSD's memory sizing behavior which could rightfully be deemed a bug. It is still, nonetheless, a matter of some personal curiousity as to how these tests might have gone had we not suffered from this particular problem or had your test systems been provided with 64MB instead of 128MB of RAM. Ah well, c'est la vie! With thanks for reviewing our product and best begards, - -- - - Jordan Hubbard FreeBSD core team / Walnut Creek CDROM. ------- End of Forwarded Message