Message-ID: <41840b750707082229k7672ef8bma050289d3cde93ee@mail.gmail.com>
Date:	Mon, 9 Jul 2007 01:29:18 -0400
From:	"Shem Multinymous" <multinymous@...il.com>
To:	"Dmitry Torokhov" <dtor@...ightbb.com>
Cc:	hdaps-devel@...ts.sourceforge.net, rlove@...ve.org,
	"Linux Kernel ML" <linux-kernel@...r.kernel.org>,
	"Andrew Morton" <akpm@...l.org>,
	"Michael Riepe" <michael@...11.de>,
	"Henrique de Moraes Holschuh" <hmh@...ian.org>
Subject: Re: [Hdaps-devel] [PATCH] hdaps - switch to using input-polldev

On 7/9/07, Dmitry Torokhov <dtor@...ightbb.com> wrote:
> > > input-polldev uses a separate workqueue, not keventd, and so should not
> > > suffer from other workqueue users loading keventd. But if entire box
> > > is under stress then workqueue vs timer context does not matter much -
> > > your daemon which is in userspace may not get to run in a timely manner
> > > anyway.
> >
> > The daemon itself typically runs with a higher priority (and sleeps a
> > lot so it gets further dumped). More importantly, the daemon depends
> > not only on the latest measurement, but also on recent measurements
> > have been obtained from the hardware in a regular fashion and with
> > reasonably accurate timestamps. And *this* depends solely on the hdaps
> > driver.
> >
>
> Every input event carries a timestamp so even if there are irregularities
> in taking the samples you should be able to account for it.

The issue is how good are the input event timestamps. The way it works
is that the EC samples the analog sensor at some fixed rate and makes
them available over the LPC bus. If the hdaps driver consumes these
samples at the same rate then the timestamps will be accurate up to a
small phase difference, which is mostly inconsequential. But if the
hdaps driver gets scheduled irregularly, its timestamps will be offset
by varying amounts, which will completely throw off computation (e.g.,
think of estimating the angular velocity).


> > > However I am open to bumping up priority of ipolldevd a little.
> >
> > Will this result in scheduling tha'ts as reliable as rearming timers
> > from softirq? I saw claims to the contrary, but it it's true then I
> > withdraw the first objection.
>
> Probably not. But I still think that if system is so busy that it can't
> get aroung to schedule one of workqueues it will not be able to part
> the driver fast enough anyway.

A delay of 20ms in invoking the userspace daemon is negligible, but a
timing variance of 20ms in the driver's measurements is devastating.


> > > I am curious why you can't use the current device, since the calibration
> > > done in hdaps does not alter the scale but merely moves '0' point around.
> > > And fuzz should only remove small jitters, not rapidly changing data
> > > that you shoudl get when your box is falling.
> >
> > Recent versions of the hdapsd daemons do much more than a simple
> > threshold check: they gather some 2nd-order and decaying averages
> > statistics to catch subtle abnormal movement (e.g., sliding off a
> > surface) that's indicative of potential shock. As pointed out in IBM's
> > HDAPS whitepaper, by the time the box is actually in free fall, it's
> > too late to start parking the heads. Now, that kind of movement is not
> > very far from the noise floor, so hdapsd needs all the accuracy it can
> > get -- hence fuzzing is very disruptive. Calibration is currently
> > harmless, but I can certainly imagine more advanced hdapsd that uses
> > heuristics based, e.g., on the absolute orientation of the laptop, so
> > let's not ruin this data.
>
> If hdaps is the main consumer for the data it may be a good idea to
> just remove the fuzz setting from input device. I don't have the hardware,
> how bad is it without fuzz?

People are using the existing input device as a joystick input for
things like Neverball. Current fuzz is 4 and the observed std dev is
roughly 2, so eliminating fuzz will certainly affect the values. The
implications are app-specific, but I guess some apps do care about
such noise, otherwise we wouldn't have fuzz built into the input
infrastructure.


> > You could one input device open, or the other, or both. How would you
> > set up input-polldev to handle this?
>
> Have 2nd input device's ->open() method call input_open_device() for
> the first one.

Won't that create an overhead by the redundant, unused notifications?

  Shem
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists