3 ms·

What's the difference between "reliable" and "accurate"? In any case, I have seen enough of these "A, B, C : pick N" (where 0 < N < 3) mantras shot down (usual

by bmer 3y ago

What's the difference between "reliable" and "accurate"? In any case, I have seen enough of these "A, B, C : pick N" (where 0 < N < 3) mantras shot down (usually by re-examining whether the constraints/assumptions of the original mantra apply in a specific situation, or just through plain algorithmic engineering) that whenever someone drops something like this, I mostly tune it out. In the case of distributed network <anything>, implementing programs in languages that help you manage important invariants automatically (and preferably not at run-time, but at compile-time) is key in creating robust systems that are both reliable, and fast. But if you have such tools, and you are trying to also meet a set of standards that were designed without any care for distributed computing, then...yeah.

abwizz 3y ago
maybe helpful https://en.wikipedia.org/wiki/CAP_theorem https://en.wikipedia.org/wiki/CAP_theorem
- bmer 3y ago
  Is this a theorem, or a rule of thumb? I can't quite tell, because I thought theorems had proofs to go along with them?
  - eru 3y ago
    You can prove it, if you pick some assumptions.
robertlagrant 3y ago
I think they probably are misremembering consistency, partition-tolerance, availability; pick 2.
- throwawaaarrgh 3y ago
  No, I'm familiar with CAP. My theorem is different. Reliable: A system can be available but not reliable; if a machine is down 6 minutes every hour, it's 90% availabile but less than 1 hour reliable. A networked distributed system can be reliable but not accurate if you keep it online while it slowly accrues errors, such as the mentioned link/unlink race condition. The machine still works, it just has occasional corruption. It tends not to be very fast if it's reliable. Fast: You can do whatever you want quickly. Think UDP, or filesystems that don't commit their log journal frequently. Tends not to be reliable or accurate. Accurate: Whatever you do has no corrupted state. Think ACID. Most systems don't do this because it's expensive/complicated.
  - robertlagrant 3y ago
    Apologies - fair enough. I can't quite tell if that is a genuine set of three alternatives or not[0], but I sort of see your point. Couple of unsure places: > Think ACID. Most systems don't do this because it's expensive/complicated. Is this true? A lot of systems are built on databases. > Accurate: Whatever you do has no corrupted state How does accuracy work if the system is distributed and there's a partition, and two node get different data? Presumably it's reliable if they're different, as accuracy is a different item? > Fast: You can do whatever you want quickly. Think UDP, or filesystems that don't commit their log journal frequently. Tends not to be reliable or accurate. Why wouldn't this be reliable?
    - throwawaaarrgh 3y ago
      Most databases aren't ACID compliant, and even if they can be, they're often used in a non-ACID way. > How does accuracy work if the system is distributed and there's a partition, and two node get different data? You don't allow writes during a partition. All nodes (or a quorum) must confirm on each write, and if that fails then a partition is detected. Everything that was accidentally written before you detected partition is thrown away. Usually you just have one writer node for simplicity. > Fast: > Why wouldn't this be reliable? If you prioritize reliability you will need a slower method to ensure reliability. TCP is slower than UDP so it can be reliable.
      - robertlagrant 3y ago
        > You don't allow writes during a partition. All nodes (or a quorum) must confirm on each write, and if that fails then a partition is detected. Everything that was accidentally written before you detected partition is thrown away. Usually you just have one writer node for simplicity. Wouldn't this be done better with a majority/minority approach, where if enough nodes are still communicating then they still work? > If you prioritize reliability you will need a slower method to ensure reliability. TCP is slower than UDP so it can be reliable. Agree - that is true in the TCP sense of the word reliable. But in your sense of the word, as I understood it, the TCP/UDP difference is more like "accuracy", is it not? Reliability is more like availability, as I read it in your previous comment.

by bmer 3y ago

abwizz 3y ago

maybe helpful https://en.wikipedia.org/wiki/CAP_theorem https://en.wikipedia.org/wiki/CAP_theorem

bmer 3y ago
Is this a theorem, or a rule of thumb? I can't quite tell, because I thought theorems had proofs to go along with them?
- eru 3y ago
  You can prove it, if you pick some assumptions.

robertlagrant 3y ago

I think they probably are misremembering consistency, partition-tolerance, availability; pick 2.

throwawaaarrgh 3y ago
No, I'm familiar with CAP. My theorem is different. Reliable: A system can be available but not reliable; if a machine is down 6 minutes every hour, it's 90% availabile but less than 1 hour reliable. A networked distributed system can be reliable but not accurate if you keep it online while it slowly accrues errors, such as the mentioned link/unlink race condition. The machine still works, it just has occasional corruption. It tends not to be very fast if it's reliable. Fast: You can do whatever you want quickly. Think UDP, or filesystems that don't commit their log journal frequently. Tends not to be reliable or accurate. Accurate: Whatever you do has no corrupted state. Think ACID. Most systems don't do this because it's expensive/complicated.
- robertlagrant 3y ago
  Apologies - fair enough. I can't quite tell if that is a genuine set of three alternatives or not[0], but I sort of see your point. Couple of unsure places: > Think ACID. Most systems don't do this because it's expensive/complicated. Is this true? A lot of systems are built on databases. > Accurate: Whatever you do has no corrupted state How does accuracy work if the system is distributed and there's a partition, and two node get different data? Presumably it's reliable if they're different, as accuracy is a different item? > Fast: You can do whatever you want quickly. Think UDP, or filesystems that don't commit their log journal frequently. Tends not to be reliable or accurate. Why wouldn't this be reliable?
  - throwawaaarrgh 3y ago
    Most databases aren't ACID compliant, and even if they can be, they're often used in a non-ACID way. > How does accuracy work if the system is distributed and there's a partition, and two node get different data? You don't allow writes during a partition. All nodes (or a quorum) must confirm on each write, and if that fails then a partition is detected. Everything that was accidentally written before you detected partition is thrown away. Usually you just have one writer node for simplicity. > Fast: > Why wouldn't this be reliable? If you prioritize reliability you will need a slower method to ensure reliability. TCP is slower than UDP so it can be reliable.
    - robertlagrant 3y ago
      > You don't allow writes during a partition. All nodes (or a quorum) must confirm on each write, and if that fails then a partition is detected. Everything that was accidentally written before you detected partition is thrown away. Usually you just have one writer node for simplicity. Wouldn't this be done better with a majority/minority approach, where if enough nodes are still communicating then they still work? > If you prioritize reliability you will need a slower method to ensure reliability. TCP is slower than UDP so it can be reliable. Agree - that is true in the TCP sense of the word reliable. But in your sense of the word, as I understood it, the TCP/UDP difference is more like "accuracy", is it not? Reliability is more like availability, as I read it in your previous comment.