Comment by panda88888
6 years ago
I think you are right. 50 days is 4.32e9 ms, which is just a bit under max value of unsigned 32-bit int.
6 years ago
I think you are right. 50 days is 4.32e9 ms, which is just a bit under max value of unsigned 32-bit int.
It's actually a bit over the max value[1] - I agree though that I'd strongly suspect this issue is related to overflowing a millisecond counter stored in a 32-bit int. The numbers are way too close.
Hey, maybe <51 was just a off-by-one error... or maybe the actual advisory is to be <50 and some PM decided that number was too round or violated an SLA.
1. 4,294,967,296 or 4.29e9
They should follow the Linux kernel and set all counters to rollover a few minutes after boot.
Does it actually do that? Is it done to ensure that all apps can handle the scenario?
1 reply →
But with engineering we almost always have safety factors. I'd say it's probably a 64-bit int, but that would be way too much of a safety factor.
Safety factors are a thing, sure. Safety factors of 4.29e9x (which is what you get when you go from 32- to 64-bit ints) are possibly a bit excessive, and not at all worthy of an FAA airworthiness directive.
1 reply →
Given this appears to be used in the communications layer of the system I expect that the width is a defined segment of some part of the wire protocol.
Good old GetTickCount() bug.
That's the first thought that came to my mind. What are the odds that they've got an embedded CPU running Win32 somewhere in the aircraft? :)
Context[1] for anyone not familiar with the old Win32 APIs.
[1]: https://docs.microsoft.com/en-us/windows/win32/api/sysinfoap...
The system in question runs VxWorks.
"for reasons the directive did not go into, the 787's common core system (CCS) – a Wind River VxWorks realtime OS product..."