Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Nov 2012 06:55:38 +0100
From:      Matthias Reyelt <Matthias.Reyelt@brunel.de>
To:        "Ronald Klop" <ronald-freebsd8@klop.yi.org>
Cc:        freebsd-arm@freebsd.org
Subject:   Re: Improve system latency during harddisk access
Message-ID:  <201211290655.39031.Matthias.Reyelt@brunel.de>
In-Reply-To: <op.woh4njgy8527sy@212-182-167-131.ip.telfort.nl>
References:  <201211280842.51271.Matthias.Reyelt@brunel.de> <op.woh4njgy8527sy@212-182-167-131.ip.telfort.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
Yes, I admit there's room for clarification:

On the system there's one task (process), which is timer controlled and runs 
every 50ms. The task therefore has only 50ms to finish its cycle. This task 
doesn't access the harddisk at all. Generally, there is no performance 
problem.  
The harddisk shall be used for logging etc. 
However, as soon as I log onto the system and do an 'ls' or so, the cyclic 
task produces an overrun. It looks as if harddisk access may block the 
complete system for 15..20ms sometimes. 

So I am trying to throttle the harddisk I/O so that it doesn't block the rest 
of the system. I have tried to renice processes to have increased priority on 
the cyclic task. 

Currently we use HZ=1000 and 4BSD scheduler. Also preemption does not improve 
the responsiveness. Seems the CPU hangs for some time waiting for the disk.

Regards
Matthias 

Am Mittwoch, 28. November 2012 22:00:45 schrieb Ronald Klop:
> 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201211290655.39031.Matthias.Reyelt>