Roku Developer Program

[RokuJoel]

The bugs filed on sleep() and wait() were never closed, but a workaround was posted:

No wait:

msg = port.GetMessage()
if type(msg) = "roUniversalControlEvent" then
<act on message>
end if

if you need an accurate timer, you could use roTimeSpan

timer=createobject("rotimespan")
timer.mark()
while true
    if timer.totalmilliseconds() >= 10 then
        msg = port.GetMessage()
        timer.mark()
        if type(msg) = "roUniversalControlEvent" then
            <act on message>
        end if
    end if
end while

- Joel

[RokuMarkn]

And while it could be mentioned elsewhere, the "Event loops" section of the Component Reference does refer to this.

--Mark

[EnTerr]

"RokuMarkn" wrote:
And while it could be mentioned elsewhere, the "Event loops" section of the Component Reference does refer to this.

Where?
It is not that i posted yesterday before doing homework first - I read that section too and there was nothing mentioning wait granularity. The only thing i saw is:

... the screen may need to be updated with new animation frames even if no buttons are pressed or other events occur. One way to deal with this is to use a timeout as the first parameter of the call to wait:
msg = wait(5, port)
This waits for a message, but if no message is received within 5 milliseconds, the wait returns and msg is set to 'invalid'. When feasible, this is a simple approach.

However, an approach that usually offers more predictable performance is to use ifMessagePort.GetMessage instead of wait. This is because GetMessage will return immediately if no message is available, while the actual amount of time before a timed wait returns can vary depending on various factors.

It says if you ask for 5ms, you get 5ms - that seems pretty clear stated, not 15ms or "no less than 5ms". Did you mean the "the actual amount of time before a timed wait returns can vary depending on various factors" part? That is so veiled, so crafty if it was supposed to mean "never use wait(N>0)".

To repeat the question: can we get clarification what's the resolution/granularity in those functions?
There must be some resolution you can state, even if it is "least common denominator" kind (e.g. if 1ms for MIPS and 15ms for ARM, could be "resolution no worse than multiples of 15ms").

I can rephrase the question in practical terms, if that helps: say for which of the following the real wait will be within 10% margin from the requested interval?

1. wait(1000, p)


2. wait(300, p)


3. wait(100, p)


4. wait(30, p)


5. wait(10, p)


6. wait(3, p)

Seems clear if i ask for 3ms wait, i won't get it +/-10% - and if i ask for 1000ms, i will get it (give or take 100ms). So the cut-off line is somewhere in-between but at which point?

[RokuJoel]

This is a bug that is specific to the Roku2 3100x 3050x and 2400x hardware models and is, as far as I'm aware, not an issue on any other platform including the Roku legacy devices. Due to an instability, the high resolution timer on the device is not used for Wait() and Sleep() on these devices, which introduces some variability into the amount of time that is actually waited or slept.

You can time the actual wait time to find out for yourself if it is accurate:

timer=createobject("roTimeSpan")
timer.mark()
wait(3,port)
print timer.totalmilliseconds()

- Joel

[TheEndless]

FWIW, I've seen a "Wait(1, port)" take anywhere from 1ms to as much as 20ms (possibly even higher), so my guess is that it's dependent on a number of factors that can't be definitively quantified into a percentage.

[EnTerr]

"TheEndless" wrote:
FWIW, I've seen a "Wait(1, port)" take anywhere from 1ms to as much as 20ms (possibly even higher), so my guess is that it's dependent on a number of factors that can't be definitively quantified into a percentage.

You misunderstood the question.
The example you are giving only shows that 1ms wait cannot be trusted within 10% variation. And i already said i don't imagine 3ms can be trusted, so no news there.

Won't you think 1000ms wait will be correct give or take 100ms and that is not "dependent on a number of factors"?
There are some values above which this is the case. I asked which are they - and even gave MCQ to pick

[TheEndless]

"EnTerr" wrote:

"TheEndless" wrote:
FWIW, I've seen a "Wait(1, port)" take anywhere from 1ms to as much as 20ms (possibly even higher), so my guess is that it's dependent on a number of factors that can't be definitively quantified into a percentage.

You misunderstood the question.
The example you are giving only shows that 1ms wait cannot be trusted within 10% variation. And i already said i don't imagine 3ms can be trusted, so no news there.

Won't you think 1000ms wait will be correct give or take 100ms and that is not "dependent on a number of factors"?
There are some values above which this is the case. I asked which are they - and even gave MCQ to pick

I'm still not sure I understand the question, but I just wrote up a simple test that loops through each Wait() 100 times returning the average time, the lowest time and the highest time for each. I ran it three times and got the following results:

------ 1st Run ------
Wait(1, port)         Average: 10.18    Shortest: 8     Longest: 20
Wait(3, port)         Average: 10.19    Shortest: 10    Longest: 19
Wait(10, port)        Average: 19.99    Shortest: 19    Longest: 21
Wait(30, port)        Average: 39.99    Shortest: 39    Longest: 41
Wait(100, port)       Average: 109.99   Shortest: 109   Longest: 110
Wait(300, port)       Average: 309.99   Shortest: 309   Longest: 311
Wait(1000, port)      Average: 1009.99  Shortest: 1009  Longest: 1011

------ 2nd Run ------
Wait(1, port)         Average: 10.23    Shortest: 8     Longest: 22
Wait(3, port)         Average: 10.19    Shortest: 10    Longest: 19
Wait(10, port)        Average: 19.99    Shortest: 19    Longest: 21
Wait(30, port)        Average: 39.99    Shortest: 39    Longest: 41
Wait(100, port)       Average: 109.99   Shortest: 109   Longest: 110
Wait(300, port)       Average: 309.99   Shortest: 309   Longest: 310
Wait(1000, port)      Average: 1009.99  Shortest: 1009  Longest: 1011

------ 3rd Run ------
Wait(1, port)         Average: 10.16    Shortest: 9     Longest: 20
Wait(3, port)         Average: 10.09    Shortest: 10    Longest: 19
Wait(10, port)        Average: 19.99    Shortest: 19    Longest: 21
Wait(30, port)        Average: 39.99    Shortest: 39    Longest: 40
Wait(100, port)       Average: 110.09   Shortest: 108   Longest: 122
Wait(300, port)       Average: 309.99   Shortest: 309   Longest: 311
Wait(1000, port)      Average: 1009.99  Shortest: 1009  Longest: 1011

I'm not sure if that tells you what you want to know, but it looks like you can pretty much count on 10ms being the lowest you can go, and a roughly, fairly consistent, 10ms overage for everything above that.