From owner-freebsd-performance@FreeBSD.ORG Wed Jun 13 09:06:23 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0464C16A46D for ; Wed, 13 Jun 2007 09:06:23 +0000 (UTC) (envelope-from filip.palian@hyperion.pl) Received: from kopytko.hyperion.pl (unregister198031239087.c31.msk.pl [87.239.31.198]) by mx1.freebsd.org (Postfix) with ESMTP id 7FAEB13C458 for ; Wed, 13 Jun 2007 09:06:21 +0000 (UTC) (envelope-from filip.palian@hyperion.pl) Received: from localhost (kopytko [127.0.0.1]) by kopytko.hyperion.pl (Postfix by dzikus) with ESMTP id AE1012673B; Wed, 13 Jun 2007 11:06:19 +0200 (CEST) Received: from kopytko.hyperion.pl ([127.0.0.1]) by localhost (kopytko [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25388-08; Wed, 13 Jun 2007 11:06:16 +0200 (CEST) Received: from [192.168.1.103] (unregister084009144195.c9.msk.pl [195.144.9.84]) by kopytko.hyperion.pl (Postfix by dzikus) with ESMTP id 694CA26738; Wed, 13 Jun 2007 11:06:12 +0200 (CEST) Message-ID: <466FB3B0.2080600@hyperion.pl> Date: Wed, 13 Jun 2007 11:06:56 +0200 From: Filip Palian User-Agent: Thunderbird 2.0.0.0 (X11/20070607) MIME-Version: 1.0 To: Tom Judge References: <46692AC6.30700@hyperion.pl> <466937BC.10703@tomjudge.com> In-Reply-To: <466937BC.10703@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by dziki-amavis Cc: freebsd-performance@freebsd.org Subject: Re: Dell/Perc5 raid/MPT SAS Integrated Raid Write Performance X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 09:06:23 -0000 Tom Judge pisze: > Filip Palian wrote: >> Hi folks, >> >> I've also encountered problems with write performnce on PE860, below are >> some details. >> >> > > I believe that a fix for this went into RELENG_6 this week. > Scott Long MFC'd the following fix at 2007-06-05 21:32:57. > > Tom > Great thing that sombody cares. > Commit Message: > > scottl 2007-06-03 23:13:05 UTC > > FreeBSD src repository > > Modified files: > sys/dev/mpt mpt.c mpt.h mpt_cam.c > Log: > mpt.c: > mpt.h: > Add support for reading extended configuration pages. > mpt_cam.c: > Do a top level topology scan on the SAS controller. If any > SATA device are discovered in this scan, send a passthrough FIS to set > the write cache. This is controllable through the following tunable at > boot: > hw.mpt.enable_sata_wc: > -1 = Do not configure, use the controller default > 0 = Disable the write cache > 1 = Enable the write cache > > The default is -1. This tunable is just a hack and may be > deprecated in the future. > Unfortunatly I couldn't use this fix because disk performance is crucial for me and i could not depend on the "hack" which may be "deprecated in the future". > Turning on the write cache alleviates the write performance problems > with SATA that many people have observed. It is not recommend for those > who value data reliability! I cannot stress this strongly enough. > However, it is useful in certain circumstances, and it brings the > performence in line with what a generic SATA controller running under > the FreeBSD ATA driver provides (and the ATA driver has had the WC > enabled by default for years). > Just for curiosity I've tried to run FreeBSD 6.2 in Xen and KVM with Gentoo as a host system. Under Xen nothing could be done because of "BTX halted" error with the same values as described in the bug "http://lists.freebsd.org/pipermail/freebsd-bugs/2006-November/020906.html" (in my example it was an IDE cdrom). But happily KVM did the work. I've intsalled FreeBSD and run blogbench and guess what... The results were: Final score for writes: 84 Final score for reads : 13636 Summing up, I'll wait for 7.0 release and then I'll put my hands on it. Regards, Filip Palian From owner-freebsd-performance@FreeBSD.ORG Wed Jun 13 20:38:22 2007 Return-Path: X-Original-To: performance@freebsd.org Delivered-To: freebsd-performance@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6B1D416A474 for ; Wed, 13 Jun 2007 20:38:22 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 33F7213C458 for ; Wed, 13 Jun 2007 20:38:22 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l5DKcKUY068499 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Wed, 13 Jun 2007 16:38:21 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Wed, 13 Jun 2007 13:37:44 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: performance@freebsd.org Message-ID: <20070613133712.C60816@10.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Call for testers, amd64 only, new scheduler. (fwd) X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 20:38:22 -0000 I'm forwarding this email that I sent to current@ in the hopes that some performance minded people will tell me their results with this new scheduler infrastructure. Thanks, Jeff ---------- Forwarded message ---------- Date: Tue, 12 Jun 2007 19:28:39 -0700 (PDT) From: Jeff Roberson To: current@freebsd.org Subject: Call for testers, amd64 only, new scheduler. This is actually a ULE derivative that I have been discussing for some time. It is now stable enough that I would like more people to bang on it and give feedback about performance and tell me about any stability problems they encounter. You can see in the following graph that the ramp-up times for the sysbench benchmark have improved although the tail has suffered a little: http://people.freebsd.org/~jeff/sysbench.png The new scheduler is FreeBSD-7.0-ULE-pcpulocks. On my dual cpu system the results are much less ambiguous. It's a 10-15% win on sysbench across the board. This also improves an artificial thread benchmark included with sysbench by 500% on an 8 way and gives us ebizzy numbers on par with or better than linux. It also includes a mechanism that should improve bde's nfs buildworld times, although I have not yet verified that. Hopefully he'll try it as well. It should reduce CPU idle time while also negating the effects of thrashing other cpus run queues in the idle thread. The new patch is at: http://people.freebsd.org/~jeff/schedsmp.diff You have to change your scheduler to SCHED_SMP. x86 support is forthcoming. Depending on feedback and what re thinks I am going to consider replacing ULE entirely with SCHED_SMP or committing this as a seperate scheduler for 7.0. Thanks, Jeff _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-performance@FreeBSD.ORG Thu Jun 14 08:48:19 2007 Return-Path: X-Original-To: performance@FreeBSD.org Delivered-To: freebsd-performance@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8561716A41F; Thu, 14 Jun 2007 08:48:19 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6991B13C448; Thu, 14 Jun 2007 08:48:19 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 5C02A1A4D80; Thu, 14 Jun 2007 01:47:52 -0700 (PDT) Received: from rot13.obsecurity.org (rot13.obsecurity.org [192.168.1.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 6FD68512A6; Thu, 14 Jun 2007 04:48:18 -0400 (EDT) Received: by rot13.obsecurity.org (Postfix, from userid 1001) id A88D6BE96; Thu, 14 Jun 2007 04:48:17 -0400 (EDT) Date: Thu, 14 Jun 2007 04:48:17 -0400 From: Kris Kennaway To: performance@FreeBSD.org Message-ID: <20070614084817.GA81087@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: smp@FreeBSD.org, current@FreeBSD.org Subject: BIND 9.4.1 performance on FreeBSD 6.2 vs. 7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 08:48:19 -0000 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I have been benchmarking BIND 9.4.1 recursive query performance on an 8-core opteron, using the resperf utility (dns/dnsperf in ports). The query data set was taken from www.freebsd.org's httpd-access.log with some of the highly aggressive robot IP addresses pruned out (to avoid huge numbers of repeated queries against a small subset of addresses, which would skew the results). Testing was done over a broadcom gigabit ethernet cable connected back-to-back between two identical machines. named was restarted in between tests to flush the cache. resperf is designed to slowly increase the query rate over a period of 60 seconds, up to a maximum query rate, to determine the point at which the server starts to fall behind on answering queries. To more accurately measure this point, in each case I tuned the maximum query rate so that the server fell behind after around 50 seconds of load. 7.0 was used with up-to-date CVS sources and the SCHED_SMP (enhanced SMP) scheduler, which is not yet committed but for which patches have been posted by Jeff Roberson. Actually this did not make much difference compared to ULE on this workload, although I didn't graph ULE. BIND 9.4.1 from the base system was used for the threaded version, and the bind94 port with threads disabled for comparison. All debugging was disabled. 6.2 was used from CVS with libthr and the 4BSD scheduler (ULE 1.0 is broken in 6.x). In addition I also tested a previously posted patch from rwatson that may be found here: www.watson.org/~robert/freebsd/netperf/20070311-sosend_dgram.diff The results show several interesting things: http://obsecurity.dyndns.org/bind-resperf.png Firstly, 7.0 beats 6.2 across the board, and has about 60% higher peak performance. BIND does not scale beyond 4 worker threads, but this appears to be due to high contention on pthread mutexes in userland, i.e. a BIND design problem rather than a FreeBSD kernel problem. There is moderate UDP contention that, if it can be optimized, might increase peak performance but is not likely to improve scaling. For now it appears that BIND 9.4 does not scale to >4 CPUs. FreeBSD 6.2 seems to have at least two major performance bottlenecks, due to file descriptor locking, and poor scaling of the old sx lock implementation (both have been fixed in 7.0). I actually don't know what is using the sx locks so heavily in 6.2, there does not appear to be an analogue on the 7.0 lock profile. There are other optimizations in 7.0 that are probably responsible for a smaller part of the difference. Robert's patch gives a modest boost to 6.2 at light concurrency but is swamped by the other scaling problems at high load. The graph should not be interpreted as showing that this patch performs worse at high load; the variance is so enormous that it is easily consistent with the CVS data. It would be interesting to test BIND performance when acting as an authoritative server, which probably has very different performance characteristics; the difficulty there is getting access to a suitably interesting and representative zone file and query data. Kris --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGcQDRWry0BWjoQKURAnalAJ98Xy6gN98dAgfaE2/wEcGP1h6aJACfaJWC G2I23fG2Bt5St7iCAUxl6Kw= =Jqh4 -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- From owner-freebsd-performance@FreeBSD.ORG Thu Jun 14 08:52:33 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1272416A469 for ; Thu, 14 Jun 2007 08:52:33 +0000 (UTC) (envelope-from redcrash@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id C7EC413C4B0 for ; Thu, 14 Jun 2007 08:52:32 +0000 (UTC) (envelope-from redcrash@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so117950anc for ; Thu, 14 Jun 2007 01:52:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=ktsd1cdOmRcwi3SJcVqqiJGhjWbsxSS3ealvSCD0OgtpF5Zw49VAbXRpwTGv0Wotv42Iw6mao3Q4PQezTgIkowN22EbQLeF74ES4utfyM8mtApEI0960mSYyJ0QL22sSzJoGbvGfPuWG1LcnI66g1OasDBypS2dUu9m89MY/m3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=gqYiaJlyn4II1Hw/JUkgr/BgsI0hcaa/jD+EJmigJAqTcu67LWyxMcFWdNwV9xqdvoXkaN/suM1iS96u3+QsT4hoo+X43P4ujux3843Aycr00yXQdivI9mmDZH0AIaoSpBeAGj7ntCoLUyZo3ghjGPIOQo+GGLeIgDA+pczqxcs= Received: by 10.100.227.5 with SMTP id z5mr935252ang.1181811152095; Thu, 14 Jun 2007 01:52:32 -0700 (PDT) Received: by 10.100.141.3 with HTTP; Thu, 14 Jun 2007 01:52:32 -0700 (PDT) Message-ID: Date: Thu, 14 Jun 2007 10:52:32 +0200 From: "Harald Servat" To: freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, freebsd-hpc@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: PAPI in the ports X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 08:52:33 -0000 Hello, I'm glad to announce you that PAPI-3.5.0 has reached the FreeBSD ports tree and now it's generally available for all FreeBSD users. Port information is available at http://www.freebsd.org/cgi/ports.cgi?query=papi&stype=all&sektion=devel See http://code.google.com/p/papi-for-freebsd/wiki/HowToInstall for installation instructions. There are some issues with P4 processors that need to be fixed on PAPI_write / PAPI_reset routines, but the package have the minimal (and most important functionality) working fine for the rest of the substrates. Regards, -- _________________________________________________________________ Empty your memory, with a free()... like a pointer! If you cast a pointer to an integer, it becomes an integer, if you cast a pointer to a struct, it becomes a struct. The pointer can crash..., and can overflow. Be a pointer my friend... From owner-freebsd-performance@FreeBSD.ORG Thu Jun 14 10:18:23 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 281AB16A400 for ; Thu, 14 Jun 2007 10:18:23 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from mail02.solnet.ch (mail02.solnet.ch [212.101.4.136]) by mx1.freebsd.org (Postfix) with ESMTP id E1EAF13C43E for ; Thu, 14 Jun 2007 10:18:22 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) X-Virus-Scanned: by amavisd-new at mail02.solnet.ch Received: from mail02.solnet.ch ([127.0.0.1]) by localhost (mail02.solnet.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id K3tKhokKrnoI; Thu, 14 Jun 2007 10:00:47 +0000 (UTC) Received: from 192.168.1.102.local.home (home.bsdunix.ch [82.220.17.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail02.solnet.ch (Postfix) with ESMTP id A43C884A0A; Thu, 14 Jun 2007 10:00:47 +0000 (UTC) Message-ID: <4671118D.1040404@bsdunix.ch> Date: Thu, 14 Jun 2007 11:59:41 +0200 From: Thomas Vogt User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Harald Servat References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org Subject: Re: PAPI in the ports X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 10:18:23 -0000 Hi Thats sounds nice. You wrote "The goal of the PmcTools project is to provide FreeBSD's developers and system administrators with non-intrusive, low-overhead and innovative ways of measuring and analysing system performance" your website. Have you ever measured the performance impact of such tools? I'm interested to run such tool on production machines in the future but only if the performance impact isn't that high. Regards, Thomas Harald Servat wrote: > Hello, > > I'm glad to announce you that PAPI-3.5.0 has reached the FreeBSD ports > tree and now it's generally available for all FreeBSD users. > > Port information is available at > http://www.freebsd.org/cgi/ports.cgi?query=papi&stype=all&sektion=devel > > See http://code.google.com/p/papi-for-freebsd/wiki/HowToInstall for > installation instructions. > > There are some issues with P4 processors that need to be fixed on > PAPI_write / PAPI_reset routines, but the package have the minimal (and > most > important functionality) working fine for the rest of the substrates. > > Regards, From owner-freebsd-performance@FreeBSD.ORG Thu Jun 14 10:20:35 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE6BD16A468 for ; Thu, 14 Jun 2007 10:20:35 +0000 (UTC) (envelope-from redcrash@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.freebsd.org (Postfix) with ESMTP id 8E18613C457 for ; Thu, 14 Jun 2007 10:20:35 +0000 (UTC) (envelope-from redcrash@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so122400anc for ; Thu, 14 Jun 2007 03:20:34 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=tkHR5ACA1hBAsNSWx75zeaTtE/ovF6Y1lmz4m37dKEbXhACg/R7ynlRJFsuhbK/E54JTLha3ZnSbh4yg/ltmnDM2U1C9maGy5oHUlQOGktxm1uNFD+mioTL19ofPaf7HD9JjGLY2UZ30Ovu+jLRUTJajKu8QmW1p3UT7q+699Ds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=IQKHbIUbCn99iKlnWPQ5CetNArTcSxi7wX18CuPyHFMB6tHCQ5zDZwmEjPEQPajjNCfFexBBt3GegbxY9suvfDXtfke+tZydywg/sBaHHw7wc+BoBuVTYonOmeQ/6wKJfg5njT5m0xajD8+i9eVsgmKP6y81kEpppUfZHZns40g= Received: by 10.100.141.13 with SMTP id o13mr1002122and.1181816434864; Thu, 14 Jun 2007 03:20:34 -0700 (PDT) Received: by 10.100.141.3 with HTTP; Thu, 14 Jun 2007 03:20:34 -0700 (PDT) Message-ID: Date: Thu, 14 Jun 2007 12:20:34 +0200 From: "Harald Servat" To: "Thomas Vogt" In-Reply-To: <4671118D.1040404@bsdunix.ch> MIME-Version: 1.0 References: <4671118D.1040404@bsdunix.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-performance@freebsd.org Subject: Re: PAPI in the ports X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 10:20:35 -0000 Hello, 2007/6/14, Thomas Vogt : > > Hi > > Thats sounds nice. You wrote "The goal of the PmcTools project is to > provide FreeBSD's developers and system administrators with > non-intrusive, low-overhead and innovative ways of measuring and > analysing system performance" your website. Have you ever measured the > performance impact of such tools? No, I didn't, I just did the port. But maybe Joseph Koshy (who is the author of PMCTools) has measurements of the PMC library on different machines/environments. See http://wiki.freebsd.org/PmcTools or contact him directly. The port itself is based directly on the PMCtools (i.e. it's almost a wrapper to convert PAPI calls into PMC calls), so I don't think that PAPI adds too much overhead to this basic library. I'm interested to run such tool on production machines in the future but > only if the performance impact isn't that high. > > Regards, > Thomas > > Harald Servat wrote: > > Hello, > > > > I'm glad to announce you that PAPI-3.5.0 has reached the FreeBSD ports > > tree and now it's generally available for all FreeBSD users. > > > > Port information is available at > > http://www.freebsd.org/cgi/ports.cgi?query=papi&stype=all&sektion=devel > > > > See http://code.google.com/p/papi-for-freebsd/wiki/HowToInstall for > > installation instructions. > > > > There are some issues with P4 processors that need to be fixed on > > PAPI_write / PAPI_reset routines, but the package have the minimal (and > > most > > important functionality) working fine for the rest of the substrates. > > > > Regards, > Regards, -- _________________________________________________________________ Empty your memory, with a free()... like a pointer! If you cast a pointer to an integer, it becomes an integer, if you cast a pointer to a struct, it becomes a struct. The pointer can crash..., and can overflow. Be a pointer my friend... From owner-freebsd-performance@FreeBSD.ORG Thu Jun 14 11:07:26 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA12116A468 for ; Thu, 14 Jun 2007 11:07:26 +0000 (UTC) (envelope-from tec@mega.net.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 68BBC13C483 for ; Thu, 14 Jun 2007 11:07:26 +0000 (UTC) (envelope-from tec@mega.net.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l5EB7QE4081106 for ; Thu, 14 Jun 2007 08:07:26 -0300 (BRT) (envelope-from tec@mega.net.br) From: NOC Meganet Organization: Prowip Telecom Ltda To: freebsd-performance@freebsd.org Date: Thu, 14 Jun 2007 08:06:05 -0300 User-Agent: KMail/1.9.6 References: <4671118D.1040404@bsdunix.ch> In-Reply-To: <4671118D.1040404@bsdunix.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200706140806.05674.tec@mega.net.br> X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on msrv.matik.com.br X-Virus-Status: Clean Subject: Re: PAPI in the ports X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 11:07:26 -0000 On Thursday 14 June 2007 06:59:41 Thomas Vogt wrote: > Hi > > Thats sounds nice. You wrote "The goal of the PmcTools project is to > provide FreeBSD's developers and system administrators with > non-intrusive, low-overhead and innovative ways of measuring and > analysing system performance" your website. Have you ever measured the > performance impact of such tools? > > I'm interested to run such tool on production machines in the future but > only if the performance impact isn't that high. > Hi ... even if the tool (whatever it is) does not require much system resources it triggers processes in order to measure their or the system's performance. So long as you do not push the system to or over the edge you might not get valuable numbers. So I mean, any performance measuring does or must stress the system. That is at least my understanding. So probably running performance tests on a production server is not the very best idea. HM -- Prowip Telecom Ltda AS 22706 A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-performance@FreeBSD.ORG Thu Jun 14 11:47:44 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 87B5E16A41F for ; Thu, 14 Jun 2007 11:47:44 +0000 (UTC) (envelope-from thomas@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 4CE5D13C480 for ; Thu, 14 Jun 2007 11:47:44 +0000 (UTC) (envelope-from thomas@bsdunix.ch) Received: from localhost (localhost.bsdunix.ch [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id 48C1C5DBB; Thu, 14 Jun 2007 13:29:01 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GWfIvxWqjTgY; Thu, 14 Jun 2007 13:29:00 +0200 (CEST) Received: from 192.168.1.102.local.home (home.bsdunix.ch [82.220.17.23]) by conversation.bsdunix.ch (Postfix) with ESMTP id 45A595DB1; Thu, 14 Jun 2007 13:29:00 +0200 (CEST) Message-ID: <46712605.5090907@bsdunix.ch> Date: Thu, 14 Jun 2007 13:27:01 +0200 From: Thomas Vogt User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: NOC Meganet References: <4671118D.1040404@bsdunix.ch> <200706140806.05674.tec@mega.net.br> In-Reply-To: <200706140806.05674.tec@mega.net.br> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 14 Jun 2007 11:55:29 +0000 Cc: freebsd-performance@freebsd.org Subject: Re: PAPI in the ports X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 11:47:44 -0000 Hi NOC Meganet wrote: > On Thursday 14 June 2007 06:59:41 Thomas Vogt wrote: >> Hi >> >> Thats sounds nice. You wrote "The goal of the PmcTools project is to >> provide FreeBSD's developers and system administrators with >> non-intrusive, low-overhead and innovative ways of measuring and >> analysing system performance" your website. Have you ever measured the >> performance impact of such tools? >> >> I'm interested to run such tool on production machines in the future but >> only if the performance impact isn't that high. >> > > Hi > ... even if the tool (whatever it is) does not require much system resources > it triggers processes in order to measure their or the system's performance. > So long as you do not push the system to or over the edge you might not get > valuable numbers. So I mean, any performance measuring does or must stress > the system. That is at least my understanding. So probably running > performance tests on a production server is not the very best idea. Yes you're right. But to have a such feature on a production system is nice if you have to debug issues. If I get a problem I can easily debug it without to simulate everything in the lab. It's not that I want to run such features 24/7. But perhaps "options HWPMC_HOOKS" in the kernel enables some hooks which could cause performance penalties even if I don't actively use such feature very often. Like many other debug options in the kernel. I don't know. Regards, Tom From owner-freebsd-performance@FreeBSD.ORG Thu Jun 14 12:38:28 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A7FE16A46F for ; Thu, 14 Jun 2007 12:38:28 +0000 (UTC) (envelope-from tec@mega.net.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 286A113C4D0 for ; Thu, 14 Jun 2007 12:38:27 +0000 (UTC) (envelope-from tec@mega.net.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l5ECcRZo088562; Thu, 14 Jun 2007 09:38:28 -0300 (BRT) (envelope-from tec@mega.net.br) From: NOC Meganet Organization: Prowip Telecom Ltda To: freebsd-performance@freebsd.org Date: Thu, 14 Jun 2007 09:36:55 -0300 User-Agent: KMail/1.9.6 References: <20070614084817.GA81087@rot13.obsecurity.org> In-Reply-To: <20070614084817.GA81087@rot13.obsecurity.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200706140936.55916.tec@mega.net.br> X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on msrv.matik.com.br X-Virus-Status: Clean Cc: smp@freebsd.org, performance@freebsd.org, Kris Kennaway Subject: Re: BIND 9.4.1 performance on FreeBSD 6.2 vs. 7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 12:38:28 -0000 On Thursday 14 June 2007 05:48:17 Kris Kennaway wrote: > 6.2 was used from CVS with libthr and the 4BSD scheduler (ULE 1.0 is > broken in 6.x). just curious what is broken because I use ULE on several servers perfectly. it seems to me that ULE is even faster on SMP when not having heavy load. Also "calcru went backwards" issues I do not get with ULE but sporadically on 4BSD scheduler kernels, specially on dualcore cpus. HM -- Prowip Telecom Ltda AS 22706 A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-performance@FreeBSD.ORG Thu Jun 14 13:55:48 2007 Return-Path: X-Original-To: performance@freebsd.org Delivered-To: freebsd-performance@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F8F816A46B; Thu, 14 Jun 2007 13:55:48 +0000 (UTC) (envelope-from tec@mega.net.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 1710513C480; Thu, 14 Jun 2007 13:55:47 +0000 (UTC) (envelope-from tec@mega.net.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l5ECcRZo088562; Thu, 14 Jun 2007 09:38:28 -0300 (BRT) (envelope-from tec@mega.net.br) From: NOC Meganet Organization: Prowip Telecom Ltda To: freebsd-performance@freebsd.org Date: Thu, 14 Jun 2007 09:36:55 -0300 User-Agent: KMail/1.9.6 References: <20070614084817.GA81087@rot13.obsecurity.org> In-Reply-To: <20070614084817.GA81087@rot13.obsecurity.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200706140936.55916.tec@mega.net.br> X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on msrv.matik.com.br X-Virus-Status: Clean Cc: smp@freebsd.org, performance@freebsd.org, Kris Kennaway Subject: Re: BIND 9.4.1 performance on FreeBSD 6.2 vs. 7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 13:55:48 -0000 On Thursday 14 June 2007 05:48:17 Kris Kennaway wrote: > 6.2 was used from CVS with libthr and the 4BSD scheduler (ULE 1.0 is > broken in 6.x). just curious what is broken because I use ULE on several servers perfectly. it seems to me that ULE is even faster on SMP when not having heavy load. Also "calcru went backwards" issues I do not get with ULE but sporadically on 4BSD scheduler kernels, specially on dualcore cpus. HM -- Prowip Telecom Ltda AS 22706 A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-performance@FreeBSD.ORG Thu Jun 14 18:09:42 2007 Return-Path: X-Original-To: performance@freebsd.org Delivered-To: freebsd-performance@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A6E7C16A46B; Thu, 14 Jun 2007 18:09:42 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 90F1513C465; Thu, 14 Jun 2007 18:09:42 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id EB8EF1A4D84; Thu, 14 Jun 2007 11:09:13 -0700 (PDT) Received: from rot13.obsecurity.org (rot13.obsecurity.org [192.168.1.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id CF4D7513AE; Thu, 14 Jun 2007 14:09:41 -0400 (EDT) Received: by rot13.obsecurity.org (Postfix, from userid 1001) id 7353CBE89; Thu, 14 Jun 2007 14:09:41 -0400 (EDT) Date: Thu, 14 Jun 2007 14:09:41 -0400 From: Kris Kennaway To: NOC Meganet Message-ID: <20070614180941.GA88451@rot13.obsecurity.org> References: <20070614084817.GA81087@rot13.obsecurity.org> <200706140936.55916.tec@mega.net.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706140936.55916.tec@mega.net.br> User-Agent: Mutt/1.4.2.3i Cc: freebsd-performance@freebsd.org, performance@freebsd.org, smp@freebsd.org, Kris Kennaway Subject: Re: BIND 9.4.1 performance on FreeBSD 6.2 vs. 7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 18:09:42 -0000 On Thu, Jun 14, 2007 at 09:36:55AM -0300, NOC Meganet wrote: > On Thursday 14 June 2007 05:48:17 Kris Kennaway wrote: > > 6.2 was used from CVS with libthr and the 4BSD scheduler (ULE 1.0 is > > broken in 6.x). > > just curious what is broken because I use ULE on several servers perfectly. it > seems to me that ULE is even faster on SMP when not having heavy load. > Also "calcru went backwards" issues I do not get with ULE but sporadically on > 4BSD scheduler kernels, specially on dualcore cpus. ULE on 6.x and is known to have severe performance problems in some workloads, as well as bugs that cause it to crash. Use it at your own peril :) Kris From owner-freebsd-performance@FreeBSD.ORG Thu Jun 14 18:09:42 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A6E7C16A46B; Thu, 14 Jun 2007 18:09:42 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 90F1513C465; Thu, 14 Jun 2007 18:09:42 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id EB8EF1A4D84; Thu, 14 Jun 2007 11:09:13 -0700 (PDT) Received: from rot13.obsecurity.org (rot13.obsecurity.org [192.168.1.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id CF4D7513AE; Thu, 14 Jun 2007 14:09:41 -0400 (EDT) Received: by rot13.obsecurity.org (Postfix, from userid 1001) id 7353CBE89; Thu, 14 Jun 2007 14:09:41 -0400 (EDT) Date: Thu, 14 Jun 2007 14:09:41 -0400 From: Kris Kennaway To: NOC Meganet Message-ID: <20070614180941.GA88451@rot13.obsecurity.org> References: <20070614084817.GA81087@rot13.obsecurity.org> <200706140936.55916.tec@mega.net.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706140936.55916.tec@mega.net.br> User-Agent: Mutt/1.4.2.3i Cc: freebsd-performance@freebsd.org, performance@freebsd.org, smp@freebsd.org, Kris Kennaway Subject: Re: BIND 9.4.1 performance on FreeBSD 6.2 vs. 7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 18:09:42 -0000 On Thu, Jun 14, 2007 at 09:36:55AM -0300, NOC Meganet wrote: > On Thursday 14 June 2007 05:48:17 Kris Kennaway wrote: > > 6.2 was used from CVS with libthr and the 4BSD scheduler (ULE 1.0 is > > broken in 6.x). > > just curious what is broken because I use ULE on several servers perfectly. it > seems to me that ULE is even faster on SMP when not having heavy load. > Also "calcru went backwards" issues I do not get with ULE but sporadically on > 4BSD scheduler kernels, specially on dualcore cpus. ULE on 6.x and is known to have severe performance problems in some workloads, as well as bugs that cause it to crash. Use it at your own peril :) Kris From owner-freebsd-performance@FreeBSD.ORG Thu Jun 14 21:00:05 2007 Return-Path: X-Original-To: performance@freebsd.org Delivered-To: freebsd-performance@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2883F16A46F for ; Thu, 14 Jun 2007 21:00:05 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from virtual.micronet.sk (smtp.micronet.sk [84.16.32.237]) by mx1.freebsd.org (Postfix) with ESMTP id D629D13C46E for ; Thu, 14 Jun 2007 21:00:04 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by virtual.micronet.sk (Postfix) with ESMTP id 223C610E657; Thu, 14 Jun 2007 22:26:31 +0200 (CEST) X-Virus-Scanned: by amavisd-new at virtual.micronet.sk Received: from virtual.micronet.sk ([127.0.0.1]) by localhost (virtual.micronet.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOx5N803RXyd; Thu, 14 Jun 2007 22:26:28 +0200 (CEST) Received: from [10.50.0.2] (danger.mcrn.sk [84.16.37.254]) by virtual.micronet.sk (Postfix) with ESMTP id DC52F10E665; Thu, 14 Jun 2007 22:26:27 +0200 (CEST) Date: Thu, 14 Jun 2007 22:27:47 +0200 From: Daniel Gerzo Organization: The FreeBSD Project X-Priority: 3 (Normal) Message-ID: <2410282290.20070614222747@rulez.sk> To: Jeff Roberson In-Reply-To: <20070613133712.C60816@10.0.0.1> References: <20070613133712.C60816@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: performance@freebsd.org Subject: Re: Call for testers, amd64 only, new scheduler. (fwd) X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Gerzo List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 21:00:05 -0000 Hello Jeff, Wednesday, June 13, 2007, 10:37:44 PM, you wrote: > I'm forwarding this email that I sent to current@ in the hopes that some > performance minded people will tell me their results with this new > scheduler infrastructure. Just a quick and maybe silly question: Why does it pefrofms worser than 7.0+contension (don't know what it really means) with a bigger concurrency limit? -- Best regards, Daniel mailto:danger@FreeBSD.org From owner-freebsd-performance@FreeBSD.ORG Fri Jun 15 00:03:21 2007 Return-Path: X-Original-To: performance@FreeBSD.org Delivered-To: freebsd-performance@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A66BD16A479; Fri, 15 Jun 2007 00:03:21 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 8EF3A13C4AE; Fri, 15 Jun 2007 00:03:21 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id BFDD11A3C1A; Thu, 14 Jun 2007 17:02:51 -0700 (PDT) Received: from rot13.obsecurity.org (rot13.obsecurity.org [192.168.1.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 92327513AE; Thu, 14 Jun 2007 20:03:20 -0400 (EDT) Received: by rot13.obsecurity.org (Postfix, from userid 1001) id 36814BEC4; Thu, 14 Jun 2007 20:03:20 -0400 (EDT) Date: Thu, 14 Jun 2007 20:03:20 -0400 From: Kris Kennaway To: Chuck Swiger Message-ID: <20070615000320.GA94458@rot13.obsecurity.org> References: <20070614084817.GA81087@rot13.obsecurity.org> <449EAA15-A4BC-4AAE-B3ED-B65E7A079877@mac.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: <449EAA15-A4BC-4AAE-B3ED-B65E7A079877@mac.com> User-Agent: Mutt/1.4.2.3i Cc: smp@FreeBSD.org, performance@FreeBSD.org, current@FreeBSD.org, Kris Kennaway Subject: Re: BIND 9.4.1 performance on FreeBSD 6.2 vs. 7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2007 00:03:21 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 14, 2007 at 04:53:01PM -0700, Chuck Swiger wrote: > Hi, Kris-- >=20 > This was interesting, thanks for putting together the testing and =20 > graphs. >=20 > On Jun 14, 2007, at 1:48 AM, Kris Kennaway wrote: > >I have been benchmarking BIND 9.4.1 recursive query performance on an > >8-core opteron, using the resperf utility (dns/dnsperf in ports). The > >query data set was taken from www.freebsd.org's httpd-access.log with > >some of the highly aggressive robot IP addresses pruned out (to avoid > >huge numbers of repeated queries against a small subset of addresses, > >which would skew the results). >=20 > It's at least arguable that doing queries against a data set =20 > including a bunch of repeats is "skewed" in a more realistic =20 > fashion. :-) A quick look at some of the data sources I have handy =20 > such as http access logs or Squid proxy logs suggests that (for =20 > example) out of a database of 17+ million requests, there were only =20 > 46000 unique IPs involved. There were still lots of repeats, just some of them were repeated hundreds of thousands of times - I stripped about a dozen of those (googlebots, I'm looking at you ;-), leaving a distribution that was less biased to the top end. > You might find it interesting to compare doing queries against your =20 > raw and filtered datasets, just to see what kind of difference you =20 > get, if any. Cached queries perform much better, as you might expect. As an estimate I was getting query rates exceeding 120000 qps when serving entirely out of cache, and I dont think I reached the upper bound yet. > >Testing was done over a broadcom gigabit ethernet cable connected > >back-to-back between two identical machines. named was restarted in > >between tests to flush the cache. >=20 > What was the external network connectivity in terms of speed? The =20 > docs suggest you need something like a 16MBs up/8 Mbs down =20 > connectivity in order to get up to 50K requests/sec.... I wasn't seeing anything close to this, so I guess it depends how much data is being returned by the queries (I was doing PTR lookups). I forget the exact numbers but it wasn't exceeding about 10Mbit in both directions, which should have been well within link capacity. Also the lock profiling data bears out the interpretation that it was BIND that was becoming saturated and not the hardware. > [ ... ] > >It would be interesting to test BIND performance when acting as an > >authoritative server, which probably has very different performance > >characteristics; the difficulty there is getting access to a suitably > >interesting and representative zone file and query data. >=20 > I suppose you could also set up a test nameserver which claims to be =20 > authoritative for all of in-addr.arpa, and set up a bunch (65K?) /16 =20 > reverse zone files, and then test against real unmodified IPs, but it =20 > would be easier to do something like this: >=20 > Set up a nameserver which is authoritative for 1.10.in-addr.arpa (ie, =20 > the reverse zone for 10.1/16), and use a zonefile with the $GENERATE =20 > directive to populate your PTR records: >=20 > $TTL 86400 > $origin 1.10.in-addr.arpa. >=20 > @ IN SOA localhost. hostmaster.localhost. ( > 1 ; serial (YYYYMMDD##) > 3h ; Refresh 3 hours > 1h ; Retry 1 hour > 30d ; Expire 30 days > 1d ) ; Minimum 24 hours >=20 > @ NS localhost. >=20 > $GENERATE 0-255 $.0 PTR ip-10-1-0-$.example.com. > $GENERATE 0-255 $.1 PTR ip-10-1-1-$.example.org. > $GENERATE 0-255 $.2 PTR ip-10-1-2-$.example.net. > ; ...etc... >=20 > ...and then feed it a query database consisting of PTR lookups. If =20 > you wanted to, you could take your existing IP database, and glue the =20 > last two octets of the real IPs onto 10.1 to produce a reasonable =20 > assortment of IPs to perform a reverse lookup upon. I could construct something like this but I'd prefer a more "realistic" workload (i.e. an uneven distribution of queries against different subsets of the data). I don't have a good idea what "realistic" means here, which makes it hard to construct one from scratch. Fortunately I have an offer from someone for access to a real large zone file and a large sample of queries. Kris --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGcddHWry0BWjoQKURAm5SAJ0WNKEKSmWAeDvbLVZDsYGGtyT9QQCgt/Rl imFuDyK59RuNiN+tPJ4C8/Q= =c16C -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From owner-freebsd-performance@FreeBSD.ORG Fri Jun 15 00:08:06 2007 Return-Path: X-Original-To: performance@FreeBSD.org Delivered-To: freebsd-performance@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A11DD16A473; Fri, 15 Jun 2007 00:08:06 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.freebsd.org (Postfix) with ESMTP id 87A1213C468; Fri, 15 Jun 2007 00:08:06 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out3.apple.com (Postfix) with ESMTP id 8CBCB8DDBEC; Thu, 14 Jun 2007 16:51:52 -0700 (PDT) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 3E8DD4008B; Thu, 14 Jun 2007 16:53:02 -0700 (PDT) X-AuditID: 11807126-a1339bb000002ff2-ff-4671d4deddef Received: from [17.214.13.96] (cswiger1.apple.com [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay8.apple.com (Apple SCV relay) with ESMTP id 1571E4005A; Thu, 14 Jun 2007 16:53:02 -0700 (PDT) In-Reply-To: <20070614084817.GA81087@rot13.obsecurity.org> References: <20070614084817.GA81087@rot13.obsecurity.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <449EAA15-A4BC-4AAE-B3ED-B65E7A079877@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Thu, 14 Jun 2007 16:53:01 -0700 To: Kris Kennaway X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: smp@FreeBSD.org, performance@FreeBSD.org, current@FreeBSD.org Subject: Re: BIND 9.4.1 performance on FreeBSD 6.2 vs. 7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2007 00:08:06 -0000 Hi, Kris-- This was interesting, thanks for putting together the testing and graphs. On Jun 14, 2007, at 1:48 AM, Kris Kennaway wrote: > I have been benchmarking BIND 9.4.1 recursive query performance on an > 8-core opteron, using the resperf utility (dns/dnsperf in ports). The > query data set was taken from www.freebsd.org's httpd-access.log with > some of the highly aggressive robot IP addresses pruned out (to avoid > huge numbers of repeated queries against a small subset of addresses, > which would skew the results). It's at least arguable that doing queries against a data set including a bunch of repeats is "skewed" in a more realistic fashion. :-) A quick look at some of the data sources I have handy such as http access logs or Squid proxy logs suggests that (for example) out of a database of 17+ million requests, there were only 46000 unique IPs involved. You might find it interesting to compare doing queries against your raw and filtered datasets, just to see what kind of difference you get, if any. > Testing was done over a broadcom gigabit ethernet cable connected > back-to-back between two identical machines. named was restarted in > between tests to flush the cache. What was the external network connectivity in terms of speed? The docs suggest you need something like a 16MBs up/8 Mbs down connectivity in order to get up to 50K requests/sec.... [ ... ] > It would be interesting to test BIND performance when acting as an > authoritative server, which probably has very different performance > characteristics; the difficulty there is getting access to a suitably > interesting and representative zone file and query data. I suppose you could also set up a test nameserver which claims to be authoritative for all of in-addr.arpa, and set up a bunch (65K?) /16 reverse zone files, and then test against real unmodified IPs, but it would be easier to do something like this: Set up a nameserver which is authoritative for 1.10.in-addr.arpa (ie, the reverse zone for 10.1/16), and use a zonefile with the $GENERATE directive to populate your PTR records: $TTL 86400 $origin 1.10.in-addr.arpa. @ IN SOA localhost. hostmaster.localhost. ( 1 ; serial (YYYYMMDD##) 3h ; Refresh 3 hours 1h ; Retry 1 hour 30d ; Expire 30 days 1d ) ; Minimum 24 hours @ NS localhost. $GENERATE 0-255 $.0 PTR ip-10-1-0-$.example.com. $GENERATE 0-255 $.1 PTR ip-10-1-1-$.example.org. $GENERATE 0-255 $.2 PTR ip-10-1-2-$.example.net. ; ...etc... ...and then feed it a query database consisting of PTR lookups. If you wanted to, you could take your existing IP database, and glue the last two octets of the real IPs onto 10.1 to produce a reasonable assortment of IPs to perform a reverse lookup upon. -- -Chuck From owner-freebsd-performance@FreeBSD.ORG Fri Jun 15 00:26:06 2007 Return-Path: X-Original-To: performance@FreeBSD.org Delivered-To: freebsd-performance@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A2FC16A400; Fri, 15 Jun 2007 00:26:06 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.freebsd.org (Postfix) with ESMTP id 6FA5813C45A; Fri, 15 Jun 2007 00:26:06 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay7.apple.com (relay7.apple.com [17.128.113.37]) by mail-out3.apple.com (Postfix) with ESMTP id 864088DE567; Thu, 14 Jun 2007 17:24:56 -0700 (PDT) Received: from relay7.apple.com (unknown [127.0.0.1]) by relay7.apple.com (Symantec Mail Security) with ESMTP id 4323630076; Thu, 14 Jun 2007 17:26:06 -0700 (PDT) X-AuditID: 11807125-9ff64bb000000801-ce-4671dc9e5429 Received: from [17.214.13.96] (cswiger1.apple.com [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay7.apple.com (Apple SCV relay) with ESMTP id 1818530041; Thu, 14 Jun 2007 17:26:06 -0700 (PDT) In-Reply-To: <20070615000320.GA94458@rot13.obsecurity.org> References: <20070614084817.GA81087@rot13.obsecurity.org> <449EAA15-A4BC-4AAE-B3ED-B65E7A079877@mac.com> <20070615000320.GA94458@rot13.obsecurity.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A845D91-435E-4F1C-A05A-270A04DAC20E@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Thu, 14 Jun 2007 17:26:05 -0700 To: Kris Kennaway X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: smp@FreeBSD.org, performance@FreeBSD.org, current@FreeBSD.org Subject: Re: BIND 9.4.1 performance on FreeBSD 6.2 vs. 7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2007 00:26:06 -0000 On Jun 14, 2007, at 5:03 PM, Kris Kennaway wrote: >> It's at least arguable that doing queries against a data set >> including a bunch of repeats is "skewed" in a more realistic >> fashion. :-) A quick look at some of the data sources I have handy >> such as http access logs or Squid proxy logs suggests that (for >> example) out of a database of 17+ million requests, there were only >> 46000 unique IPs involved. > > There were still lots of repeats, just some of them were repeated > hundreds of thousands of times - I stripped about a dozen of those > (googlebots, I'm looking at you ;-), leaving a distribution that was > less biased to the top end. Heh, yes, it's surprising how happy a webspider is to crawl around a heavily-interlinked site. :-) Perhaps someone ought to add a: Crawl-delay: 600 ...statement to http://www.freebsd.org/robots.txt...? >> You might find it interesting to compare doing queries against your >> raw and filtered datasets, just to see what kind of difference you >> get, if any. > > Cached queries perform much better, as you might expect. As an > estimate I was getting query rates exceeding 120000 qps when serving > entirely out of cache, and I dont think I reached the upper bound yet. Sure, anything cached or anything the nameserver is authoritative for is going to be directly answerable without having to do an external recursive query. >> What was the external network connectivity in terms of speed? The >> docs suggest you need something like a 16MBs up/8 Mbs down >> connectivity in order to get up to 50K requests/sec.... > > I wasn't seeing anything close to this, so I guess it depends how much > data is being returned by the queries (I was doing PTR lookups). I > forget the exact numbers but it wasn't exceeding about 10Mbit in both > directions, which should have been well within link capacity. Also > the lock profiling data bears out the interpretation that it was BIND > that was becoming saturated and not the hardware. OK, thanks for the info. Maybe I'll get a chance to run some numbers of my own testing, if I can free up some time from WWDC.... >> [ ... ] >>> It would be interesting to test BIND performance when acting as an >>> authoritative server, which probably has very different performance >>> characteristics; the difficulty there is getting access to a >>> suitably >>> interesting and representative zone file and query data. >> >> I suppose you could also set up a test nameserver which claims to be >> authoritative for all of in-addr.arpa, and set up a bunch (65K?) /16 >> reverse zone files, and then test against real unmodified IPs, but it >> would be easier to do something like this: >> >> Set up a nameserver which is authoritative for 1.10.in-addr.arpa (ie, >> the reverse zone for 10.1/16), and use a zonefile with the $GENERATE >> directive to populate your PTR records: >> >> [ ...zonefile snipped for brevity... ] >> >> ...and then feed it a query database consisting of PTR lookups. If >> you wanted to, you could take your existing IP database, and glue the >> last two octets of the real IPs onto 10.1 to produce a reasonable >> assortment of IPs to perform a reverse lookup upon. > > I could construct something like this but I'd prefer a more > "realistic" workload (i.e. an uneven distribution of queries against > different subsets of the data). I don't have a good idea what > "realistic" means here, which makes it hard to construct one from > scratch. Fortunately I have an offer from someone for access to a > real large zone file and a large sample of queries. Ah, very good, then. While I expect there to be quite a difference between recursive queries vs. authoritative/locally answerable queries (after all, that seems to be why both dnsperf and resperf were created as distinct programs), I'm not convinced that there is too much difference between doing reverse lookups for one set of IPs versus another if those IPs are all in zones the server is authoritative for. -- -Chuck From owner-freebsd-performance@FreeBSD.ORG Fri Jun 15 07:25:00 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4DC3016A469 for ; Fri, 15 Jun 2007 07:25:00 +0000 (UTC) (envelope-from patpro@patpro.net) Received: from smtp.univ-lyon2.fr (smtp.univ-lyon2.fr [159.84.143.102]) by mx1.freebsd.org (Postfix) with ESMTP id D497413C458 for ; Fri, 15 Jun 2007 07:24:59 +0000 (UTC) (envelope-from patpro@patpro.net) Received: from localhost (localhost [127.0.0.1]) by smtp.univ-lyon2.fr (Postfix) with ESMTP id 4A01A37BBD4C for ; Fri, 15 Jun 2007 09:24:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at univ-lyon2.fr Received: from smtp.univ-lyon2.fr ([127.0.0.1]) by localhost (smtp.univ-lyon2.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxiKDKOwPTSE for ; Fri, 15 Jun 2007 09:24:56 +0200 (CEST) Received: from [159.84.148.60] (patpro.univ-lyon2.fr [159.84.148.60]) by smtp.univ-lyon2.fr (Postfix) with ESMTP id 720D837BBD41 for ; Fri, 15 Jun 2007 09:24:56 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <8A81ECB9-67EB-4E4D-A26A-8221D52463AA@patpro.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-performance@freebsd.org From: Patrick Proniewski Date: Fri, 15 Jun 2007 09:24:47 +0200 X-Mailer: Apple Mail (2.752.2) Subject: wifi network performance with ath0 and hostapd X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2007 07:25:00 -0000 Hello, I've setup a little WLAN at home, using my freebsd box as an access point: - FreeBSD 6.2 (tag=RELENG_6_2) - DLink DWL-G520 PCI card (Atheros chipset) - hostapd configured with WPA The "client" is a powerbook G4 (Built-in 54-Mbps Wi-Fi, certified for 802.11g and 802.11b interoperability) running Mac OS X 10.4.9 The powerbook is 1.5 meters away from the Dlink antena, and ath0 is in "mode 11g" and "pureg". The best transfer rate I can achieve is 3.1 MB/s from the powerbook to the freebsd-box, and about 2.7 MB/s from the freebsd-box to the powerbook. Any idea how I could boost my transfer rates ? thanks, patpro -- $ ifconfig ath0 ath0: flags=8843 mtu 2290 inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:19:5b:ca:31:3a media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ssid boleskine channel 2 bssid 00:19:5b:ca:31:3a authmode WPA privacy MIXED deftxkey 3 TKIP 2:128-bit TKIP 3:128-bit txpowmax 36 bmiss 7 pureg protmode CTS burst dtimperiod 1 bintval 100 $ wicontrol -i ath0 NIC serial number: [ ] Station name: [ ****.*******.** ] SSID for IBSS creation: [ boleskine ] Current netname (SSID): [ boleskine ] Desired netname (SSID): [ boleskine ] Current BSSID: [ 00:19:5b:ca:31:3a ] Channel list: [ 3ffe ] IBSS channel: [ 2 ] Current channel: [ 2 ] Comms quality/signal/noise: [ 0 4 0 ] Promiscuous mode: [ Off ] Intersil-Prism2 based card: [ 1 ] Port type (1=BSS, 3=ad-hoc): [ 6 ] MAC address: [ 00:19:5b:ca:31:3a ] TX rate (selection): [ 0 ] TX rate (actual speed): [ 36 ] RTS/CTS handshake threshold: [ 2346 ] Create IBSS: [ Off ] Access point density: [ 1 ] Power Mgmt (1=on, 0=off): [ 0 ] Max sleep time: [ 100 ] WEP encryption: [ On ] TX encryption key: [ 3 ] Encryption keys: [ ][ ][ ][ ] $ dmesg | grep -i ath ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0xd8120000-0xd812ffff irq 21 at device 5.0 on pci6 ath0: Ethernet address: 00:19:5b:ca:31:3a ath0: mac 7.9 phy 4.5 radio 5.6 $ kldstat Id Refs Address Size Name 1 18 0xc0400000 3ae6d4 kernel 2 1 0xc07af000 fbc0 if_ath.ko 3 3 0xc07bf000 312f8 ath_hal.ko 4 8 0xc07f1000 1d7e4 wlan.ko 5 2 0xc080f000 3f18 ath_rate.ko 6 1 0xc0813000 a9d4 cpufreq.ko 7 1 0xc081e000 2d08 wlan_wep.ko 8 1 0xc0821000 4000 wlan_tkip.ko 9 1 0xc0825000 6d04 wlan_ccmp.ko 10 1 0xc082c000 1b10 wlan_xauth.ko 11 1 0xc082e000 2c54 wlan_acl.ko 12 1 0xc0831000 59e80 acpi.ko 13 1 0xc51d7000 2000 pflog.ko 14 1 0xc51e3000 2a000 pf.ko 15 1 0xc53c4000 2000 green_saver.ko From owner-freebsd-performance@FreeBSD.ORG Fri Jun 15 16:32:37 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C27016A41F for ; Fri, 15 Jun 2007 16:32:37 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 15A2D13C4BF for ; Fri, 15 Jun 2007 16:32:37 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l5FGIqiJ016516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jun 2007 09:18:52 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4672BC15.9090904@errno.com> Date: Fri, 15 Jun 2007 09:19:33 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.0 (X11/20070530) MIME-Version: 1.0 To: Patrick Proniewski References: <8A81ECB9-67EB-4E4D-A26A-8221D52463AA@patpro.net> In-Reply-To: <8A81ECB9-67EB-4E4D-A26A-8221D52463AA@patpro.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org Subject: Re: wifi network performance with ath0 and hostapd X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2007 16:32:37 -0000 Patrick Proniewski wrote: > Hello, > > I've setup a little WLAN at home, using my freebsd box as an access point: > - FreeBSD 6.2 (tag=RELENG_6_2) > - DLink DWL-G520 PCI card (Atheros chipset) > - hostapd configured with WPA > > The "client" is a powerbook G4 (Built-in 54-Mbps Wi-Fi, certified for > 802.11g and 802.11b interoperability) running Mac OS X 10.4.9 > The powerbook is 1.5 meters away from the Dlink antena, and ath0 is in > "mode 11g" and "pureg". > > The best transfer rate I can achieve is 3.1 MB/s from the powerbook to > the freebsd-box, and about 2.7 MB/s from the freebsd-box to the powerbook. > > Any idea how I could boost my transfer rates ? Find athstats in tools/tools/ath and figure out why you're not seeing the expected throughput. Sam