23 ms·

https://www.microsoft.com/en-us/research/uploads/prod/2016/12/On-the-Glitch-Phenomenon.pdf https://www.microsoft.com/en-us/research/uploads/prod/2016/1... The

https://www.microsoft.com/en-us/research/uploads/prod/2016/12/On-the-Glitch-Phenomenon.pdf https://www.microsoft.com/en-us/research/uploads/prod/2016/1... The author specifically addressed “noise” in another paper. In this paper, the predecessor to the one linked, the author shows that noise doesn’t fix the problem, rather it makes it impossible to determine which inputs would make it hang for an arbitrary amount of time.

mannykannot 7y ago
Are you referring to this passage? 2. Introducing noise to drive the device out of its metastable state.The noise can be considered to be just an unpredictable input.The introduction of noise cannot eliminate the possibility of the device hanging up for an arbitrarily long time, but can make it impossible to predict which inputs will cause it to do so. While I do not disagree, introducing noise changes the issue from being stuck forever on a single decision, to being a series of decision points (each time the noise signal changes), with the chain being broken as soon as one results in a definite outcome. In practice, this allows us to engineer the risk of being stuck, for longer than some specified period, to an arbitrarily small probability - at the cost of a small loss of precision, and possibly much greater complexity in modeling the device.
- senderista 7y ago
  Coincidentally, this is reminiscent of the usual solution to Paxos liveness violations: introduce randomness into the timing of the competing proposals.
  - shakezula 7y ago
    True! Wouldn’t be surprised if that’s why Lamport was originally thinking about the problem.
- aj7 7y ago
  No no no! Using noise is useless without hysteresis. You must have a process, built in, which prevents re-decision or waffling for a time sufficient that conditions are so changed as to eliminate the original decision. Once you stop, you stop long enough for the train to pass. Or you close your eyes and floor it, and stand on the accelerator.
aj7 7y ago
In actual practice, do you think he’s right?
- shakezula 7y ago
  I think it's an interesting proof in the context of distributed systems where delays can be interpreted in any number of different ways, and the paper shows pretty concretely the existence of at least one of these delay-causing inputs. In most practical scenarios it's not an issue, sure, but I don't think that's what the author was trying to get across as the point of this.

mannykannot 7y ago

Are you referring to this passage? 2. Introducing noise to drive the device out of its metastable state.The noise can be considered to be just an unpredictable input.The introduction of noise cannot eliminate the possibility of the device hanging up for an arbitrarily long time, but can make it impossible to predict which inputs will cause it to do so. While I do not disagree, introducing noise changes the issue from being stuck forever on a single decision, to being a series of decision points (each time the noise signal changes), with the chain being broken as soon as one results in a definite outcome. In practice, this allows us to engineer the risk of being stuck, for longer than some specified period, to an arbitrarily small probability - at the cost of a small loss of precision, and possibly much greater complexity in modeling the device.

senderista 7y ago
Coincidentally, this is reminiscent of the usual solution to Paxos liveness violations: introduce randomness into the timing of the competing proposals.
- shakezula 7y ago
  True! Wouldn’t be surprised if that’s why Lamport was originally thinking about the problem.
aj7 7y ago
No no no! Using noise is useless without hysteresis. You must have a process, built in, which prevents re-decision or waffling for a time sufficient that conditions are so changed as to eliminate the original decision. Once you stop, you stop long enough for the train to pass. Or you close your eyes and floor it, and stand on the accelerator.

aj7 7y ago

In actual practice, do you think he’s right?

shakezula 7y ago
I think it's an interesting proof in the context of distributed systems where delays can be interpreted in any number of different ways, and the paper shows pretty concretely the existence of at least one of these delay-causing inputs. In most practical scenarios it's not an issue, sure, but I don't think that's what the author was trying to get across as the point of this.