From owner-freebsd-arm@FreeBSD.ORG Wed Nov 28 21:01:55 2012 Return-Path: <owner-freebsd-arm@FreeBSD.ORG> Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43FE5354 for <freebsd-arm@freebsd.org>; Wed, 28 Nov 2012 21:01:55 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews02.kpnxchange.com (cpsmtpb-ews02.kpnxchange.com [213.75.39.5]) by mx1.freebsd.org (Postfix) with ESMTP id 956688FC14 for <freebsd-arm@freebsd.org>; Wed, 28 Nov 2012 21:01:53 +0000 (UTC) Received: from cpsps-ews29.kpnxchange.com ([10.94.84.195]) by cpsmtpb-ews02.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 28 Nov 2012 22:00:04 +0100 Received: from CPSMTPM-TLF104.kpnxchange.com ([195.121.3.7]) by cpsps-ews29.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 28 Nov 2012 22:00:03 +0100 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF104.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 28 Nov 2012 22:00:46 +0100 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id CEB114679; Wed, 28 Nov 2012 22:00:45 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org, "Matthias Reyelt" <Matthias.Reyelt@brunel.de> Subject: Re: Improve system latency during harddisk access References: <201211280842.51271.Matthias.Reyelt@brunel.de> Date: Wed, 28 Nov 2012 22:00:45 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" <ronald-freebsd8@klop.yi.org> Message-ID: <op.woh4njgy8527sy@212-182-167-131.ip.telfort.nl> In-Reply-To: <201211280842.51271.Matthias.Reyelt@brunel.de> User-Agent: Opera Mail/12.11 (FreeBSD) X-OriginalArrivalTime: 28 Nov 2012 21:00:46.0380 (UTC) FILETIME=[6FE20EC0:01CDCDAB] X-RcptDomain: freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor <freebsd-arm.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm> List-Post: <mailto:freebsd-arm@freebsd.org> List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=subscribe> X-List-Received-Date: Wed, 28 Nov 2012 21:01:55 -0000 On Wed, 28 Nov 2012 08:42:51 +0100, Matthias Reyelt <Matthias.Reyelt@brunel.de> wrote: > Hi, > > We have a cyclic test application running at a 50ms cycle running on a > Marvell OpenRD with 9.0 with an attached sata harddisk. > > We have observed that the system is sometimes blocked up to about 18ms by > accessing the harddisk. We have checked the ULE and 4BSD scheduler and > preemption, but without any significant difference. > > I actually do not really believe that this is somewhat ARM specific. > Generally, harddisk I/O is critical for latency, but I've cross checked > with a > Linux installed OpenRD and had less impact of harddisk I/O. > > Do you have any idea how to minimize the influence of harddisk I/O under > FreeBSD? > > Regards > Matthias I think your question is to open to give a good answer. Plus, I don't think 18ms for harddisk IO is very much. My (not so new) desktop PC gives: [root@sjakie ~]# diskinfo -t ada0 ada0 512 # sectorsize 320072933376 # mediasize in bytes (298G) 625142448 # mediasize in sectors 0 # stripesize 0 # stripeoffset 620181 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. GEA354RC3B5S6L # Disk ident. Seek times: Full stroke: 250 iter in 7.440554 sec = 29.762 msec Half stroke: 250 iter in 5.806944 sec = 23.228 msec Quarter stroke: 500 iter in 9.120537 sec = 18.241 msec Short forward: 400 iter in 2.397724 sec = 5.994 msec Short backward: 400 iter in 1.500501 sec = 3.751 msec Seq outer: 2048 iter in 0.208478 sec = 0.102 msec Seq inner: 2048 iter in 0.143242 sec = 0.070 msec Transfer rates: outside: 102400 kbytes in 1.578200 sec = 64884 kbytes/sec middle: 102400 kbytes in 1.726028 sec = 59327 kbytes/sec inside: 102400 kbytes in 2.321649 sec = 44107 kbytes/sec So if your application has to do a little bit of seeking on the disk it has to wait. As there is no information about what your program actually does I can't say anything else about it. Ronald.