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:[email protected]] Sent: Sunday, December 15, 2013 7:58 PM To: Hanchett, Paul Cc: Lynch, Rusty; Clark, Joel; [email protected] 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. Regards, Ram ------- Original Message ------- Sender : Hanchett, Paul<[email protected]<mailto:[email protected]>> 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 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: [email protected]<mailto:[email protected]> ------------------- 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 <[email protected]<mailto:[email protected]>> 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. Regards, Ram ------- Original Message ------- Sender : Rusty Lynch<[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>] > Sent: Thursday, December 12, 2013 11:35 AM > To: Clark, Joel > Cc: [email protected]<mailto:[email protected]> > Subject: Re: [Dev] Tizen use of FIFO & Nice > > On Thu, Dec 12, 2013 at 9:38 AM, Clark, Joel > <[email protected]<mailto:[email protected]>> 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 > [email protected]<mailto:[email protected]> > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected]<mailto:[email protected]> https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected]<mailto:[email protected]> https://lists.tizen.org/listinfo/dev [cid:[email protected]] [http://ext.samsung.net/mailcheck/SeenTimeChecker?do=31dc7115280b9d43d101bf591f03642fc3381a562e0b251e34c6e08d0329743ce9e8027498d7b0edd8c023f270a836a153cb8b1934afabac2f6aaf3d92ded142cf878f9a26ce15a0]
<<inline: image001.gif>>
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
