5 ms·

Docker containers in space

83 points by adunk 7y ago

deleted 7y ago
[deleted]
covermydonkey 7y ago
I wonder what timezone the containers think they're in?
- oszione 7y ago
  UTC
- nathankunicki 7y ago
  I would argue that all machines, on Earth or otherwise, should run on UTC! Only when interacting with a human should the output be converted to the local time of that human.
- LiamPa 7y ago
  Good question as time is slower in space..
  - DannyB2 7y ago
    Time is slower (relative to us) due to spacecraft being in motion (relative to us). But then time is faster (relative to us) because it is higher up in the gravity well. https://www.telegraph.co.uk/news/science/science-news/8020988/Einsteins-theory-of-relativity-works-on-a-human-scale-the-higher-you-are-the-faster-you-age.html https://www.telegraph.co.uk/news/science/science-news/802098... So which one wins out?
    - teraflop 7y ago
      Interestingly, it depends on your altitude. For objects in a low, fast orbit such as the ISS, time runs slower; in higher, slower orbits, such as GPS and geostationary communications satellites, time runs faster. In between these points, the effects cancel out at an altitude of roughly 3000km. https://en.wikipedia.org/wiki/Time_dilation#/media/File:Time_Dilation_vs_Orbital_Height.png https://en.wikipedia.org/wiki/Time_dilation#/media/File:Time... However, both effects can be ignored for almost all purposes. The effect of time dilation is less than 1 part per billion, which is basically undetectable without an atomic clock.
      - jononor 7y ago
        Yes, especially because clock drift on the crystals is several orders of magnitude higher. Often 10 parts per million, or more.
alpb 7y ago
Related: NASA has previously done some work with Kubernetes and Docker containers. https://www.nas.nasa.gov/SC17/demos/demo29.html https://www.nas.nasa.gov/SC17/demos/demo29.html It has happened on the ground, however.
lukejduncan 7y ago
Planet Labs runs Ubuntu on their Satellites. I wonder if there were any docker containers running on those or similar cubesats.
bsder 7y ago
For anyone who reads this, NEVER use an I2C bus on anything which needs reliability. Ever. Use CAN, preferably, or SPI, if nothing better. Even old school RS-232 is probably superior. I2C simply isn't reliable in harsh environments without extensions (I believe that there is an ESA paper on this somewhere). CAN, in particular, was built for harsh environments (automobiles).
- sgtnoodle 7y ago
  I2C is alright as long as it's on the same PCB and your code handles nacks and detects hung transfers. Running I2C through a connector is asking for trouble though.
- petrosagg 7y ago
  I'd be interested to hear about the failure modes of I2C that you've observed. Unfortunately I'm not familiar with CAN or SPI. Do these alternatives provide error correction as part of the protocol? Do they offer superior reliability in some other way?
  - sgtnoodle 7y ago
    SPI is similar to I2C in concept, but there's separate RX and TX data lines and a discrete "chip select" signal for addressing. The chips drive both high and low rather than relying on a pull-up, so SPI can operate significantly faster than I2C. CAN allows many nodes to communicate via broadcast messages on a shared twisted pair of wires called a bus. The signals are differential, making them fairly immune to noise. The messages are CRC'd and acked, and are automatically retransmitted as necessary. CAN is "content addressed" rather than addressed-to-recipient, and each message's address also acts as a priority for arbitration of the bus; the highest priority message ready to be written always gets the next opportunity to transmit. To make things annoying, messages can only contain 8 bytes of payload. I2C, SPI and CAN all have different purposes. I2C is nice for interfacing to low data rate chips because of the low signal count. SPI is nice for interfacing to high data rate chips but is 4 signals at least. CAN is nice for connecting microcontrollers that are far apart from each other. Folks abuse I2C because it's only two signals, and run it over connectors. The protocols built on top of I2C quickly fall apart when the signals are flaky, leading to firmware pain. SPI is harder to abuse because no one wants to run 4 comms signals over connectors, and typically at several MHz, electrical engineers know it's a bad idea. CAN is very robust when done correctly (good enough for drive by wire in cars), but it's also orders of magnitude more complicated. The typical way to add CAN to a raspberry pi is an MCP2515 chip. The linux driver for the MCP2515 can barely service the chip fast enough though, which means it tends to drop data at the higher bitrates.
