vrv

linux-microsecondrto

Systems & Infrastructure2011–2013

vrv / linux-microsecondrto

linux-microsecondrto

Linux patches to support microsecond granularity RTOs in datacenters.

Systems & Infrastructure Hardware & Embedded

Explore on GitHub Read Hacker News discussions

3Distinct people

4Mentions

0Explicit recommenders

16GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Linux patches to support microsecond granularity RTOs in datacenters.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month4 dated mentions

Observed mentions: 2011-06-06 18:04:57 UTC to 2013-08-06 06:46:23 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
Jun 2011	2011-06-01 00:00:00 UTC	2011-07-01 00:00:00 UTC	1	1
Jul 2011	2011-07-01 00:00:00 UTC	2011-08-01 00:00:00 UTC	0	0
Aug 2011	2011-08-01 00:00:00 UTC	2011-09-01 00:00:00 UTC	0	0
Sep 2011	2011-09-01 00:00:00 UTC	2011-10-01 00:00:00 UTC	0	0
Oct 2011	2011-10-01 00:00:00 UTC	2011-11-01 00:00:00 UTC	0	0
Nov 2011	2011-11-01 00:00:00 UTC	2011-12-01 00:00:00 UTC	0	0
Dec 2011	2011-12-01 00:00:00 UTC	2012-01-01 00:00:00 UTC	0	0
Jan 2012	2012-01-01 00:00:00 UTC	2012-02-01 00:00:00 UTC	1	1
Feb 2012	2012-02-01 00:00:00 UTC	2012-03-01 00:00:00 UTC	0	0
Mar 2012	2012-03-01 00:00:00 UTC	2012-04-01 00:00:00 UTC	0	0
Apr 2012	2012-04-01 00:00:00 UTC	2012-05-01 00:00:00 UTC	0	0
May 2012	2012-05-01 00:00:00 UTC	2012-06-01 00:00:00 UTC	0	0
Jun 2012	2012-06-01 00:00:00 UTC	2012-07-01 00:00:00 UTC	0	0
Jul 2012	2012-07-01 00:00:00 UTC	2012-08-01 00:00:00 UTC	0	0
Aug 2012	2012-08-01 00:00:00 UTC	2012-09-01 00:00:00 UTC	0	0
Sep 2012	2012-09-01 00:00:00 UTC	2012-10-01 00:00:00 UTC	0	0
Oct 2012	2012-10-01 00:00:00 UTC	2012-11-01 00:00:00 UTC	0	0
Nov 2012	2012-11-01 00:00:00 UTC	2012-12-01 00:00:00 UTC	0	0
Dec 2012	2012-12-01 00:00:00 UTC	2013-01-01 00:00:00 UTC	1	1
Jan 2013	2013-01-01 00:00:00 UTC	2013-02-01 00:00:00 UTC	0	0
Feb 2013	2013-02-01 00:00:00 UTC	2013-03-01 00:00:00 UTC	0	0
Mar 2013	2013-03-01 00:00:00 UTC	2013-04-01 00:00:00 UTC	0	0
Apr 2013	2013-04-01 00:00:00 UTC	2013-05-01 00:00:00 UTC	0	0
May 2013	2013-05-01 00:00:00 UTC	2013-06-01 00:00:00 UTC	0	0
Jun 2013	2013-06-01 00:00:00 UTC	2013-07-01 00:00:00 UTC	0	0
Jul 2013	2013-07-01 00:00:00 UTC	2013-08-01 00:00:00 UTC	0	0
Aug 2013	2013-08-01 00:00:00 UTC	2013-09-01 00:00:00 UTC	1	1

What Hacker News says

4 sources

ballard·Aug 6, 2013

Looks like incast. Here's an in-depth article http://www.snookles.com/slf-blog/2012/01/05/tcp-incast-what-... Check out these patches extracted from the original paper site for 2.6/3.0rc kernel lines https://github.com/vrv/linux-microsecondrto

