Primarily latency. Now, ideally you'd like the entire subsystem moved off disk into volatile memory, but for some things you're going to have to read from disk. I can imagine cases where that wouldn't be easily feasible if the drive had NSA crypto.
"Regarding the Russians: Oh, I see, now. Yes, you're right that if country X cracks our encryption, we can't assume that they didn't get help from <insert China or Russia here>."
Right, but its more than that in the case of the Iranians. The Russians have a long and documented history of assistance to the Iranians and the Syrians.
for some things you're going to have to read from disk.
I'm not sure I follow. For some things you're going to have to _write_ to disk... like captured video. (I wouldn't consider that to be the "real-time" part of the software, though.) And you might have to read from disk occasionally... maybe you have map information stored there... but that probably doesn't need to be real-time. Can you tell me an example where you would need to read from disk in real-time? (Which I think should anyway be impossible, regardless of whether or not heavy crypto is being used.)
The Russians have a long and documented history of assistance to the Iranians and the Syrians.
Sure! Man I love when people on hn ask genuine questions rather than trying to one up one another. It's one of the reasons I was so reluctant to stop lurking for so long.
Much like the Mars rovers, the navigation system is loaded in a modular fashion, with complex algorithms for each scenario loaded on the fly. So for example, imagine a UAV goes into a stall. Likely the aircraft needs a whole new set of algorithms to recover. It's very likely I this case you'd need low latency disk reads. Now again, this is just a guess based upon my experience with similar systems. I've never developed a UAV system.
Man I love when people on hn ask genuine questions rather than trying to one up one another. It's one of the reasons I was so reluctant to stop lurking for so long.
Well then, you're exactly the kind of person we need to stop lurking and start participating, so welcome aboard. But yeah, I totally understand you.
this is just a guess based upon my experience with similar systems
You mean planetary rovers? If not, can you be more specific? I realize it's not necessarily wise to divulge too much industrial information. I actually have worked on UAVs... not to the point that I can say the scenario you're presenting is incorrect (I wasn't involved in that kind of stuff), but I don't think it's very plausible. I could see that strategy being more reasonable on a super memory-constrained device where the system is radiation hardened, like space equipment. I would think for a normal UAV, you'd just keep all the code (algorithms) you might need in memory.
Its possible I'm wrong. I've never designed a UAV flight system, so I was speculating as to reasons why a lower level of encryption might be needed. Its possible that's not a realistic constraint for atmospheric craft.
Comments
Primarily latency. Now, ideally you'd like the entire subsystem moved off disk into volatile memory, but for some things you're going to have to read from disk. I can imagine cases where that wouldn't be easily feasible if the drive had NSA crypto.
"Regarding the Russians: Oh, I see, now. Yes, you're right that if country X cracks our encryption, we can't assume that they didn't get help from <insert China or Russia here>."
Right, but its more than that in the case of the Iranians. The Russians have a long and documented history of assistance to the Iranians and the Syrians.
I'm not sure I follow. For some things you're going to have to _write_ to disk... like captured video. (I wouldn't consider that to be the "real-time" part of the software, though.) And you might have to read from disk occasionally... maybe you have map information stored there... but that probably doesn't need to be real-time. Can you tell me an example where you would need to read from disk in real-time? (Which I think should anyway be impossible, regardless of whether or not heavy crypto is being used.)
Yeah, very true, I have noticed that, too.
Sure! Man I love when people on hn ask genuine questions rather than trying to one up one another. It's one of the reasons I was so reluctant to stop lurking for so long.
Much like the Mars rovers, the navigation system is loaded in a modular fashion, with complex algorithms for each scenario loaded on the fly. So for example, imagine a UAV goes into a stall. Likely the aircraft needs a whole new set of algorithms to recover. It's very likely I this case you'd need low latency disk reads. Now again, this is just a guess based upon my experience with similar systems. I've never developed a UAV system.
Well then, you're exactly the kind of person we need to stop lurking and start participating, so welcome aboard. But yeah, I totally understand you.
You mean planetary rovers? If not, can you be more specific? I realize it's not necessarily wise to divulge too much industrial information. I actually have worked on UAVs... not to the point that I can say the scenario you're presenting is incorrect (I wasn't involved in that kind of stuff), but I don't think it's very plausible. I could see that strategy being more reasonable on a super memory-constrained device where the system is radiation hardened, like space equipment. I would think for a normal UAV, you'd just keep all the code (algorithms) you might need in memory.
Its possible I'm wrong. I've never designed a UAV flight system, so I was speculating as to reasons why a lower level of encryption might be needed. Its possible that's not a realistic constraint for atmospheric craft.