From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 14 17:21:17 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B34D16A412 for ; Thu, 14 Sep 2006 17:21:17 +0000 (UTC) (envelope-from gcorcoran@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06A1643D49 for ; Thu, 14 Sep 2006 17:21:16 +0000 (GMT) (envelope-from gcorcoran@rcn.com) Received: from mr08.lnh.mail.rcn.net ([207.172.157.28]) by smtp02.lnh.mail.rcn.net with ESMTP; 14 Sep 2006 13:21:16 -0400 X-IronPort-AV: i="4.09,165,1157342400"; d="scan'208"; a="299656428:sNHT113473602" Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr08.lnh.mail.rcn.net (MOS 3.7.5a-GA) with ESMTP id GYZ38944; Thu, 14 Sep 2006 13:21:13 -0400 (EDT) Received: from 207-172-55-230.c3-0.tlg-ubr5.atw-tlg.pa.cable.rcn.com (HELO [10.56.78.130]) ([207.172.55.230]) by smtp01.lnh.mail.rcn.net with ESMTP; 14 Sep 2006 13:21:13 -0400 X-IronPort-AV: i="4.09,165,1157342400"; d="scan'208"; a="276692524:sNHT24747688" Message-ID: <45099123.4000500@rcn.com> Date: Thu, 14 Sep 2006 13:28:03 -0400 From: Gary Corcoran User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <863bauk3gp.fsf@dwp.des.no> In-Reply-To: <863bauk3gp.fsf@dwp.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Junkmail: UCE(50) X-Junkmail-Status: score=50/50, host=mr08.lnh.mail.rcn.net X-Junkmail-SD-Raw: score=bulk(0), refid=str=0001.0A090201.45098DCF.001E,ss=3,fgs=0, ip=207.172.4.11, so=2006-05-09 23:27:51, dmn=5.2.113/2006-07-26 Cc: freebsd-hackers@freebsd.org Subject: Re: numbers don't lie ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2006 17:21:17 -0000 Dag-Erling Smørgrav wrote: > Danny Braniss writes: >> Im testing these 2 boxes, Sun X4100 and Dell-2950, and: >> >> SUN X4100: Dual Core AMD Opteron(tm) Processor 280 (2393.19-MHz K8-class CPU) >> one 70g sata disk >> DELL 2950: Intel(R) Xeon(TM) CPU 3.20GHz (3192.98-MHz K8-class CPU) >> 4 sata disks + raid0 >> >> they both run identical 6.1-STABLE. >> >> my 'cpu benchmark' shows the amd being much better than the intel. >> but, doing a make buildworld give interesting results: >> >> dell-2950 : make -j16 TARGET_ARCH=amd64 buildworld : 24m17.41s real 1h3m3.26s user 17m15.07s sys >> dell-2950 : make -j8 TARGET_ARCH=amd64 buildworld : 24m8.28s real 1h2m59.38s user 16m16.20s sys >> >> sunfire : make -j16 TARGET_ARCH=amd64 buildworld : 24m21.38s real 49m6.68s user 14m22.64s sys >> sunfire : make -j8 TARGET_ARCH=amd64 buildworld : 23m47.69s real 48m53.58s user 13m44.81s sys >> >> which probably says something about my 'cpu benchmark' :-( >> but why is the user time so much different between the boxes? > > I don't see what's so surprising. User time reflects time actually > spent compiling stuff; you can see there that the Opteron is much > faster than the Xeon. Sys time is time spent executing kernel code on > behalf of the build, which is mostly time spent processing I/O > requests (but does not include time spent actually reading from or > writing to disks). > > The reason why there is no significant difference in wall time between > the two is that buildworld is mostly bound by I/O and memory > bandwidth, not by CPU power. If you have enough memory, place > /usr/src and /usr/obj on malloc()-backed RAM disks and see if it makes > any difference. The confusing thing is that I thought 'real' time should be >= 'user' + 'sys'. But here 'user' is much greater than 'real' for both machines! The sense I got from the other messages in this thread is that 'user' time is somewhat meaningless (i.e. unreliable as a measure) in a multi-CPU and/or hyperthreading environment. Can you clarify? Thanks, Gary