In Obscure kernel settings to increase performance of Linux TCP servers

vrv·Dec 29, 2012

The degenerate/extreme/unrealistic case of Incast is you have switch buffer capacity to store N segments, you talk to M servers that each return one segment, and M >> N. Although RTO is calculated based on RTT and RTTVAR, in the extreme case you can get clumps (and waves) of retransmissions (depending on the properties of the network) such that even eliminating the minRTO altogether may not solve the problem at some scale. In simulation we experimented with adding an adaptive staggering to the exponential backoff algorithm and found that it helped at high server counts [1], but it was only simulation so I'd take that approach with a grain of salt. The R2D2 work is pretty neat: different than a lot of other approaches I've seen. I'm excited to see how the FPGA implemention works! Some comments: 1) I think any significant change to the co

Read the rest

ntrol algorithm requires careful analysis: the variance in throughput with the multi-client experiment looks interesting, though I don't know whether that is steady state. From the graphs, R2D2 suffers more with larger filesizes whereas TCP actually improves. 2) Real datacenters can have very different traffic patterns that can break some of the assumptions about bandwidth uniformity and latency, though it's harder for academics to tackle that. 3) If you are going down the path of TCP offload, you presumably can avoid the overhead of CPU interrupts/timer programming when reducing the RTO into microseconds :). I'd be interested in seeing how R2D2's algorithms/constants work when you're able to reduce the 3ms timer to microseconds in hardware! Also, if some kernel programmer wants to fix my once-working patch to support microsecond-granularity TCP retransmissions [2], I personally know a bunch of people who would be happy :) [1] http://vijay.vasu.org/static/papers/sigcomm147-vasudevan.pdf [2] https://github.com/vrv/linux-microsecondrto

In TCP incast: What is it? How can it affect Erlang applications?

newman314·Jan 24, 2012

Ninja commenting here... After more digging, I was able to find this. If you scroll all the way to the end, there is some verbiage about just setting TCP_RTO_MIN to 1. However, the author claims this causes issues with delayed ACK unless another (missing) patch is applied. https://github.com/vrv/linux-microsecondrto http://www.pdl.cmu.edu/PDL-FTP/Storage/sigcomm147-vasudevan....

In Let's make TCP faster

vrv·Jun 6, 2011

This work is really cool and is attacking an important problem in a lot of datacenter networks. It's also great that they've released the source code too. As someone who's worked on this problem, I encourage those interested in reading up more about this. Here are a few papers on the problem in chronological order: 1. Original paper briefly talking about the "incast" TCP problem in storage environments: http://portal.acm.org/citation.cfm?id=1049998 2. Our follow up work on that problem from a few years back: Measurement paper ( http://portal.acm.org/citation.cfm?id=1364825 ) and our initial solution ( http://portal.acm.org/citation.cfm?id=1592604 ) with a microsecond retransmission Linux patch here: https://github.com/vrv/linux-microsecondrto 3. Another paper talking about Incast in Datacenter environments, focusing on a different for

Read the rest

m of the workload: http://portal.acm.org/citation.cfm?id=1592693 4. RAMCloud - a project that briefly talks about the need for low-latency transports: http://www.stanford.edu/~ouster/cgi-bin/papers/ramcloud.pdf 5. ICTCP - paper from last year that tries to solve the Incast problem using receiver advertised window algorithms: http://conferences.sigcomm.org/co-next/2010/CoNEXT_papers/13... DCTCP tries to go beyond solving the Incast problem and focuses on trying to control buffer occupancy in datacenter environments that contain both long flows and bursty flows. I think these papers all assume lossy link layers (Ethernet), but there are standards and other technologies (Datacenter Ethernet, Myrinet, Infiniband) that aim for lossless link layers to make the transport problem easier, but come with various other drawbacks today (cost, compatibility, etc.). In the meantime, I hope DCTCP or the microsecond TCP patch prove useful in solving some of these problems.

In DCTCP: TCP optimized for lower latency in Data Centers