[Bug 10633] New: Minimums for timer granularity should be left to the user agent - different form factors have different power requirements

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10633

           Summary: Minimums for timer granularity should be left to the
                    user agent - different form factors have different
                    power requirements
           Product: HTML WG
           Version: unspecified
          Platform: All
               URL: http://dev.w3.org/html5/spec/timers.html#timers
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: adrianba@microsoft.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


Summary 

The HTML5 spec contains the following section

"6.2 Timers
Note: This API does not guarantee that timers will fire exactly on schedule.
Delays due to CPU load, other tasks, etc, are to be expected.
... 
The setTimeout() method must run the following steps:
... 
5. If the currently running task is a task that was created by the setTimeout()
method, and timeout is less than 4, then increase timeout to 4.
... 
The setInterval() method must run the following steps:
... 
    5. If timeout is less than 10, then increase timeout to 10."

We propose removing the exact timeout values from the spec for the following
reasons:
1. Many architectures and computing platforms are unlikely to support these
timeout values.
2. The provided timeout values can have a very negative impact on power
consumption and battery life
3. Every major released and pre-release browser implements different setTimeout
and setInterval behavior and don't adhere to the timeout values provided


Rationale

Even though the spec clearly states that timers aren't guaranteed to fire
exactly on schedule, the spec does set the expectation for web developers that
a setTimeout of 4ms can be expected to work and only occasionally not fire
precisely at the given timeout. 

Many mobile architecture and platforms are aggressive with regards to power
consumption and battery life times. Consequently, they do not allow callbacks
with timeouts of 4ms or even 10ms. 

The impact on battery life time can be significant: 

Energy Smart Software[1] page 6:
"The default Windows 7 timer resolution is 15.6 milliseconds (ms), which allows
the processor to make effective use of C-states when the system is not heavily
loaded. The highest timer resolution available on most modern systems is 1ms.
Setting the timer resolution to 1ms on a modern system can increase power
consumption by 15 percent. For a typical client scenario of a modern laptop
that is being used to browse the web and to do light processing, setting the
timer to 1 ms could reduce battery run time by more than an hour."

Furthermore, frequent periodic executions are detrimental to power consumption
since it prevents processors and surrounding components from entering power
conservation states and the overhead of entering and exiting power states
frequently negates any power savings. It is more optimal to execute a burst of
computation followed by a long idle time during which cores and other chipset
components can be turned off:

CPU Power Utilization on Intel Architectures [2]:
"Every interrupt will pull back the CPU from a deeper sleep state to C0 due to
the interrupt handler that services the interrupts. This impacts the sleep
state residencies that are critical to optimize the power consumed. There is
also an energy cost associated in transitioning between multiple C-states. If
the interrupt rates are high, the power savings due to deeper sleep states are
negatively impacted due to the decrease in sleep state residencies and the cost
associated with C-state transitions. While Intel® platforms offer
platform-specific C3-like states, they require long residency (multiple
milliseconds) to fully amortize their transitional costs. An aggressive
interrupt rate can potentially negate the benefits of deep sleep states offered
by the platform."


Details

The bullet 5 in the setTimeout part of section "6.2 Timers" should be changed
to:

5. If the currently running task is a task that was created by the setTimeout()
method, and timeout is less than a user-agent-defined value, then increase
timeout to the user-agent-defined value.

As well as the bullet 5 in the setInterval part of the same section should be
changed to:

5. If timeout is less than a user-agent-defined value, then increase timeout to
the user-agent-defined value.


Impact

Positive Impact
* Not prescribing specific timeout values avoid setting expectations with web
developers that certain timeouts can be achieved on all architectures and
platforms
* Removing the prescribed timeouts allows browser vendors to create
implementations that are power conscious, conserve battery lifetime and reduce
power consumption ultimately impacting world energy consumption
* Allows browser vendors to implement HTML5 conforming browsers on platforms
that cannot meet the currently prescribed values as well as meet power
restrictions.

Negative Impact
* Implementation will not converge on implementation, but that is unlikely to
happen due to different architecture constraints

Risks

Considering that more major browsers do not adhere to the currently prescribes
timeout values, removing the values entirely from the spec should not impact
existing web pages. 


References

[1] Energy Smart Software (June 16, 2010) 
http://www.microsoft.com/whdc/system/pnppwr/powermgmt/Energy-Smart_SW.mspx 

[2] CPU Power Utilization on Intel Architectures
http://software.intel.com/en-us/articles/cpu-power-utilization-on-intel-architectures/

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 15 September 2010 01:55:24 UTC