rnxrx

In practice at the time I know we used Sparc 10 and Sparc 20 pizza boxes as servers. Until the various Ultras came out it was pretty common to see stacks of them running firewalls, dns (...and sometimes nis) or web servers next to the big iron running databases and such.

The 10 and 20 in particular had a much longer lifespan than a lot of folks realize. There were cheap (for the time) upgrades to put quad CPU's and a decent selection of SCSI HBA's, Ethernet NIC's and even some ATM interfaces. I know I still saw those units fairly commonly well into the mid 2000's.

In my experience the environment where the drives are running makes a huge difference in longevity. There's a ton more variability in residential contexts than in data center (or even office) space. Potential temperature and humidity variability is a notable challenge but what surprised me was the marked effect of even small amounts of dust.

Many years ago I was running an 8x500G array in an old Dell server in my basement. The drives were all factory-new Seagates - 7200RPM and may have been the "enterprise" versions (i.e. not cheap). Over 5 years I ended up averaging a drive failure every 6 months. I ran with 2 parity drives, kept spares around and RMA'd the drives as they broke.

I moved houses and ended up with a room dedicated to lab stuff. With the same setup I ended up going another 5 years without a single failure. It wasn't a surprise that the new environment was better, but it was surprising how much better a cleaner, more stable environment ended up being.

Maybe I'm missing something but wouldn't the paid-for check mark also mean that a given account can be more specifically targeted, thus increasing the potential ad revenue to Twitter?

