21–30 of 58 posts
Earlier quoted context omitted.
51 days seems to be approximately how often my mac dies in kernel panic or starting to be bugged by persistent software problems that go away with a restart.
I’m at 356 days of uptime on my MacBook Pro. ¯\_(ツ)_/¯
tl;dr: 51 days is the wraparound point of a signed 6-byte counter running at 33 MHz, used to invalidate stale data from instruments.
https://www.cnet.com/culture/windows-may-crash-after-49-7-da...
tl;dr: 51 days is the wraparound point of a signed 6-byte counter running at 33 MHz, used to invalidate stale data from instruments.
Earlier quoted context omitted.
To address the second part: > and yet the plane appears to have no mechanical backup instruments[?] This is unlikely in a modern aircraft because mechanical instruments to back up e.g., the artificial horizon / attitude indicator or directional gyro (DG) / heading indicator are: 1) Mechanically complex - the attitude indicator and DG make use of gyroscopes which rotate at up to 24,000 RPM along with other mechanisms.…
I think backups for the electronic systems would not need the same level of redundancy as the primary systems (which presumably already have backups). It's sort of like how you don't need RAID for your offsite backup disks, just some parity for bit-rot. The mechanical instruments would be the (additional) redundancy. The additional weight/lines/service is indeed burdensome even without redundant mechanical systems.
If your backup is failing more often than your primary system then it's not much use as a backup.
Also, there ARE backups. There's fallback artificial horizon boxes that work independently of the rest of the system, for example.
For example, let’s imagine that the timestamp set by the transmitting ES is close to its wrap-around value. After performing the required calculation, the receiving ES obtains a timestamp that has already wrapped-around, so it would look like the message had been received before it was actually sent. Isn't it surprising that modulo arithmetic, as already employed successfully in TCP sequence numbers and the like, sti…
To address the second part: > and yet the plane appears to have no mechanical backup instruments[?] This is unlikely in a modern aircraft because mechanical instruments to back up e.g., the artificial horizon / attitude indicator or directional gyro (DG) / heading indicator are: 1) Mechanically complex - the attitude indicator and DG make use of gyroscopes which rotate at up to 24,000 RPM along with other mechanisms.…
"Glass" standby instruments come with significant upside and not much downside, which is why they've been preferred in larger/more expensive aircraft for a while. There is nothing inherently more or less reliable about them, being fully isolated and redundant just as old-timey mechanical backups are, and they offer a much richer presentation (typically like a small PFD). However, new things are usually more expensive, which IIUC is why they were adopted first in larger, more expensive aircraft. They were considered a luxury in GA until fairly recently.
Earlier quoted context omitted.
I’m at 356 days of uptime on my MacBook Pro. ¯\_(ツ)_/¯
So you never install security updates? Because all Apple updates require a reboot due to their SIP "update the frozen image offline" nonsense.
Earlier quoted context omitted.
51 days seems to be approximately how often my mac dies in kernel panic or starting to be bugged by persistent software problems that go away with a restart.
I’m at 356 days of uptime on my MacBook Pro. ¯\_(ツ)_/¯
Avionics software starts with writing comprehensive requirements. When the software itself is developed based on those requirements, it is then tested against the requirements, always in a real functioning airplane, but also often in smaller airplane-cockpit-like rigs and in purely simulated environments.
Nobody is going to write a requirement that says "this avionics subsystem will function without error forever". Even if you thought you could make it happen, you can't test it. So there are going to be boundaries. You might say that the subsystem will function for X days. What happens after that? It may well run just fine for X+1 days, or 2X days, or 100X days. But it's only required to run for X days, and it's only tested and certified for running for X days.
I could easily imagine that this particular subsystem was required and certified for some value of X But even if the intended X wasn't 51 days, there almost certainly was some intended, finite value for X. We might say, "well, my laptop has run for three years without needing a reboot". Great! Is that a guaranteed, repeatable state of operation that the FAA would certify? Probably not. And besides that, do we really want to have to endure a three-year verification test?
In most software, we are happy to say, "it should run indefinitely". For avionics software, that's insufficient. We instead say "it will run at least for some specific predetermined finite amount of time" and then back up that statement with certifiable evidence.
tl;dr: 51 days is the wraparound point of a signed 6-byte counter running at 33 MHz, used to invalidate stale data from instruments.
