[Dev] Tizen use of FIFO & Nice

Ramasamy Kannan ram.kannan at samsung.com
Fri Dec 13 09:42:03 GMT 2013

Indoor Navigation applications use sensor fusion algorithms on raw accelerometer, gyroscope, magnetometer, barometer sensor data along with GPS data to estimate the position of the mobile phone user. Sensor Fusion uses extended kalman filter signal processing which normally gives better estimation of position, height, orientation data when sampling rate is increased for example to 25Hz or 50Hz or 100Hz. There are lots of research papers online which provide information on this.  

Example paper:-


------- Original Message -------
Sender : Lukasz Stelmach<l.stelmach at samsung.com>  Software Engineer/SRPOL-Kernel & System Framework (SSD)/Samsung Electronics
Date   : Dec 13, 2013 14:38 (GMT+05:30)
Title  : Re: [Dev] Tizen use of FIFO & Nice

It was <2013-12-13 pi? 04:20>, when Ramasamy Kannan wrote:
> Sender : Rusty Lynch<rusty.lynch at intel.com> 
> Date   : Dec 13, 2013 01:38 (GMT+05:30)
>> On Thu, 2013-12-12 at 20:01 +0000, Clark, Joel wrote:
>>> From: Kok, Auke-jan H [mailto:auke-jan.h.kok at intel.com] 
>>> Sent: Thursday, December 12, 2013 11:35 AM
>>>> On Thu, Dec 12, 2013 at 9:38 AM, Clark, Joel <joel.clark at intel.com> wrote:
>>>>> Why does Tizen use FIFO and NICE?  There are more than 500 threads
>>>>> with FIFO and NICE affecting the performance of critical elements
>>>>> for reading sensor data and updating location etc.
>>>> Mostly to prioritize screen update refresh rates. Do you really
>>>> need your GPS location to update within a 20ms interval?
>>>> Humans can see a single frame drop, easily. Audio is critical too.
>>>> Sensor data (apart from touch) is almost irrelevant at the scale
>>>> that humans can detect.
>>>> Also, even with Nice values set high, applications can still be low
>>>> latency. They do not necessarily conflict.
>>> For IVI, we are expecting several thousand sensor updates per
>>> second, with nearly 200 different types of sensor data.  Think about
>>> data on the engine, transmission, wheels, brakes, windows, doors,
>>> seats, radar updates on proximity, etc.
>> This isn't going through the sensor framework.
> There are performance issues with the current sensor framework
> architecture, like generating a thread in the sensor server each time
> sensor data is required. We have fixed this in the new architecture
> that will be released for 3.0. In the new architecture there is a
> single event queue that delivers all the sensor events from the sensor
> plugins to the sensor clients.
> Here are some sensor event interval requirements for different applications.
> Gaming -20ms
> User Interface - 50ms

100 ms won't hurt.

> GPS - 100ms

Most GPS receivers I've seen provide updates once a second. Some of them
could be switched to 5Hz updates at most. As far as I can tell even
aviation GPS receivers don't update more than 10Hz.

> Some indoor navigation GPS applications need to be very accurate
> interms of calculating the position of the mobile device. So they may
> go for lower sensor event intervals.

Accuracy in case of these has nothing to do with timing. Those systems
which use WiFi signals calculate the position based on signal strength.
WiFi cards do not send updates more than once a few seconds. In case of
dedicated systems they probably have their own MCUs and behave more or
less like GPS.

?ukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics

More information about the Dev mailing list