The dilemma with these sorts of discussions always seems to come back to where the line is drawn between the personality and the disorder. Clearly there are some pathologies whose features manifest in ways that are dangerous (..to one's self and/or others) but it's not clear to me which of the criteria above rise from being facets of ordinary personalities and become truly pathological.

This seems to also coincide with other literature that describes those with SPD as being among the least likely to seek treatment.

Do countries with more billionaires inherently rank higher in terms of quality of life, or do billionaires tend to live in places that already have higher quality of life (...particularly for the wealthy)?

There were also a number of Usenet <-> FidoNet/echomail gateways. This was especially useful for local BBS users that weren’t affiliated with any university computing facilities.

Working from the 10K end-host number in the paper with a radix of 43 and 722 total router nodes, it’s the case that a given switch connects ~15 end-hosts. Fifteen downlinks to 43 uplinks seems pretty wasteful in its own right.

The numbers you cite are closer to realistic: a modified Clos fabric consisting of a four-way spine of 8-slot chassis with 36 100G blades connecting a full complement of 288 leaves, each with 4x100G up and 40x10G down (no oversubscription, at least nominally) leaves us with 11.5K hosts connected by a total of 292 switches. Even if the modular switches are 10X the cost of the ToR this is still markedly cheaper than 700+ ToR’s (and this doesn’t include actual power/cooling costs and the opportunity cost of space lost).

This also doesn’t include cabling/transceiver cost differences: 722 * 43 * 2 (62K) vs 288 * 4 * 2 (2.3K). That’s literally an order of magnitude difference.

Even if the design were approached using single-speed connections (ex: 48x10G up divided over 16 spines, 48x10G down locally) there’s still a pretty compelling numerical advantage to Clos: ~210 96x10G ToR’s and 16 16-slot chassis for 10K hosts is 226 devices and ~20K transceivers. If we assume the spines cost 10X the leaves then 370X is still almost half of 722X.

Routers absolutely do fragment packets (...at least those that don't have the DF bit set) but it's up to the receiving host to reassemble the fragments.

Possibly, but it's in the right neighborhood. It depends on whether we're counting from the time of design/initial fabrication or actual mass production and general sale.

The point is that 12.5Gb/s SerDes pretty much means they'd be practically to 10/40G. At least in the DC networking world this puts it several generations back.

This isn't really true in the market today. 100G switches have emerged at roughly the same cost per port as 40G from a couple of years ago and, indeed, can often accept both 40 and 100 gig optics. Even at list price the cost per port for 100G switching has been under $1K for more than a year.

As a result it's actually fairly common to find new DC fabrics (read: inter-switch connections, not end hosts) being built with 100G because there's no significant economic disadvantage to doing so. That said, the pricing for inter-site 100G is still high enough that it hasn't commonly made its way to smaller organizations.

As impressive as this is, it's likely 3-4 generations back from what's currently shipping. It's a switch-on-chip (SoC) set up for 12.5 Gbit SerDes. As pointed out elsewhere, it might have been deployed for 16 10G front panel ports, another 160G to a backplane ASIC and some of the remaining ports for control plane use.

Reading between the lines a bit it might have been used in one of the Nexus 5K's - which would put it at around 8 years old, depending on how we're counting.

It was "solved" in some general sense but was never implemented widely or consistently. It was traditionally a really clunky and fragile system (e-mail forms) that ended up being really limited in its utility because it wasn't widely used.

That said, the point isn't that this is a technically difficult problem (it isn't) but rather one of human scale: altering the behavior of tens of thousands of more-or-less autonomous networks spanning the globe is non-trivial.

Operational complexity. For a carrier the size of Verizon to build an authoritative list of prefixes to advertise they would have to have a registration process for every single customer, peer, etc that was both reliable and up to the minute. That list would have to be compiled and driven on a near constant basis to many tens of thousands of routers and potentially hundreds of thousands of BGP sessions.

It's not that this isn't doable, but it touches far more process in far more places than might be obvious and potentially requires additional capacity/capability on a lot of hardware. For a giant network this all means a great deal of time and money. Should they do it? Absolutely. Is it cheap/easy? Absolutely not. More cynically, does the potential cost and disruption of doing the right thing map favorably against their view of the risk of NOT doing it? Unknown.

It's been quite mainstream in certain contexts and geographies for a number of years now. As an example - most handsets on modern LTE (and newer) networks have been strong-majority v6 for quite a while. The fact that this hasn't been obvious is an argument in favor of v6's success.

The network piece seems kind of incomplete and outdated when compared to what's being discussed in terms of compute and storage. Most of the new networking fabrics being built at this point are 100G, with emerging server connectivity focusing on nx25G for in-rack. Longer-distance 25G is awaiting implementations of FEC but the currently shipping gear can do 3-5M - which is about ideal for top-of-rack. The economics and development cycles of these link-types tends to dictate that 40GE doesn't make sense for a new installation.

The call for "SDN" is incredibly nebulous - to the point of being almost meaningless, IMO. What the big guys tend to be after is a way to control the fabric via standardized API calls - so capability for YANG/NETCONF or some mechanism for direct access to SDE calls. The other thing that's not addressed is how to efficiently get information about the network out of the network. Traditional polled mechanisms (SNMP/RMON, et al) have been shown not to both lack scale and adequate resolution while legacy approaches to push telemetry (sFlow/Netflow) miss the mark in terms of level of detail and compatibility with large-scale data processing needs.

The next point is the selection of topology and the integration with multi-site planning. There's a lot of cool stuff happening in this regard and there seems to still be a pretty big disconnect between what the systems folks seem to understand and what's happening in the network industry, which is a shame because there's probably more opportunity for neat stuff (read: scalability, performance, fault resistance, manageability) than seems to be discussed (at least on HN).

Finally - there's a certain conventional wisdom among the systems and some sections of the programmer crowd that network control planes are just another mostly simple bit of software to be implemented. It's not. It's a hard problem and is the manifest reason why only a handful of organizations have been able to produce software that runs a meaningful percentage of large-scale L3 infrastructure in the world (hint: Arista is a great company but isn't included in this number quite yet). Truly rugged, useful/usefully-featured and performant network code is hard. Making that code work in the context of 30+ years of protocol implementations, morphing standards and a world of bad/clueful actors is REALLY hard. There's an inverse relationship between the amount of money spent on a solution and the amount of specialized expertise you have on staff. A more traditional commercial solution might be more expensive but it also relieves you of the need to keep some relatively rare, likely expensive and almost certainly non-revenue producing skill-sets off-staff.