It does seem like all those bits are unnecessary. Either 48 or 64 bits seems plenty. One note: if we want to use the same logging infrastructure for the controller in the ble stack we will need sub-millisecond precision. 1 microsecond units would be preferable; 16 bits for time since last second is not great given BLE timing requirements but could work… That is like 15 or 16 usec precision, right?
> On Apr 8, 2016, at 7:33 AM, Sterling Hughes > <[email protected]> wrote: > > > >> On Apr 8, 2016, at 6:11 AM, Christopher Collins <[email protected]> wrote: >> >>> On Thu, Apr 07, 2016 at 10:33:26PM -0700, Vipul Rahane wrote: >>> Hello, >>> >>> I agree with your statement. We do not know on what kind of devices >>> Mynewt would be ported to. Sleepy devices which are meant to work for >>> 20 years running on a single coin cell battery will rollover the time >>> stamp in 2038. We want to be able to take care of such a situation. >>> While there are other solutions which can be implemented that are more >>> efficient, keeping it as simple as possible is better from an end to >>> end perspective as these logs would be used by applications to >>> understand the state of the devices. >>> >>> I was planning on storing microseconds because the OS currently >>> populates OS time in seconds and microseconds. For microseconds we do >>> require 32 bits. I agree for milliseconds 16 bits are enough but >>> higher resolution is always better. >> >> I think 12 bytes of time is more than necessary. A few notes: >> >> * A single 64-bit microsecond counter allows for 584942 years before >> rollover. >> >> * A single 32-bit second counter won't actually roll over until 2106 >> (the 2038 issue only applies to signed 32-bit timestamps). >> >> If we want microsecond precision, I would just go with a single 64-bit >> counter. Otherwise, 32 bits of seconds is sufficient in my opinion. >> > > +1. That was the original thought. Underlying counters may not be at that > precision- but that doesn't mean you can't store it as microseconds > >> Chris >> >>> >>> Regards, >>> Vipul Rahane >>> >>>> On Apr 7, 2016, at 10:02 PM, Justin Mclean <[email protected]> wrote: >>>> >>>> HI, >>>> >>>>> I am going to change the log structure so that it stores both(UTC >>>>> timestamp in seconds - 64 bit, Microseconds since last second - 32 bit) >>>> >>>> NO objection, but just out of interest why 64 bit for seconds (when 32 bit >>>> of seconds = 60+ years and good until 2038) and 32 bits for milliseconds >>>> when 16 bits will do? See also [1] >>>> >>>> Thanks, >>>> Justin >>>> >>>> 1. https://en.wikipedia.org/wiki/Year_2038_problem#Solutions >>>
