W3C home > Mailing lists > Public > public-device-apis-log@w3.org > May 2017

Re: [sensors] Define processing model

From: Tobie Langel via GitHub <sysbot+gh@w3.org>
Date: Wed, 24 May 2017 11:10:53 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-303693510-1495624252-sysbot+gh@w3.org>
> In Chrome implementation, we use same shared memory IPC, no change to architecture at all.

Cool. That was my question (sorry it took me quite some time to formulate it in a why that was understandable). And this answer settles it.

> I just asked whether you know about other non-UI bound APIs that do rAF sync, maybe we can learn from them.

Oh, sorry! It sounded like a rhetorical question. :)

Thing is, it's incorrect to consider that sensors usage isn't rAF bound. It is in some cases and isn't in others. It also happens that the cases where it is have high frequency and low latency requirements. Hence my suggestion to look into making rAF syncing opt-in.

> I think there was consensus that we are not delivering data faster than was requested by sensor instance.

Yes. That's not what I'm talking about here at all.

> High sampling rates not necessarily equal to same data rates, as I mentioned before, sensor can be running at 8kHz, while data is delivered at 60Hz,

Yes, that's precisely my point. The rAF sync architecture allowed to request only one frequency setting from the developer which was used both to set the frequency at which the sensor was polled AND the frequency at which the data was delivered to the developers, capped at rAF rate. The limit of memcpy was thus opaquely enforced by the API.

> thus, we will only make 60 memcpy copies per second. 

Well, no. That worked in the previous solution because the 60 copies were rAF sync'ed. If they're not, developers will require 1000 memcpy per second to obtain the same latency.

> If developer needs higher output data rate, higher 'frequency hint' can be provided (frequency hint is more or less ODR, in HW sensor terms).

Well, that's not what's at stake in this scenario. Here, developers are essentially interested in getting a single low latency reading at every rAF. This isn't a far fetched scenario; it's how the original Oculus paper describes the solution implemented in the Oculus Rift. To obtain that you need to high polling rate on the sensor and the ability to grab the latest reading during rAF. With rAF sync, you only need to copy one sample per rAF. Without, you need all 1000 to be copied to the application layer. I can't imagine this has no perf consequences.

Again, I'm not suggesting changing course is not necessary. I'm just pointing out issues that need to be resolved, perhaps by new APIs, perhaps by extra implementation.

GitHub Notification of comment by tobie
Please view or discuss this issue at https://github.com/w3c/sensors/issues/198#issuecomment-303693510 using your GitHub account
Received on Wednesday, 24 May 2017 11:11:00 UTC

This archive was generated by hypermail 2.4.0 : Monday, 4 July 2022 12:47:54 UTC