4 ms·

According to earlier articles about this issue, planes currently in wide use need to be 'rebooted' at a similar frequency, it's just specific subsystems that ge

According to earlier articles about this issue, planes currently in wide use need to be 'rebooted' at a similar frequency, it's just specific subsystems that get rebooted (I think the F-35's former problem was a sensor), the planes keep flying, and missions don't often last that long anyway (IIRC all the details). Here, I found the link: https://news.ycombinator.com/item?id=11260927 https://news.ycombinator.com/item?id=11260927 EDIT: Heck, I'll just copy the meat of it here: http://breakingdefense.com/2016/02/bogdan-predicts-f-35s-for-less-than-80m-engines-included/ http://breakingdefense.com/2016/02/bogdan-predicts-f-35s-for... The toughest problem the program is having is matching the timing of the aircraft’s fusion software with its sensors’ software. “As we add different radar modes and as we add different and capabilities to the DAS system and to the EOTS system, the timing is misaligned,” and then you have to reboot it. Bogdan said he’s aiming for eight to nine hours between such software failures when a radar or DAS or EOTS needs to be rebooted, which is what legacy aircraft boast. Right now they are at four to five hours between such events. “That’s not a good metric.”

Gravityloss 10y ago
I guess if you demand a lot of interaction between almost all systems, it's harder to ensure high levels of independence.
- arca_vorago 10y ago
  Welcome to the perils of globalism...
  - mlvljr 10y ago
    Coming to those less-developed on the wings of F-35s! :)
- ArkyBeagle 10y ago
  It's not hard at all - you buffer it and make the communications paths asynchronous. You allow dropped "packets" when necessary. I don't think you can enforce hard realtime constraints across subsystems and expect anything but tears.
  - Retric 10y ago
    Buffering is not such a great idea when your getting shot at.
    - ArkyBeagle 10y ago
      I'm not talking about buffering that breaks a time line. I'm talking about buffering to deal with something that can be modelled as essentially clock uncertainty.
ArkyBeagle 10y ago
Holy friggin crap. Can I buy a hardware timer, pls? I have to be reading this wrong - they can't even enforce the time budget for different tasks/threads under varied configurations? Don't nobody here know how to play this game?
- munin 10y ago
  > Don't nobody here know how to play this game? I guess all they need to do is hire "ArkyBeagle" from the comments section of hacker news, right?
  - rhizome 10y ago
    Maybe! What do we know?
  - deleted 10y ago
    [deleted]
  - ArkyBeagle 10y ago
    We tried that. It didn't work out :)
- Retric 10y ago
  Real issue is different company's building different systems and then trying to integrate them after the fact. Chances are good that several systems are involved no one team has source code for even 1/2 of them. So, this is probably a reasonable trade off to prevent something else braking or massively delaying the project. Don't forget this is a weapon decreasing latency by 0.0001 seconds might be worth a lot of pain.
  - aidenn0 10y ago
    They actually will have most of the source code for everything non-classified. However, they won't be allowed to change any of the software from other companies. This means getting a single bug fixed involves several con-calls with various levels of management at each company over the course of somewhere between two weeks and a few months. Double this at a minimum if the software wasn't developed in-house at the company that delivered it to you. In such an environment you very quickly get used to living with workarounds rather than bugfix. [edit] Oh, another thing I forgot that isn't universal, but is unfortunately too common. Dealing with managers after the bug is fixed asking why you spent time, and thereby the company's money fixing a bug in code that is the responsibility of another company.
chris_overseas 10y ago
I realise there's a difference between military and passenger, but the 787 Dreamliner had a problem that required a reset every 248 days and it made the headlines: http://arstechnica.com/information-technology/2015/05/boeing-787-dreamliners-contain-a-potentially-catastrophic-software-bug/ http://arstechnica.com/information-technology/2015/05/boeing... Based on the raw numbers the F-35 problem sounds a LOT worse?

Gravityloss 10y ago

I guess if you demand a lot of interaction between almost all systems, it's harder to ensure high levels of independence.

arca_vorago 10y ago
Welcome to the perils of globalism...
- mlvljr 10y ago
  Coming to those less-developed on the wings of F-35s! :)
ArkyBeagle 10y ago
It's not hard at all - you buffer it and make the communications paths asynchronous. You allow dropped "packets" when necessary. I don't think you can enforce hard realtime constraints across subsystems and expect anything but tears.
- Retric 10y ago
  Buffering is not such a great idea when your getting shot at.
  - ArkyBeagle 10y ago
    I'm not talking about buffering that breaks a time line. I'm talking about buffering to deal with something that can be modelled as essentially clock uncertainty.

ArkyBeagle 10y ago

Holy friggin crap. Can I buy a hardware timer, pls? I have to be reading this wrong - they can't even enforce the time budget for different tasks/threads under varied configurations? Don't nobody here know how to play this game?

munin 10y ago
> Don't nobody here know how to play this game? I guess all they need to do is hire "ArkyBeagle" from the comments section of hacker news, right?
- rhizome 10y ago
  Maybe! What do we know?
- deleted 10y ago
  [deleted]
- ArkyBeagle 10y ago
  We tried that. It didn't work out :)
Retric 10y ago
Real issue is different company's building different systems and then trying to integrate them after the fact. Chances are good that several systems are involved no one team has source code for even 1/2 of them. So, this is probably a reasonable trade off to prevent something else braking or massively delaying the project. Don't forget this is a weapon decreasing latency by 0.0001 seconds might be worth a lot of pain.
- aidenn0 10y ago
  They actually will have most of the source code for everything non-classified. However, they won't be allowed to change any of the software from other companies. This means getting a single bug fixed involves several con-calls with various levels of management at each company over the course of somewhere between two weeks and a few months. Double this at a minimum if the software wasn't developed in-house at the company that delivered it to you. In such an environment you very quickly get used to living with workarounds rather than bugfix. [edit] Oh, another thing I forgot that isn't universal, but is unfortunately too common. Dealing with managers after the bug is fixed asking why you spent time, and thereby the company's money fixing a bug in code that is the responsibility of another company.

chris_overseas 10y ago

I realise there's a difference between military and passenger, but the 787 Dreamliner had a problem that required a reset every 248 days and it made the headlines: http://arstechnica.com/information-technology/2015/05/boeing-787-dreamliners-contain-a-potentially-catastrophic-software-bug/ http://arstechnica.com/information-technology/2015/05/boeing... Based on the raw numbers the F-35 problem sounds a LOT worse?