Thursday 2nd April 2020 15:11 GMT
BJC
Millisecond roll-over?
So, what is the probability that the timing for these events is stored as milliseconds in a 32 bit structure?

Reply Icon
Re: Millisecond roll-over?
My first thought too, but that rolls over after 49.7 days.

Still, they could have it wrong again.

Re: Millisecond roll-over?
I suspect that it is a millisecond roll over and someone at the FAA picked 51 days instead of 49.7 because they don't understand software any better than Boeing.

Thursday 2nd April 2020 17:05 GMT
the spectacularly refined chap
Reply Icon
Re: Millisecond roll-over?
Could well be something like that, the earlier 248 day issue is exactly the same duration that older Unix hands will recognise as the 'lbolt issue': a variable holding the number of clock ticks since boot overflows a signed 32 bit int after 248 days assuming clock ticks are at 100Hz as was usual back then and is still quite common.

See e.g. here. The issue has been known about and the mitigation well documented for at least 30 years. Makes you wonder about the monkeys they have coding this stuff. //

bombastic bobSilver badge
Reply Icon
Devil
Re: Millisecond roll-over?
I've run into that problem (32-bit millisecond timer rollover issues) with microcontrollers, solved by doing the math correctly

capturing the tick count

if((uint32_t)(Ticker() - last_time) >= some_interval)

and

last_time=Ticker(); // for when it crosses the threshold

[ alternately last_time += some_interval when you want it to be more accurate ]

using a rollover time

if((int32_t)(Ticker() - schedule_time) >= 0)

and

schedule_time += schedule_interval (for when it crosses the threshold)

(this is how Linux kernel does its scheduled events, internally, as I recall, except it compares to jiffies which are 1/100 of a second if I remember correctly)

(examples in C of course, the programming lingo of choice the gods!)

do the math like this, should work as long as you use uint32_t data types for the 'Ticker()' function and for the 'scheduld_time'; or 'last_time' vars.

If you are an IDIOT and don't do unsigned comparisons "similar to what I just demonstrated", you can predict uptime-related problems at about... 49.71 days [assuming milliseconds].

I think i remember a 'millis()' or similarly named function in VxWorks. It's been over a decade since I've worked with it though. VxWorks itself was pretty robust back then, used in a lot of routers and other devices that "stay on all the time". So its track record is pretty good.

So the most likely scenario is what you suggested - a millisecond timer rolling over (with a 32-bit var storing info) and causing bogus data to accumulate after 49.71 days, which doesn't (for some reason) TRULY manifest itself until about 51 days...

Anyway, good catch.