Slashdot Mirror
The 100-Million Mile Network
mykepredko writes "eWeek has an article on the network and radio topography of the two Mars rovers and how they communicate with satellites in Mars' orbit as well as the Earth. The article ends by giving four rules for maintaining a space network, a) Automate processes, b) Bulletproof your gear, c) Be persistent and d) Simulate potential problems, which are probably good rules for any network."
It appears that one of the direct results of NASA research will be better networks, both on Earth and elsewhere. Just about anything and everything applied to a deep space network can be applied right here at home. I'm also wondering about wireless network tech resulting from all of this.
Considering how enthralled we are about seeing Mars up close and personal now, I'd think this would be a Really Good Idea.
This sig no verb.
Good stuff :) And true enough. But basically all four of the rules are pretty straight forward and don't have to be said. The problem is in an organization like that, they have to be said. Otherwise there's no accountability. If something goes wrong and they did no simulations then they can just say "Well, we never had that in our guidelines so we didn't do it". With it written down, now there is a accountability.
Something tells me that the communications aren't encrypted or authenticated.
Your last paragraph should tell you otherwise.
If someone did manage to DoS or somehow log in to the rover and damage the software it could be the most damaging single-target attack (dollar wise - at over $400 million per rover) of all time. I think that's kind of scary.
or did they not talk much about space networking? I want to know what protocols they use, how data is buffered on the sats orbiting mars, etc. Where are the technical details?
Error: Id10t detected
Heck, the RS/6000 has been around long enough, I'd say its more like the grandfather of those used in macs...
I was wondering if NASA has actually disclosed the details of what they believe was the malfunction of the Spirit rover?
As someone who has developed backup and recovery systems for embedded systems using vxWorks and flash memory I have my own theory of what could have gone wrong.
There is an intermitant problem that can occur when using a combination of vxWorks 5.5, dosFs2 and flash memory.
The problem goes like this : When file A is written to flash memory formatted with a FAT16 table the FAT table is updated to say which disk clusters are occupied by file A, and hence no longer available as free disk space. So when file B starts writing to the hard disk it checks what clusters are free to write to.
Now a timing problem can occur when a process writing files in a sequential order closes the file handle to A and opens a new handle for B and starts writting to B. The problem exists because the clusters used by A have not been updated to the FAT in time before file B starts writing. The consequence of this is that some of the data belonging to A is overwritten hence breaking the chain. Once this has occurred the FAT and file A cluster chain are corrupt. Once this corruption occurs more corruptions occur with rate of corruption errors growing expotentially until the flash memory can longer function for disk I/O.
Now as the problem only occurs rarely it is very hard to reproduce in a lab. Also as the rate of corruption is expotential then catching the orginal culprit is even harder. I have spent weeks just trying to catch and diagnosis the problem before eventually catching it.
Unfortunately once the flash had started to become corrupt the only way to correct it was to reformat the flash memory.
As for solving the problem, before closing the handle of a file that had been written to flash memory was done an ioctl call would be made to the dosFs2 library to write the size of the file to the disk. Once this solution was is in place the problem never raised its head again.