4 ms·
Not getting it.. yeah the famous 32 bit ms overflow after 49 something days. But why then 51 here? Shouldn't they be required to reboot after 49 days please ple
by throwbadubadu 2y ago
Not getting it.. yeah the famous 32 bit ms overflow after 49 something days. But why then 51 here? Shouldn't they be required to reboot after 49 days please please? :D
- tines 2y agoPossibly cumulative error in the timing source?
- icelancer 2y agoThis is even scarier than the base concern.
- jcelerier 2y agoOr just ticking every 1.025 ms (e.g. at 975 Hz instead of 1khz)... that brings us to : (4406400000 - 1.025*2 ^ 32)/1000 so a difference of 1.12 hours with the "51 days" mention.
- hinkley 2y agoIt's possible to run tasks instead of starting every second, starting one second after the previous iteration finishes. So if you have something that checks the system health every millisecond, and keeps a count instead of a duration, then if it takes a couple microseconds to complete you might get something less than 86 million ticks per day instead of 86.4 million.
- Jtsummers 2y agoThe OS used on the 787 has a hard real-time scheduler. Tasks are started up at a specific frequency (set per task), run to completion or to the end of their time slot (set per task) and terminated. We had, IIRC, a strict 100ms slot for our bit of LRU software to do everything and it would be launched every 1s (from memory, that was 15 years ago). Information could be stored between executions so partial completion is something you could handle if needed by storing state information and using it at the start of the next iteration (we didn't need that, our tasks finished in the slot). You don't base the start of a future task on the end of the prior one, you base it on a fixed clock for these kinds of systems.
- tedunangst 2y agoOr maybe it's aliens and their strontium-89 wormhole collapses after 51 days. At this point we're just making shit up.
- amelius 2y agoMaybe it takes 2 days to boot the entire thing?