Lambda the Ultimate on Why Multi-Core is Easy, Internet Hard

By Bryan Rasmussen
June 26, 2008

Lambda the Ultimate has a post up on "Why Multi-Core is Easy and Internet is Hard", It hits on some issues and servers, like Rest and Waterken with its capability based system over Rest so for that alone it is worth reading, but probably the greatest bit is this table made by Chris Rathman comparing architectures,
that table is based on the preceding post by Scott Johnson listing relevant issues, have to quote it:

Sequential code, private to an organization: * Determinstic scheduling: yes * Topology: Fixed. * Migration: N/A * Global consensus ("god's eye view"): yes * Partial failure: no * Malicious third parties: no * Malicious clients: no * Administrative domains: single * Bandwidth: Extremely high * Latency: Extremely low (nanoseconds to tens of nanoseconds)

Multithreaded code, private to an organization, running on a single CPU with pre-emption:
* Deterministic scheduling: no
* Topology: Fixed
* Migration: N/A
* Global consensus: yes
* Partial failure: no
* Malicious third parties: no
* Malicious clients: no
* Administrative domains: single
* Bandwidth: Extremely high.
* Latency: Extremely low (nanoseconds to tens of nanoseconds)

SMP/Multicore, private to an organization:
* Determinstic scheduling: no
* Topology: Extremely stable (occasional CPU upgrade in some systems)
* Migration: Trivial (one processor as good as another)
* Global consensus: Possible, though more expensive (cache coherency issues)
* Partial failure: no
* M3P: no
* MC: no
* Administrative domains: single
* Bandwidth: Extremely high
* Latency: Very low (tens to hundreds of nanoseconds, cache coherency, again)

NUMA architectures:
* Deterministic scheduling: no
* Topology: Very stable (occasional CPU upgrade in some systems)
* Migration: Somewhat trivial--support provided by underyling OS typically.
* Global consensus: Expensive, often "no"
* Partial failure: no
* M3P: no
* MC: no
* Administrative domains: single
* Bandwidth: Very high
* Latency: Low (hundreds of nanoseconds to microseconds)

Dedicated clusters with fixed topology, decoupled or isolated from an organization's intranet:

* Deterministic scheduling: no
* Topology: Stable-very stable (such systems are not reconfigured without good reason)
* Migration: somewhat difficult--though often supported by OS or grid/clustering software.
* Global consensus: No
* Partial failure: Yes, though uncommon and usually quickly detectable
* M3P: no
* MC: no
* Administrative domains: single (administrative responsibility may be subdivided, though there is usually one person "at the top")
* Bandwidth: High
* Latency: Medium-low (tens to hundreds of microseconds)

Intranets in general and similar private distributed systems

* Deterministic scheduling: no
* Topology: moderately stable (often changes to topology, though most are harmless or published in advance)
* Migration: difficult.
* Global consensus: No
* Partial failure: Yes, though somewhat uncommon and usually quickly detectable
* M3P: no
* MC: no
* Administrative domains: single (administrative responsibility may be subdivided, though there is usually one person "at the top")
* Bandwidth: High
* Latency: Medium (hundreds of microseconds to milliseconds or more)

Clusters, other loosely coupled systems, via a VPN (all nodes private to an organization, but over a public network; possibly with negotiated QoS)
* Deterministic scheduling: no
* Topology: moderately stable (often changes to topology, though most are harmless or published in advance). Topology of intermediate network is often a "don't care" and is abstracted away by VPN.
* Migration: difficult. Global consensus: No
* Partial failure: Yes
* M3P: yes, though modern VPN abtractions reduce the risk via transport-layer encryption (transparent to the application).
* MC: no
* Administrative domains: multiple. Nodes are technically under a single point of control, though geographically distributed sysadmins are often better modeled as multiple domains. Network service provider(s) are additional domains, though they are often required to provide some level of QoS even if best-effort.
* Bandwidth: Medium
* Latency: Medium (milliseconds to tens of milliseconds)

Distributed systems over the open internet, all nodes private to an organization:
* Deterministic scheduling: no
* Migration: difficult.
* Topology: unstable
* Partial failure: Yes
* Global consensus: No
* Partial failure: Yes, with fault isolation difficult.
* M3P: yes. In addition, some service providers may be hostile to some applications (ie BitTorrent).
* MC: no
* Administrative domains: multiple. Intermediate domains may be difficult to identify, intermediate service providers may be indifferent to endpoints.
* Bandwidth: Medium-low
* Latency: Low (tens to hnudreds of milliseconds)

External services over the open Internet:
* Deterministic scheduling: no
* Migration: difficult.
* Topology: very unstable; client nodes come and go at will.
* Global consensus: No
* Partial failure: Yes, with fault isolation very difficult.
* M3P: yes. In addition, some service providers may be hostile to some applications (ie BitTorrent).
* MC: yes. tons of them.
* Administrative domains: multiple, including clients under different domains.
* Bandwidth: Low, especially if client is over dialup or other low-bandwidth connection.
* Latency: Low to very low (hundreds of milliseconds or more)




You might also be interested in:


Popular Topics

Archives

Or, visit our complete archives.

Recommended for You

Got a Question?