[Dev] Sensor Framework design.

Clark, Joel joel.clark at intel.com
Mon Dec 16 05:14:14 GMT 2013

It's really time to change the subject line, since the previous title and original question was not about Sensor Framework.

From: Ramasamy Kannan [mailto:ram.kannan at samsung.com]
Sent: Sunday, December 15, 2013 7:58 PM
To: Hanchett, Paul
Cc: Lynch, Rusty; Clark, Joel; dev at lists.tizen.org
Subject: Re: Re: [Dev] Tizen use of FIFO & Nice

Below is the big picture of how the current and new sensor framework will work.

Current Sensor Framework Architecture:-

The applications (highest layer) here use a kind of polling based mechanism for getting sensor events from the sensor plugins (lowest layer). Sensor plugins are used to configure and get sensor event data from the sensor driver. The sensor client running on the application process registers sensor events as GSource events with specific sensor event interval and the event callback function. The sensor client sends commands (to read sensor data or to configure the sensors or to register/deregister for events) to the sensor server. The GSource event handler sends a command to the server for each sensor event interval timeout. Each client communicates with server using a socket. The sensor server at the lowest layer monitors all the sensor plugins. The sensor server on receiving the commands from each application/sensor client creates individual thread to process the command. In case the command is for getting data, the newly created thread would then invoke a command handler to get data from the sensor plugin, send acknowledgement for the command with the sensor data back to the client and then terminates. The client receives the data as command acknowledgement packet on the socket and triggers the registered sensor event callback function.

New Sensor Framework Architecture:-

We observed lot of performance issues in the above mechanism. One of the fixes was to remove the functionality of sending commands to get sensor data. From 3.0 release, only sensor configuration and registering/deregistering events would be handled using commands. The sensor data will not be received by applications sending commands as described in old architecture, but event would be sent to the clients from the server plugins whenever the events become available. Hence instead of individual threads getting data, a single event queue will deliver all event data to the event dispatcher in the server. The event dispatcher then filters out events for specific clients and sends them over the event socket to the client.

But there is no option to add priority to specific events and deliver them faster than other events. All applications and their events are considered to be equal priority. However the events will be delivered to the sensor framework client based on their registered event interval.



------- Original Message -------

Sender : Hanchett, Paul<phanchet at jaguarlandrover.com<mailto:phanchet at jaguarlandrover.com>>

Date : Dec 13, 2013 23:35 (GMT+05:30)

Title : Re: [Dev] Tizen use of FIFO & Nice

> like generating a thread in the sensor server each time sensor data is required.

Can you tell a little more about this?  AFAIK most automotive events (from the CAN bus) will be coming through the Automotive Message Broker, which will be relaying messages upward through the dbus.  Messages off the CAN bus have their own priority system that has nothing to do with threading.

Admittedly my focus has been on getting CAN data upwards (and downwards) to (and from) an HTML5 app, but I've seen no mechanism to prioritize events as they bubble up into applications.

So your idea is interesting to me.  Have I missed something?


Paul Hanchett
Infotainment Engineer
MSX on behalf of Jaguar Land Rover
One World Trade Center, 121 Southwest Salmon Street, 11th Floor, Portland, Oregon, 97204

Email: phanchet at jaguarlandrover.com<mailto:phanchet at jaguarlandrover.com>

Business Details:
Jaguar Land Rover Limited
Registered Office: Abbey Road, Whitley, Coventry CV3 4LF
Registered in England No: 1672070

On Thu, Dec 12, 2013 at 7:20 PM, Ramasamy Kannan <ram.kannan at samsung.com<mailto:ram.kannan at samsung.com>> wrote:
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
GPS - 100ms

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.


------- Original Message -------
Sender : Rusty Lynch<rusty.lynch at intel.com<mailto:rusty.lynch at intel.com>>
Date   : Dec 13, 2013 01:38 (GMT+05:30)
Title  : Re: [Dev] Tizen use of FIFO & Nice

This isn't going through the sensor framework.
On Thu, 2013-12-12 at 20:01 +0000, Clark, Joel wrote:
> 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.
> Regards
> Joel
> -----Original Message-----
> From: Kok, Auke-jan H [mailto:auke-jan.h.kok at intel.com<mailto:auke-jan.h.kok at intel.com>]
> Sent: Thursday, December 12, 2013 11:35 AM
> To: Clark, Joel
> Cc: dev at lists.tizen.org<mailto:dev at lists.tizen.org>
> Subject: Re: [Dev] Tizen use of FIFO & Nice
> On Thu, Dec 12, 2013 at 9:38 AM, Clark, Joel <joel.clark at intel.com<mailto: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.
> Auke
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org<mailto:Dev at lists.tizen.org>
> https://lists.tizen.org/listinfo/dev

Dev mailing list
Dev at lists.tizen.org<mailto:Dev at lists.tizen.org>
Dev mailing list
Dev at lists.tizen.org<mailto:Dev at lists.tizen.org>

[cid:image001.gif at 01CEF9DA.99342040]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131216/896764d4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 14036 bytes
Desc: image001.gif
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131216/896764d4/attachment-0001.gif>

More information about the Dev mailing list