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.