<HTML xmlns:o = "urn:schemas-microsoft-com:office:office"><HEAD><TITLE>Samsung Enterprise Portal mySingle</TITLE>
<META content="text/html; charset=windows-1252" http-equiv=Content-Type>
<STYLE id=mysingle_style type=text/css>P {
        MARGIN-TOP: 5px; FONT-FAMILY: Arial, arial; MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt
}
TD {
        MARGIN-TOP: 5px; FONT-FAMILY: Arial, arial; MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt
}
LI {
        MARGIN-TOP: 5px; FONT-FAMILY: Arial, arial; MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt
}
BODY {
        LINE-HEIGHT: 1.4; MARGIN: 10px; FONT-FAMILY: Arial, arial; FONT-SIZE: 9pt
}
</STYLE>

<META name=GENERATOR content=ActiveSquare></HEAD>
<BODY>
<P>Below is the big picture of how the current and new sensor framework will work.</P>
<P>Current Sensor Framework Architecture:-</P>
<P>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.<o:p></o:p></P>
<P>New Sensor Framework Architecture:-</P>
<P>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.</P>
<P> </P>
<P>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.</P>
<P> </P>
<P>Regards,</P>
<P>Ram</P>
<P>------- <B>Original Message</B> -------</P>
<P><B>Sender</B> : Hanchett, Paul<phanchet@jaguarlandrover.com></P>
<P><B>Date</B> : Dec 13, 2013 23:35 (GMT+05:30)</P>
<P><B>Title</B> : Re: [Dev] Tizen use of FIFO & Nice</P>
<P> </P>
<DIV dir=ltr>
<DIV style="FONT-SIZE: small" class=gmail_default>> <SPAN style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 12px">like generating a thread in the sensor server each time sensor data is required.</SPAN></DIV>
<DIV style="FONT-SIZE: small" class=gmail_default><SPAN style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 12px"><BR></SPAN></DIV>
<DIV style="FONT-SIZE: small" class=gmail_default><SPAN style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 12px">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.</SPAN></DIV>
<DIV style="FONT-SIZE: small" class=gmail_default><SPAN style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 12px"><BR></SPAN></DIV>
<DIV style="FONT-SIZE: small" class=gmail_default><SPAN style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 12px">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.</SPAN></DIV>
<DIV style="FONT-SIZE: small" class=gmail_default><SPAN style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 12px"><BR></SPAN></DIV>
<DIV style="FONT-SIZE: small" class=gmail_default><SPAN style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 12px">So your idea is interesting to me.  Have I missed something?</SPAN></DIV>
<DIV style="FONT-SIZE: small" class=gmail_default><SPAN style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 12px"><BR></SPAN></DIV>
<DIV style="FONT-SIZE: small" class=gmail_default><SPAN style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 12px">Paul</SPAN></DIV></DIV>
<DIV class=gmail_extra><BR clear=all>
<DIV>
<DIV dir=ltr><BR>Paul Hanchett<BR>-------------------<BR>Infotainment Engineer<BR>MSX on behalf of Jaguar Land Rover<BR>One World Trade Center, 121 Southwest Salmon Street, 11th Floor, Portland, Oregon, 97204 <BR><BR>Email: <A style="COLOR: rgb(17,85,204)" href="mailto:phanchet@jaguarlandrover.com" target=_blank>phanchet@jaguarlandrover.com</A><BR>-------------------<BR><BR>Business Details:<BR>Jaguar Land Rover Limited<BR>Registered Office: Abbey Road, Whitley, Coventry CV3 4LF  
<DIV>Registered in England No: 1672070</DIV></DIV></DIV><BR><BR>
<DIV class=gmail_quote>On Thu, Dec 12, 2013 at 7:20 PM, Ramasamy Kannan <SPAN dir=ltr><<A href="mailto:ram.kannan@samsung.com" target=_blank>ram.kannan@samsung.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class=gmail_quote>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.<BR><BR>Here are some sensor event interval requirements for different applications.<BR><BR>Gaming -20ms<BR>User Interface - 50ms<BR>GPS - 100ms<BR><BR>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.<BR><BR>Regards,<BR>Ram<BR><BR><BR>------- Original Message -------<BR>Sender : Rusty Lynch<<A href="mailto:rusty.lynch@intel.com">rusty.lynch@intel.com</A>><BR>Date   : Dec 13, 2013 01:38 (GMT+05:30)<BR>Title  : Re: [Dev] Tizen use of FIFO & Nice<BR>
<DIV class="im HOEnZb"><BR>This isn't going through the sensor framework.<BR><BR></DIV>
<DIV class=HOEnZb>
<DIV class=h5>On Thu, 2013-12-12 at 20:01 +0000, Clark, Joel wrote:<BR>> 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.<BR>><BR>> Regards<BR>> Joel<BR>><BR>><BR>> -----Original Message-----<BR>> From: Kok, Auke-jan H [mailto:<A href="mailto:auke-jan.h.kok@intel.com">auke-jan.h.kok@intel.com</A>]<BR>> Sent: Thursday, December 12, 2013 11:35 AM<BR>> To: Clark, Joel<BR>> Cc: <A href="mailto:dev@lists.tizen.org">dev@lists.tizen.org</A><BR>> Subject: Re: [Dev] Tizen use of FIFO & Nice<BR>><BR>> On Thu, Dec 12, 2013 at 9:38 AM, Clark, Joel <<A href="mailto:joel.clark@intel.com">joel.clark@intel.com</A>> wrote:<BR>> > Why does Tizen use FIFO and NICE?  There are more than 500 threads<BR>> > with FIFO and NICE affecting the performance of critical elements for<BR>> > reading sensor data and updating location etc.<BR>><BR>> Mostly to prioritize screen update refresh rates. Do you really need your GPS location to update within a 20ms interval?<BR>><BR>> Humans can see a single frame drop, easily. Audio is critical too.<BR>> Sensor data (apart from touch) is almost irrelevant at the scale that humans can detect.<BR>><BR>> Also, even with Nice values set high, applications can still be low latency. They do not necessarily conflict.<BR>><BR>> Auke<BR>> _______________________________________________<BR>> Dev mailing list<BR>> <A href="mailto:Dev@lists.tizen.org">Dev@lists.tizen.org</A><BR>> <A href="https://lists.tizen.org/listinfo/dev" target=_blank>https://lists.tizen.org/listinfo/dev</A><BR><BR><BR>_______________________________________________<BR>Dev mailing list<BR><A href="mailto:Dev@lists.tizen.org">Dev@lists.tizen.org</A><BR><A href="https://lists.tizen.org/listinfo/dev" target=_blank>https://lists.tizen.org/listinfo/dev</A><BR>_______________________________________________<BR>Dev mailing list<BR><A href="mailto:Dev@lists.tizen.org">Dev@lists.tizen.org</A><BR><A href="https://lists.tizen.org/listinfo/dev" target=_blank>https://lists.tizen.org/listinfo/dev</A><BR></DIV></DIV></BLOCKQUOTE></DIV><BR></DIV>
<P> </P>
<TABLE id=confidentialsignimg>
<TBODY>
<TR>
<TD NAMO_LOCK>
<P><IMG border=0 src="cid:LP7KBSL8PYMC@namo.co.kr" width=520></P></TD></TR></TBODY></TABLE></BODY></HTML><img src='http://ext.samsung.net/mailcheck/SeenTimeChecker?do=31dc7115280b9d43d101bf591f03642fc3381a562e0b251eb1172e5b3e944dae141ee34884fd53a83dd9d89d549c74c3d5d78d49b87aef04f866eba98cb7300acf878f9a26ce15a0' border=0 width=0 height=0 style='display:none'>