Category: archived
Distributed consensus involves organizing a collection of independent agents – processes or network sites – to agree on some value or sequence of values. Many distributed consensus methods depend on a leader-follower scheme in which the leader is an agent that essentially tells the followers what the values are. The challenges in such methods are to determine when enough of the followers have accepted the value and how to recover from failures of agents. In particular, failures of the leader trigger some procedure to select a new leader. Leader election, however, is a distributed consensus problem. In fact, leader election is the harder problem. Once there is a leader, consensus in the followers can be produced by a dead simple protocol (see the second part of this ). Oddly, leader election is generally treated as a minor issue. For example, in “Paxos made simple” we read:
The famous result of Fischer, Lynch, and Patterson [1] implies that a reliable algorithm for electing a proposer must use either randomness or real time—for example, by using timeouts. However, safety is ensured regardless of the success or failure of the election.
The FLP result is essentially a tautology: if an agent doesn’t ever get any information that reliably distinguishes between failure and slow response in a second agent, the first agent cannot reliably distinguish between failure of the second agent and slow response. So the import of the first sentence is that leader election depends on timeouts or “randomness” (perhaps this means some analysis of probability of failure scenarios). I don’t think this is correct, but it’s an interesting claim. The second sentence says nothing more than that an algorithm that fails to progress will never produce a false result – which I think is also a dubious claim.
Algorithm P solves problem X by assuming some other mechanism solves X and then by using that mechanism to make problem X simpler. Ok.
State equations
Download paper.
And like Intel, I would argue that mobile software companies are instrumental in making silicon solutions pervasive, because they tick two major check boxes: reference design and support.
The hidden asset of mobile software companies
Mobile embedded software companies (e.g. Myriad, Access, Aplix, NXP software, Azingo) have a unique understanding of products as a hardware/software system. They understand how silicon can be leveraged, encapsulated and productised to fast-track device delivery. Beyond specific IP, these companies have the capability to build the very first product that will feature a new chipset. This is the reference design check box.A reference design is not a half-baked breadboard; it is a scale 1:1 device, ready to ship.
The absence of such capability has drained Texas Instrument, once the mobile silicon leader. Alternatively, true reference design has been instrumental in the success of Qualcomm and Mediatek.(cite)
Also see previous note
If anything, Wind River’s inability to breakout, despite a once Microsoft-like position of dominance, is a by-product of their failure to meaningfully go “up the stack” and away from their historical focus on the silicon layer as a primary differentiation point.
In other words, if Wind River had enabled the next generation of Cisco and Apple killers by providing more differentiated OEM-in-a-Box offerings, ala what Google is now trying to do with Android, they would not be staring at a $900M market cap and relatively flat revenues, margins and stock price.
Well, that’s an argument. Embedded is a tough beat, but Wind did not exactly set the world on fire developing new concepts and software. Intel’s history in software is not glorious either – so it’s going to be an interesting challenge for the new entity.