How Facebook can deal with your data 99.6% faster than before

Data Centre

by Duncan MacRae| 17 July 2014

New data centre technology could reduce data-transmission delays across server farms by almost 100%.

MIT researchers have reduced the average queue length of routers in a Facebook data centre by 99.6% - virtually doing away with queues.

In their experiments, when network traffic was heavy, the average latency - the delay between the request for an item of information and its arrival - shrank nearly as much, from 3.56 microseconds to 0.23 microseconds.

Big websites usually maintain their own data centres, banks of tens or even hundreds of thousands of servers, all passing data back and forth to field users' requests.

Like any big, decentralised network, data centres are prone to congestion: Packets of data arriving at the same router at the same time are put in a queue, and if the queues get too long, packets can be delayed.

Like the Internet, most data centres use decentralised communication protocols: Each node in the network decides, based on its own limited observations, how rapidly to send data and which adjacent node to send it to. Decentralised protocols have the advantage of an ability to handle communication over large networks with little administrative oversight.

The MIT system, dubbed Fastpass, instead relies on a central server called an 'arbiter' to decide which nodes in the network may send data to which others during which periods of time.

Hari Balakrishnan, the Fujitsu Professor in Electrical Engineering and Computer Science and one of the paper's co-authors, said: "It's not obvious that this is a good idea."

With Fastpass, a node that wishes to transmit data first issues a request to the arbiter and receives a routing assignment in return.
Jonathan Perry, a graduate student in electrical engineering and computer science (EECS) and another of the paper's authors, said: "If you have to pay these maybe 40 microseconds to go to the arbiter, can you really gain much from the whole scheme? Surprisingly, you can."

Balakrishnan and Perry are joined on the paper by Amy Ousterhout, another graduate student in EECS; Devavrat Shah, the Jamieson Associate Professor of Electrical Engineering and Computer Science; and Hans Fugal of Facebook.

The researchers' experiments indicate that an arbiter with eight cores, or processing units, can keep up with a network transmitting 2.2 terabits of data per second. That's the equivalent of a 2,000-server data centre with gigabit-per-second connections transmitting at full bore all the time.

"This paper is not intended to show that you can build this in the world's largest data centers today," Balakrishnan said. "But the question as to whether a more scalable centralised system can be built, we think the answer is yes."

The key to Fastpass's efficiency is a technique for splitting up the task of assigning transmission times so that it can be performed in parallel on separate cores. The problem, Balakrishnan explained, is one of matching source and destination servers for each time slot.

He said: "If you were asked to parallelise the problem of constructing these matchings you would normally try to divide the source-destination pairs into different groups and put this group on one core, this group on another core, and come up with these iterative rounds. This system doesn't do any of that."

Instead, Fastpass assigns each core its own time slot, and the core with the first slot scrolls through the complete list of pending transmission requests. Each time it comes across a pair of servers, neither of which has received an assignment, it schedules them for its slot. All other requests involving either the source or the destination are simply passed on to the next core, which repeats the process with the next time slot. Each core thus receives a slightly attenuated version of the list the previous core analysed.

The MIT researchers will present their new network-management at the annual conference of the ACM Special Interest Group on Data Communication in August.

 

 

 

Comments
Post a comment

Comments may be moderated for spam, obscenities or defamation.
Privcy Policy

We have updated our privacy policy. In the latest update it explains what cookies are and how we use them on our site. To learn more about cookies and their benefits, please view our privacy policy. Please be aware that parts of this site will not function correctly if you disable cookies. By continuing to use this site, you consent to our use of cookies in accordance with our privacy policy unless you have disabled them.