[OASIS Issue Tracker] (MQTT-320) Expectations of timing accuracy in MQTT implementations

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/MQTT-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=64286#comment-64286 ] 

Ed Briggs commented on MQTT-320:
--------------------------------

I agree with Andrews general approach. I would like to point out some counter-examples to a few of the assumptions discussed so far. These are things I encounter in my work on time synchronization.

1. Interval timers are preferable for timeout purposes, but not all systems have interval timers available. For those that do, the resolution of the timer is an important parameter. A timer with 1 second resolution, will have an accuracy  of +/- 1 second.  Some implementations make the following mistake,  if timer of interest (say the MQTT Keep Alive timer) is (say) 60 seconds, they will implement a tick timer that wakes up every 30 or 60 seconds. The result is 50% probability the time interval will be too short,
and by a substantial amount. 

2. Embedded system manufacturers (automotive and consumer markets) are switching to cheaper, less accurate ceramic resonators in place of quartz crystals for clocks, and these typically have a manufacturing frequency tolerance of  +/- 0.5%, which means that over a period of 24 hours, the time interval may be off by +/- 432 seconds (6min, 12 sec), and any two system may diverge by twice that (14 minutes, 24 sec).   This size of the error increases with the size of the interval.  There is an additional 0.1% error due to thermal conditions over an operating temperature range of -40 - 120 F.  Automotive devices are subject to wide temperature variations.   

3. Not all systems have an interval timer. Some will use time-of-day measurements for this purpose, and this presents some massive problems:
    a.) Some systems, like the ubiquitous Raspberry PI have no CMOS or battery clock, so the time is set to 1-Jan-1970 when the system starts. If the time is later set to an external reference, there is a jump of 46 years between two adjacent timestamps.  And when the system is rebooted, there is a step backward of 46 years.  Any time interval measurements would be, well, unreliable.

4.  Those systems that have RTC chips with CMOS/Battery backup may be set to an incorrect value, causing the same sort of leap as in #3 if the clock is ever set or synchronized (say with NTP.)     Some RTC chips may not be set to UTC, and so there will be seasonal time-zone adjustments that invalidate the time intervals. 

5. There are leap seconds in UTC which typically cause a step backward of 1 second  (different systems behave differently, but this is a common case)

6. Some embedded systems designers are prohibited from synchronizing the TOD clock to an external source (e.g. GPS, NIST or ntp.org, etc) because of security concerns.
     Both are easily spoofed. 

7. If an external time reference is used (e.g. GPS in a automobile, or NTP in a residential device), the reference source may become inaccessible (driving in a tunnel, or out of wireless range).  This can lead to an arbitrarily large time offset error, and a very step forward or backward when reachability is restored.

In conclusion, I would suggest we avoid any assumptions about both the magnitude and the direction of the phase error.


> Expectations of timing accuracy in MQTT implementations
> -------------------------------------------------------
>
>                 Key: MQTT-320
>                 URL: https://issues.oasis-open.org/browse/MQTT-320
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 5
>            Reporter: Ian Craggs
>            Priority: Minor
>
> There are a number of aspects of MQTT which involve timings, starting with the keepalive interval, and some new features introduced in MQTT 5 such as message expiration.
> These timers are denoted in seconds (I don't think we have any exceptions to that), but the implementation of those timers in both servers and clients may not actually be at the resolution of small numbers of seconds.  I suggest that we include some wording to limit the expectation of accuracy when a small number of seconds is used on such a timer, where "small" is to be defined, but could be less than 10 for instance.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)