nategri 7y ago
Both comforted and alarmed to see all that perfboard in something that crossed the Karman line.
Rebelgecko 7y ago
It's interesting that it doesn't sound like they're using any sort of watchdog to detect for things locking up, and they're using SD cards for their "read only" filesystem. I suppose it's less of an issue for sounding rockets
- petrosagg 7y ago
  balena founder here. balenaOS does use the hardware watchdog available on the raspberry pi to detect CPU lock ups and automatically reset the board. On top of that we're also running software watchdogs that check the health of key system components and restart them if they become unhealthy. It's true that SD cards are known for getting corrupt. balenaOS separates the partitions of the device and keeps the userspace in a readonly one while keeping mutable OS state in a separate partition. We are very conscious of writing as infrequently as possible to the SD card for this reason. The partition that accepts the most writes is the one holding the user container, which will get written to during an update, and also in case the user container stores any data on the device. I'm aware that SD cards will internally swap blocks and don't really care about partition boundaries but assuming you're using an SD card with a well designed firmware it shouldn't lose a block during wear leveling. That said, the SD card problem is one reasons we designed balenaFin :)
  - sgtnoodle 7y ago
    I've personally seen many dozens of SD cards fail such that they don't even know their own sector count anymore. My suspicion is that in-progress wear leveling operations aren't rebust to sudden power loss (ejecting card without unmounting it). Most likely firmware specific...
    - petrosagg 7y ago
      Yes, and this problem is exacerbated by the raspberrypi's microUSB power input. We've seen countless number of cases where a Pi exhibiting SD card corruption was also experiencing undervoltage. If you're using raspberrypis in production it's paramount to have a good microUSB cable and power supply
jt2190 7y ago
Related: In 17 days the door closes on StackBlitz’s payload of a RaspberryPi server hosting 1000 web apps [1], so if you’ve got something you want in orbit, act now. > the plan is to broadcast a public wifi hotspot that passerby aliens can tap into while their teleporter beam slowly slurps up unsuspecting humans [1] https://deployto.space/ https://deployto.space/
heelix 7y ago
Crazy how fast that sounding rocket was at launch. I don't think I'd ever seen one before... and man, did that move with purpose.

83 points by adunk 7y ago

deleted 7y ago

[deleted]

covermydonkey 7y ago

I wonder what timezone the containers think they're in?

oszione 7y ago
UTC
nathankunicki 7y ago
I would argue that all machines, on Earth or otherwise, should run on UTC! Only when interacting with a human should the output be converted to the local time of that human.
LiamPa 7y ago
Good question as time is slower in space..
- DannyB2 7y ago
  Time is slower (relative to us) due to spacecraft being in motion (relative to us). But then time is faster (relative to us) because it is higher up in the gravity well. https://www.telegraph.co.uk/news/science/science-news/8020988/Einsteins-theory-of-relativity-works-on-a-human-scale-the-higher-you-are-the-faster-you-age.html https://www.telegraph.co.uk/news/science/science-news/802098... So which one wins out?
  - teraflop 7y ago
    Interestingly, it depends on your altitude. For objects in a low, fast orbit such as the ISS, time runs slower; in higher, slower orbits, such as GPS and geostationary communications satellites, time runs faster. In between these points, the effects cancel out at an altitude of roughly 3000km. https://en.wikipedia.org/wiki/Time_dilation#/media/File:Time_Dilation_vs_Orbital_Height.png https://en.wikipedia.org/wiki/Time_dilation#/media/File:Time... However, both effects can be ignored for almost all purposes. The effect of time dilation is less than 1 part per billion, which is basically undetectable without an atomic clock.
    - jononor 7y ago
      Yes, especially because clock drift on the crystals is several orders of magnitude higher. Often 10 parts per million, or more.

alpb 7y ago

Related: NASA has previously done some work with Kubernetes and Docker containers. https://www.nas.nasa.gov/SC17/demos/demo29.html https://www.nas.nasa.gov/SC17/demos/demo29.html It has happened on the ground, however.

lukejduncan 7y ago

Planet Labs runs Ubuntu on their Satellites. I wonder if there were any docker containers running on those or similar cubesats.

bsder 7y ago

