> 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] ------------------- 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]>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]> > 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]] > > Sent: Thursday, December 12, 2013 11:35 AM > > To: Clark, Joel > > Cc: [email protected] > > Subject: Re: [Dev] Tizen use of FIFO & Nice > > > > On Thu, Dec 12, 2013 at 9:38 AM, Clark, Joel <[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] > > https://lists.tizen.org/listinfo/dev > > > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev >
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
