From owner-freebsd-performance@FreeBSD.ORG Tue Oct 11 14:01:13 2005 Return-Path: X-Original-To: performance@FreeBSD.org Delivered-To: freebsd-performance@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60AE116A41F; Tue, 11 Oct 2005 14:01:13 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDAFF43D58; Tue, 11 Oct 2005 14:01:12 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E0CA346B7C; Tue, 11 Oct 2005 10:01:11 -0400 (EDT) Date: Tue, 11 Oct 2005 15:01:11 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: performance@FreeBSD.org In-Reply-To: <20051005133730.R87201@fledge.watson.org> Message-ID: <20051011145923.B92528@fledge.watson.org> References: <20051005133730.R87201@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: net@FreeBSD.org Subject: Re: Call for performance evaluation: net.isr.direct 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: Tue, 11 Oct 2005 14:01:13 -0000 On Wed, 5 Oct 2005, Robert Watson wrote: > In 2003, Jonathan Lemon added initial support for direct dispatch of > netisr handlers from the calling thread, as part of his DARPA/NAI Labs > contract in the DARPA CHATS research program. Over the last two years > since then, Sam Leffler and I have worked to refine this implementation, > removing a number of ordering related issues, opportunities for > excessive parallelism, recursion issues, and testing with a broad range > of network components. There has also been a significant effort to > complete MPSAFE locking work throughout the network stack. Combined > with the earlier move to ithreads and a functional direct dispatch > ("process to completion" implementation), there are a number of exciting > possible benefits. If I don't hear anything back in the near future, I will commit a change to 7.x to make direct dispatch the default, in order to let a broader community do the testing. :-) If you are setup to easily test stability and performance relating to direct dispatch, I would appreciate any help. As of 6.0-RC1 and recent 7.x, the name of the sysctl is "net.isr.direct"; previously it has been named "net.isr.enable", but its use is not recommend in versions that do not use the new name. Thanks, Robert N M Watson > > - Possible parallelism by packet source -- ithreads can dispatch > simultaenously into the higher level network stack layers. Since > ithreads can execute in parallel on different CPU, so can code they > invoke directly. > > - Elimination of context switches in the network receive path -- rather > than context switching to the netisr thread from the ithread, we can now > directly execute netisr code from the ithread. > > - A CPU-bound netisr thread on a multi-processor system will no longer > rate limit traffic to the available resources on one CPU. > > - Eliminating the additional queueing in the handoff reduces the > opportunity for queues to overfill as a result of scheduling delays. > > There are, however, some possible downsides and/or trade-offs: > > - Higher level network processing will now compete with the interrupt > handler for CPU resources available to the ithread. This means less > time for the interrupt code to execute in the thread if the thread is > CPU-bound. > > - Lower levels of parallelism between portions of the inbound packet > processing path. Without direct dispatch, there is possible parallelism > between receive network driver execution and higher level stack layers, > whereas with direct dispatch they can no longer execute in parallel. > > - Re-queued packets from tunnel and encapsulation processing will now > require a context switch to process, since they will be processed in the > netisr proper rather than in the ithread, whereas before the netisr > thread would pick them up immediately after completing the current > processing without a context switch. > > - Code that previously ran in the SWI at a SWI priority now runs in the > ithread at an ithread priority, elevating the general priority at which > network processing takes place. > > And there are a few mixed things, that can offer good and bad elements: > > - Less queueing takes place in the network stack in in-bound processing: > packets are taken directly from the driver and processed to completion > one by one, rather than queued for batch processing. Packets will be > dropped before the link layer, rather than on the boundary between the > link and protocol layers. This is good in that we invest less work in > packets we were going to drop anyway, but bad in that less queueing > means less room for scheduling delays. > > In previous FreeBSD releases, such as several 5.x series releases, > net.isr.enable could not be turned on by default because there was > insufficient synchronization in the network stack. As of 5.5 and 6.0, I > believe there is sufficient synchronization, especially given that we force > non-MPSAFE protocol handlers to run in the netisr without direct dispatch. > As such, there has been a gradual conversation going on about making direct > dispatch the default behavior in the 7.x development series, and more > publically documenting and supporting the use of direct dispatch in the 6.x > release engineering series. > > Obviously, this is about two things: performance, and stability. Many of us > have been running with direct dispatch on by default for quite some time, so > it passes some of the basic "does it run" tests. However, since it > significantly increases the opportunity for parallelism in the receive path > of the network stack, it likely will trigger otherwise latent or infrequent > races and bugs to occur more frequently. The second aspect is performance: > many results suggest that direct dispatch has a significant performance > benefit. However, evaluating the impact on a broad range of results is > required in order for us to go ahead with what is effectively a significant > architectural change in how we perform network stack processing. > > To give you a sense of some of the performance effect I've measured recently, > using the netperf measurement tool (with -DHISTOGRAM removed from the FreeBSD > port build), here are some results. In each case, I've put parenthesis > around host or router to indicate which is the host where the configuration > change is being tested. These tests were performed using dual Xeon systems, > and using back-to-back gigabit ethernet cards and the if_em driver: > > TCP round trip benchmark (TCP_RR), host-(host): > > 7.x UP: 0.9% performance improvement > 7.x SMP: 0.7% performance improvement > > TCP round trip benchmark (TCP_RR), host-(router)-host: > > 7.x UP: 2.4% performance improvement > 7.x SMP: 2.9% performance improvement > > UDP round trip benchmark (UDP_RR), host-(host): > > 7.x UP: 0.7% performance improvement > 7.x SMP: 0.6% performance improvement > > UDP round trip benchmark (UDP_RR), host-(router)-host: > > 7.x UP: 2.2% performance improvement > 7.x SMP: 3.0% performance improvement > > TCP stream banchmark (TCP_STREAM), host-(host): > > 7.x UP: 0.8% performance improvement > 7.x SMP: 1.8% performance improvement > > TCP stream benchmark (TCP_STREAM), host-(router)-host: > > 7.x UP: 13.6% performance improvement > 7.x SMP: 15.7% performance improvement > > UDP stream benchmark (UDP_STREAM), host-(host): > > 7.x UP: none > 7.x SMP: none > > UDP stream benchmark (UDP_STREAM), host-(router)-host: > > 7.x UP: none > 7.x SMP: none > > TCP connect benchmark (src/tools/tools/netrate/tcpconnect) > > 7.x UP: 7.90383% +/- 0.553773% > 7.x SMP: 12.2391% +/- 0.500561% > > So in some cases, the impact is negligible -- in other places, it is quite > significant. So far, I've not measured a case where performance has gotten > worse, but that's probably because I've only been measuring a limited number > of cases, and with a fairly limited scope of configurations, especially given > that the hardware I have is pushing the limits of what the wire supports, so > minor changes in latency are possible, but not large changes in throughput. > > So other than a summary of the status quo, this is also a call to action. I > would like to get more widespread benchmarking of the impact of direct > dispatch on network-related workloads. This means a variety of things: > > (1) Performance of low level network services, such as routing, bridging, > and filtering. > > (2) Performance of high level application servces, such as web and > database. > > (3) Performance of integrated kernel network services, such as the NFS > client and server. > > (4) Performance of user space distributed file systems, such as Samba and > AFS. > > All you need to do to switch to direct dispatch mode is set the sysctl or > tunable "net.isr.dispatch" to 1. To disable it again, remove the setting, or > set it to 0. It can be modified at run-time, although during the transition > from one mode to the other, there may be a small quantity of packet > misordering, so benchmarking over the transition is discouraged. > FYI: as of 6.0-RC1 and recent 7.0, net.isr.dispatch is the name of the > variable. In earlier releases, the name of this variable was net.isr.enable. > > Some important details: > > - Only non-local protocol traffic is affected: loopback traffic still goes > via the netisr to avoid issues of recursion and lock order. > > - In the general case, only in-bound traffic is directly affected by this > change. As such, send-only benchmarks may reveal little change. They > are still interesting, however. > > - However, the send path is indirectly affected due to changes in > scheduling, workload, interrupt handling, and so on. > > - Because network benchmarks, especially micro-benchmarks, are especially > sensitive to minor perturbations, I highly recommend running in a > minimal multi-user or ideally single-user environment, and suggest > isolating undesired sources of network traffic from segments where > testing is occuring. For macro-benchmarks this can be less important, > but should be paid attention to. > > - Please make sure debugging features are turned off when running tests -- > especially WITNESS, INVARIANTS, INVARIANT_SUPPORT, and user space malloc > debugging. These can have a significant impact on performance, both > potentially overshadowing changes, and in some cases, actually reversing > results (due to higher overhead under locks, for example). > > - Do not use net.isr.enable in the 5.x line unless you know what you are > doing. While it is reasonably safe with 5.4 forwards, it is not a > supported configuration, and may cause stability issues with specific > workloads. > > - What we're particularly interested in is a statistically meaningful > comparison of the "before" and "after" case. When doing measurements, I > like to run 10-12 samples, and usually discard the first one or two, > depending on the details of the benchmark. I'll then use > src/tools/tools/ministat to compare the data sets. Running a number of > samples is quite important, because the variance in many tests can be > significant, and if the two sample sets overlap, you can quite easily > draw the entirely wrong conclusion about the results from a small number > of measurements in a sample. > > Assuming you have a fixed width font, typicaly output from ministat looks > something like the following and may be human readable: > > x 7SMP/tcpconnect_queue > + 7SMP/tcpconnect_direct > +--------------------------------------------------------------------------+ > |x xx + +| > |xxxxx xx ++ +++++ +| > ||__A__| |___A__| | > +--------------------------------------------------------------------------+ > N Min Max Median Avg Stddev > x 10 5425 5503 5460 5456.3 26.284977 > + 10 6074 6169 6126 6124.1 31.606785 > Difference at 95.0% confidence > 667.8 +/- 27.3121 > 12.2391% +/- 0.500561% > (Student's t, pooled s = 29.0679) > > Of particular interest is if changing to direct dispatch hurts performance in > your environment, and understanding why that is. > > Thanks, > > Robert N M Watson > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to > "freebsd-performance-unsubscribe@freebsd.org" > From owner-freebsd-performance@FreeBSD.ORG Wed Oct 12 11:45:19 2005 Return-Path: X-Original-To: performance@freebsd.org Delivered-To: freebsd-performance@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80DE816A41F; Wed, 12 Oct 2005 11:45:19 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4841A43D46; Wed, 12 Oct 2005 11:45:19 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout1.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id j9CBiEpW088169; Wed, 12 Oct 2005 04:44:15 -0700 (PDT) Date: Wed, 12 Oct 2005 20:44:13 +0900 Message-ID: From: gnn@freebsd.org To: Robert Watson In-Reply-To: <20051011145923.B92528@fledge.watson.org> References: <20051005133730.R87201@fledge.watson.org> <20051011145923.B92528@fledge.watson.org> User-Agent: Wanderlust/2.12.2 (99 Luftballons) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin8.1.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: performance@freebsd.org, net@freebsd.org Subject: Re: Call for performance evaluation: net.isr.direct 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, 12 Oct 2005 11:45:19 -0000 At Tue, 11 Oct 2005 15:01:11 +0100 (BST), rwatson wrote: > If I don't hear anything back in the near future, I will commit a > change to 7.x to make direct dispatch the default, in order to let a > broader community do the testing. :-) If you are setup to easily > test stability and performance relating to direct dispatch, I would > appreciate any help. > One thing I would caution, though I have no proof nor have I made any tests (yes, I know, bad gnn), is that I would expect this change to degrade non-network performance when the network is under load. This kind of change is most likely to help those with purely network loads, i.e. routers, bridges, etc and to hurt anyone else. Are you absolutely sure we should make this the default? Later, George From owner-freebsd-performance@FreeBSD.ORG Wed Oct 12 12:33:27 2005 Return-Path: X-Original-To: performance@freebsd.org Delivered-To: freebsd-performance@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 166A216A41F; Wed, 12 Oct 2005 12:33:27 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id E60D543D69; Wed, 12 Oct 2005 12:33:07 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 82CFE46B0A; Wed, 12 Oct 2005 08:33:06 -0400 (EDT) Date: Wed, 12 Oct 2005 13:33:06 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: gnn@freebsd.org In-Reply-To: Message-ID: <20051012132648.J7178@fledge.watson.org> References: <20051005133730.R87201@fledge.watson.org> <20051011145923.B92528@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: performance@freebsd.org, net@freebsd.org Subject: Re: Call for performance evaluation: net.isr.direct 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, 12 Oct 2005 12:33:27 -0000 On Wed, 12 Oct 2005 gnn@freebsd.org wrote: > At Tue, 11 Oct 2005 15:01:11 +0100 (BST), > rwatson wrote: >> If I don't hear anything back in the near future, I will commit a >> change to 7.x to make direct dispatch the default, in order to let a >> broader community do the testing. :-) If you are setup to easily >> test stability and performance relating to direct dispatch, I would >> appreciate any help. > > One thing I would caution, though I have no proof nor have I made any > tests (yes, I know, bad gnn), is that I would expect this change to > degrade non-network performance when the network is under load. This > kind of change is most likely to help those with purely network loads, > i.e. routers, bridges, etc and to hurt anyone else. Are you absolutely > sure we should make this the default? In theory, as I mentioned in my earlier e-mail, this does result in more network processing occurring at a hardware ithread priority. However, the software ithread (swi) priority is already quite high. Looking closely at that is probably called for -- specifically, how will this impact scheduling for other hardware (rather than software) ithreads? The most interesting effect I've seen on non-network applications is that, because the network stack now uses significantly less CPU when under high load, more CPU is available for other activities. With the performance of network hardware available on server now often exceeding the CPU capacity of those servers (as compared to a few years ago when 100mbps cards could be trivially saturated by server hardware), the cost of processing packets is now back up again, so this can occur with relative ease. Another interesting point is that remote traffic can now no longer result in a denial of service of local traffic by virtue of overflowing the netisr queue. Previously, a single queue was shared by all network interfaces going to the netisr, and in the direct dispatch model, the queueing now happens almost entirely in the device driver and skips entering a queue to get to the stack. This has some other interesting effects, not least that older cards with less buffering now see significantly less queue space, but I'm not sure if that's significant. In general, I agree with your point though: we need to evaluate the effect of this change on a broad array of real-world workloads. Hence my e-mail, which so far has seen two responses -- a private one from Mike Tancsa offering to run testing, and your public one. So anyone willing to help evaluate the performance of this change would be most welcome to. Robert N M Watson From owner-freebsd-performance@FreeBSD.ORG Thu Oct 13 00:11:10 2005 Return-Path: X-Original-To: freebsd-performance@FreeBSD.org Delivered-To: freebsd-performance@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0478A16A41F for ; Thu, 13 Oct 2005 00:11:10 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from freebee.digiware.nl (dsl439.iae.nl [212.61.63.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A64143D46 for ; Thu, 13 Oct 2005 00:11:08 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from [212.61.27.71] (dual.digiware.nl [212.61.27.71]) by freebee.digiware.nl (Postfix) with ESMTP id 6DD0C2AAAF; Thu, 13 Oct 2005 02:11:07 +0200 (CEST) Message-ID: <434DA6D3.3040309@withagen.nl> Date: Thu, 13 Oct 2005 02:14:11 +0200 From: Willem Jan Withagen User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce Evans References: <20051002170446.78674.qmail@web30303.mail.mud.yahoo.com> <004701c5c77e$a8ab4310$b3db87d4@multiplay.co.uk> <434146CA.8010803@pgt.mpt.gov.br> <20051004075806.F45947@delplex.bde.org> In-Reply-To: <20051004075806.F45947@delplex.bde.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-performance@FreeBSD.org, =?UTF-8?B?VHVsaW8gR3VpbWFyw6NlcyBkYSBTaWx2YQ==?= Subject: Re: dd(1) performance when copiing a disk to another 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, 13 Oct 2005 00:11:10 -0000 Bruce Evans wrote: > On Mon, 3 Oct 2005, [ISO-8859-1] Tulio Guimar�es da Silva wrote: > >> But just to clear out some questions... >> 1) Maxtor�s full specifications for Diamond Max+ 9 Series refers to >> maximum *sustained* transfer rates of 37MB/s and 67MB/s for "ID" and >> "OD", respectively (though I couldn�d find exactly what it means, I >> deduced that represents the rates for center- and border-parts of the >> disk - please correct me if I�m wrong), then your tests show you�re >> getting the best out of it ;) ; >> much slower. > > > Another interesting point is that you can often get closer to the maximum > rate than the average of the maximum and minumum rate. The outer tracks > contain more sectors (about 67/37 times as many with the above spec), so > the average rate over all sectors is larger than average of the max and > min, > significantly so since 67/37 is a fairly large fraction. Also, you can > often partition disks to put less-often accessed stuff in the slow parts. > [All GEOM alligning deleted] As it so happens, I have again some (faster) spare servers in my office. And given the NFS-tests of last year, I want to see if I could run those tests again. But before doing so I wanted to verify the extent of what Bruce suggest here above. (Which I found first in an article some time ago) I've written a small, not yet complete page, on the topic. At current it only involves writting to the disk. But it clearly visualises the effect of non-constant transferrates, which actually depends on the location of the track read from. If you want, you could see for yourself at: http://withagen.dyndns.org/FreeBSD/Performance/Raw-disk/ Suggestions etc. are welcome. --WjW From owner-freebsd-performance@FreeBSD.ORG Fri Oct 14 09:47:39 2005 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A7B016A41F for ; Fri, 14 Oct 2005 09:47:39 +0000 (GMT) (envelope-from ben@algroup.co.uk) Received: from mail.links.org (mail.links.org [217.155.92.109]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E8FD43D45 for ; Fri, 14 Oct 2005 09:47:38 +0000 (GMT) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 0283E33C1B; Fri, 14 Oct 2005 10:47:37 +0100 (BST) Message-ID: <434F7EBA.1090206@algroup.co.uk> Date: Fri, 14 Oct 2005 10:47:38 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: JG References: <134970360.20050825104636@adeon.lublin.pl> <20050825092210.25239.qmail@web30312.mail.mud.yahoo.com> <1476333643.20050825224149@adeon.lublin.pl> In-Reply-To: <1476333643.20050825224149@adeon.lublin.pl> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org, =?ISO-8859-1?Q?Arne_W=F6rner?= Subject: Re: slow tar performance on fbsd5 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, 14 Oct 2005 09:47:39 -0000 JG wrote: >>Now I say, what about >># cpio -i < mysql-m.tgz >>(assuming that mysql-m.tgz is in "tar" format)? > > > Hello, > > idea is good, but the result is the same :/ The filesystem is _much_ slower in 5 than it is in 4. You can benchmark it with postmark (in the ports tree) - the difference is huge. Not a good thing, IMNSHO! -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-freebsd-performance@FreeBSD.ORG Fri Oct 14 10:06:36 2005 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E51A116A41F for ; Fri, 14 Oct 2005 10:06:36 +0000 (GMT) (envelope-from jarek@adeon.lublin.pl) Received: from v00061.home.net.pl (list.pl [212.85.96.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 13E0743D46 for ; Fri, 14 Oct 2005 10:06:35 +0000 (GMT) (envelope-from jarek@adeon.lublin.pl) Received: from alr194.internetdsl.tpnet.pl (HELO KOMP) (jarek.list@home@83.17.47.194) by matrix01.home.net.pl with SMTP; Fri, 14 Oct 2005 10:06:32 -0000 Date: Fri, 14 Oct 2005 12:06:59 +0200 From: JG X-Priority: 3 (Normal) Message-ID: <1851634286.20051014120659@adeon.lublin.pl> To: freebsd-performance@freebsd.org In-Reply-To: <434F7EBA.1090206@algroup.co.uk> References: <134970360.20050825104636@adeon.lublin.pl> <20050825092210.25239.qmail@web30312.mail.mud.yahoo.com> <1476333643.20050825224149@adeon.lublin.pl> <434F7EBA.1090206@algroup.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re[2]: slow tar performance on fbsd5 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: JG List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 10:06:37 -0000 Hello all, Seems that my problem with untarring is resolved! Firstly, Write Cache was disabled by default by my scsi controller. FreeBSD 5.4, WCE=0 # time gtar -xf mysql-m.tgz 1.207u 16.371s 7:01.06 4.1% 164+278k 8030+7176io 4pf+0w FreeBSD 5.4, WCE=1 # time gtar -xf mysql-m.tgz 1.217u 16.893s 3:24.51 8.8% 170+288k 8550+6355io 4pf+0w I've upgraded to RELENG_6 today. FreeBSD6 RC1, WCE=1 # time gtar -xf mysql-m.tgz 0.141u 2.836s 0:22.23 13.3% 177+284k 2+1298io 0pf+0w Unbeliveable! It's 22 seconds on FBSD6 versus 3 minutes and 24secs on FBSD5! BTW. If you want to turn write cache on, use: camcontrol modepage daX -m8 -P0 -e then put "1" after WCE in your favourite editor. Regards, JG From owner-freebsd-performance@FreeBSD.ORG Fri Oct 14 11:08:12 2005 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D010C16A41F for ; Fri, 14 Oct 2005 11:08:12 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7F0A43D5A for ; Fri, 14 Oct 2005 11:08:11 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 7D2BD46C01; Fri, 14 Oct 2005 07:08:11 -0400 (EDT) Date: Fri, 14 Oct 2005 12:08:11 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ben Laurie In-Reply-To: <434F7EBA.1090206@algroup.co.uk> Message-ID: <20051014120728.O22507@fledge.watson.org> References: <134970360.20050825104636@adeon.lublin.pl> <20050825092210.25239.qmail@web30312.mail.mud.yahoo.com> <1476333643.20050825224149@adeon.lublin.pl> <434F7EBA.1090206@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-performance@freebsd.org, JG , =?ISO-8859-1?Q?Arne_W=F6rner?= Subject: Re: slow tar performance on fbsd5 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, 14 Oct 2005 11:08:12 -0000 On Fri, 14 Oct 2005, Ben Laurie wrote: > JG wrote: >>> Now I say, what about >>> # cpio -i < mysql-m.tgz >>> (assuming that mysql-m.tgz is in "tar" format)? >> >> Hello, >> >> idea is good, but the result is the same :/ > > The filesystem is _much_ slower in 5 than it is in 4. You can benchmark > it with postmark (in the ports tree) - the difference is huge. If you haven't tried 6.x yet, please do, and see if that improves the situation. And if you run into problems, please report ASAP so we can try to get them fixed before we release. :-) Robert N M Watson From owner-freebsd-performance@FreeBSD.ORG Fri Oct 14 12:57:39 2005 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8723116A41F for ; Fri, 14 Oct 2005 12:57:39 +0000 (GMT) (envelope-from jeff.tchang@gmail.com) Received: from qproxy.gmail.com (qproxy.gmail.com [72.14.204.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EDBC43D46 for ; Fri, 14 Oct 2005 12:57:38 +0000 (GMT) (envelope-from jeff.tchang@gmail.com) Received: by qproxy.gmail.com with SMTP id a39so277863qbd for ; Fri, 14 Oct 2005 05:57:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=DRsxCqjflLZjeWA3rpMIeXDPgdR2sfjaXzFr3Z+tz8dVskS1Nyc26lLs5+IipCzOiSWieaG6CYR2H3MFzI77So+/GN106g7gGgJMQuhBCP7mqV0SlTDw0kkfPo6uw3vHsJJuoJppRjq2z232eWjgLvbVuxXKwP+dBf3yopLqe9Q= Received: by 10.65.98.20 with SMTP id a20mr722562qbm; Fri, 14 Oct 2005 05:57:38 -0700 (PDT) Received: by 10.65.135.14 with HTTP; Fri, 14 Oct 2005 05:57:38 -0700 (PDT) Message-ID: <63f9d2650510140557p287997bemf773469811c8d2a0@mail.gmail.com> Date: Fri, 14 Oct 2005 08:57:38 -0400 From: Jeff Tchang To: freebsd-performance@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: slow tar performance on fbsd5 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, 14 Oct 2005 12:57:39 -0000 JG, Are you using any type of raid controller? I wonder if upgrading to freebsd= 6 will solve some performance issues? From owner-freebsd-performance@FreeBSD.ORG Sat Oct 15 13:05:39 2005 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32D0B16A41F for ; Sat, 15 Oct 2005 13:05:39 +0000 (GMT) (envelope-from jarek@adeon.lublin.pl) Received: from v00061.home.net.pl (list.pl [212.85.96.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 83CEE43D48 for ; Sat, 15 Oct 2005 13:05:37 +0000 (GMT) (envelope-from jarek@adeon.lublin.pl) Received: from aui141.neoplus.adsl.tpnet.pl (jarek.list@home@83.27.16.141) by matrix01.home.net.pl with SMTP; Sat, 15 Oct 2005 13:05:32 -0000 Date: Sat, 15 Oct 2005 15:05:31 +0200 From: JG X-Priority: 3 (Normal) Message-ID: <1987290756.20051015150531@adeon.lublin.pl> To: freebsd-performance@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: slow tar performance on fbsd5 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: JG List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2005 13:05:39 -0000 > Are you using any type of raid controller? This server suports RAID, but I don't use it. It has "LSILogic 1030 Ultra4 Adapter". See Dell 2850 specification for more hardware details. > I wonder if upgrading to freebsd6 > will solve some performance issues? Yes, it should! Give it a try. Best reagrds, JG