For anyone who reads this, NEVER use an I2C bus on anything which needs reliability. Ever. Use CAN, preferably, or SPI, if nothing better. Even old school RS-232 is probably superior. I2C simply isn't reliable in harsh environments without extensions (I believe that there is an ESA paper on this somewhere). CAN, in particular, was built for harsh environments (automobiles).

sgtnoodle 7y ago
I2C is alright as long as it's on the same PCB and your code handles nacks and detects hung transfers. Running I2C through a connector is asking for trouble though.
petrosagg 7y ago
I'd be interested to hear about the failure modes of I2C that you've observed. Unfortunately I'm not familiar with CAN or SPI. Do these alternatives provide error correction as part of the protocol? Do they offer superior reliability in some other way?
- sgtnoodle 7y ago
  SPI is similar to I2C in concept, but there's separate RX and TX data lines and a discrete "chip select" signal for addressing. The chips drive both high and low rather than relying on a pull-up, so SPI can operate significantly faster than I2C. CAN allows many nodes to communicate via broadcast messages on a shared twisted pair of wires called a bus. The signals are differential, making them fairly immune to noise. The messages are CRC'd and acked, and are automatically retransmitted as necessary. CAN is "content addressed" rather than addressed-to-recipient, and each message's address also acts as a priority for arbitration of the bus; the highest priority message ready to be written always gets the next opportunity to transmit. To make things annoying, messages can only contain 8 bytes of payload. I2C, SPI and CAN all have different purposes. I2C is nice for interfacing to low data rate chips because of the low signal count. SPI is nice for interfacing to high data rate chips but is 4 signals at least. CAN is nice for connecting microcontrollers that are far apart from each other. Folks abuse I2C because it's only two signals, and run it over connectors. The protocols built on top of I2C quickly fall apart when the signals are flaky, leading to firmware pain. SPI is harder to abuse because no one wants to run 4 comms signals over connectors, and typically at several MHz, electrical engineers know it's a bad idea. CAN is very robust when done correctly (good enough for drive by wire in cars), but it's also orders of magnitude more complicated. The typical way to add CAN to a raspberry pi is an MCP2515 chip. The linux driver for the MCP2515 can barely service the chip fast enough though, which means it tends to drop data at the higher bitrates.

nategri 7y ago

Both comforted and alarmed to see all that perfboard in something that crossed the Karman line.

Rebelgecko 7y ago

It's interesting that it doesn't sound like they're using any sort of watchdog to detect for things locking up, and they're using SD cards for their "read only" filesystem. I suppose it's less of an issue for sounding rockets

petrosagg 7y ago
balena founder here. balenaOS does use the hardware watchdog available on the raspberry pi to detect CPU lock ups and automatically reset the board. On top of that we're also running software watchdogs that check the health of key system components and restart them if they become unhealthy. It's true that SD cards are known for getting corrupt. balenaOS separates the partitions of the device and keeps the userspace in a readonly one while keeping mutable OS state in a separate partition. We are very conscious of writing as infrequently as possible to the SD card for this reason. The partition that accepts the most writes is the one holding the user container, which will get written to during an update, and also in case the user container stores any data on the device. I'm aware that SD cards will internally swap blocks and don't really care about partition boundaries but assuming you're using an SD card with a well designed firmware it shouldn't lose a block during wear leveling. That said, the SD card problem is one reasons we designed balenaFin :)
- sgtnoodle 7y ago
  I've personally seen many dozens of SD cards fail such that they don't even know their own sector count anymore. My suspicion is that in-progress wear leveling operations aren't rebust to sudden power loss (ejecting card without unmounting it). Most likely firmware specific...
  - petrosagg 7y ago
    Yes, and this problem is exacerbated by the raspberrypi's microUSB power input. We've seen countless number of cases where a Pi exhibiting SD card corruption was also experiencing undervoltage. If you're using raspberrypis in production it's paramount to have a good microUSB cable and power supply

jt2190 7y ago

Related: In 17 days the door closes on StackBlitz’s payload of a RaspberryPi server hosting 1000 web apps [1], so if you’ve got something you want in orbit, act now. > the plan is to broadcast a public wifi hotspot that passerby aliens can tap into while their teleporter beam slowly slurps up unsuspecting humans [1] https://deployto.space/ https://deployto.space/

heelix 7y ago

Crazy how fast that sounding rocket was at launch. I don't think I'd ever seen one before... and man, did that move with purpose.