FaRM: Fast Remote Memory
Networked Systems Design and Implementation, 2014 · paper · Computer science
Describes FaRM, a main-memory distributed computing platform that uses RDMA to expose cluster memory as a shared address space with transactions. The authors report an order-of-magnitude latency and throughput gain; a 20-machine cluster does 167 million key-value lookups per second at 31µs.
Checked: PDF from usenix.org, fetched 4 Oct 2026. Page numbers are those of that PDF.
5 findings
Substance Abstract says "a 20-machine cluster can perform 167 million key-value lookups per second with a latency of 31µs", but Section 4.2 says "FaRM achieves 146 million lookups per second with a latency of only 35µs with 20 machines and the uniform distribution" (146 million repeated later in the section).
- p. 2 Abstract, last sentence
a 20-machine cluster can perform 167 million key-value
- p. 11 Section 4.2, second paragraph
FaRM achieves 146 million lookups per second with a
- p. 11 Section 4.2, single-machine paragraph
achieves 146 million lookups per second while provid-
- p. 2 Abstract, last sentence
a 20-machine cluster can perform 167 million key-value lookups per second with a latency of 31µs
Only the authors can say what is right here.
Judge's note: Read the abstract on the page 2 image and Section 4.2 plus Figures 12 and 13 on the page 11 image. The abstract prints 167 million and 31µs; the body prints 146 million (twice) and 35µs, and the FaRM uniform curve in Figures 12 and 13 ends at about 146 at 20 servers. Searched the full text: neither 167 nor 31µs appears anywhere else, and no alternative configuration is named that would give them (YCSB is lower at about 100 million and 51µs; Figure 10 uses 8-byte keys and peaks near 160). The body and figures agree with each other, so the abstract looks stale, but only the authors can say which numbers are final.
Second check: another model agreed
Report a problem with this finding
Reference or label Section 4.2: "The low level optimizations discussed in Section 2 improve lookup throughput by 8x" — Section 2 is "Background on RDMA" and describes no optimizations; they are in Section 3.1.
- p. 12 Section 4.2, last paragraph
The low level optimizations discussed in Section 2 im-
- p. 5 Section 3.1 (PhyCo, queue-pair sharing, polling)
We fixed this problem by using larger pages to reduce
- p. 7 Section 3.3
(as described in Section 2)
- p. 14 Related work
scalability problems that we discuss in Section 2
Judge's note: Sentence read on the page 12 image; Section 2 on the page 3 image; Section 3.1 on the page 5 image. Section 2 only gives background (registration, limited NIC memory, RoCE). The optimizations (PhyCo 2 GB pages, queue-pair sharing, polling instead of interrupts) are all in Section 3.1 "Communication primitives". The pointer should be to Section 3.1. The page 7 pointer "(as described in Section 2)" for NIC registration is correct, since registration is described in Section 2. The page 14 instance is judged under C015.
Second check: another model agreed
Report a problem with this finding
Reference or label Reference [6] prints its authors as "ANJALI, G., BARBARA, L., AND RODRIGO, R. Efficient routing for peer-to-peer overlays", which appears to put given names in the surname position and reduce the surnames to initials.
- p. 14 References, entry [6]
ANJALI, G., BARBARA, L., AND RODRIGO, R. Efficient routing
- p. 14 References, entry [6]
ANJALI, G., BARBARA, L., AND RODRIGO, R.
Only the authors can say what is right here.
Judge's note: Rests on outside knowledge: that the authors of this NSDI '04 paper are Anjali Gupta, Barbara Liskov and Rodrigo Rodrigues. The page 14 image shows the entry exactly as quoted, so it is not an extraction artefact. Every other entry on the page is in surname-first form, and Anjali, Barbara and Rodrigo read as given names, but the true author list cannot be checked from the files.
Second check: another model agreed
Report a problem with this finding
Reference or label Reference [37] prints its authors as "MITCHELL, C., YIFENG, G., AND JINYANG, L.", which appears to put the given names of the second and third authors in the surname position.
- p. 15 References, entry [37]
MITCHELL, C., YIFENG, G., AND JINYANG, L.
Only the authors can say what is right here.
Judge's note: Rests on outside knowledge: that the Pilaf paper's authors are Christopher Mitchell, Yifeng Geng and Jinyang Li. The page 15 image shows the entry exactly as quoted. The first author is in surname-first form while the next two look inverted, but the true author list cannot be checked from the files.
Second check: another model agreed
Report a problem with this finding
Reference or label Reference [23] gives one author only as initials, "W.-U. R. M., WANG, H.,", whereas the same author appears as "WASI-UR RAHMAN, M." in references [29] and [30].
- p. 15 References, entry [23]
W.-U. R. M., WANG, H.,
- p. 15 References, entry [23]
W.-U. R. M.
Judge's note: The page 15 image shows "HUANG, J., OUYANG, X., JOSE, J., W.-U. R. M., WANG, H., ..." in entry [23]. The name is reduced to initials with no surname, unlike every other author in the list. Entries [29] and [30] on the same page, from the same research group, print "WASI-UR RAHMAN, M.", so the inconsistency is internal and the fix is evident.
Second check: another model agreed
Report a problem with this finding
11 minor (typos and the like; most checked by the judge only)
Reference or label Introduction: "achieves an order-of-magnitude improvement in message rate and latency relative to TCP/IP on the same Ethernet network (Figure 2)"; Figure 2 shows only request rate, and latency is in Figure 3.
- p. 2 Section 1, third paragraph
improvement in message rate and latency relative to
- p. 4 Figure 2 caption
Figure 2: Random reads: request rate per machine
Judge's note: Checked the page 2 image for the sentence and the page 4 image for the figures. Figure 2 is "Random reads: request rate per machine"; Figure 3 is "Random reads: latency with high and low load". The pointer covers only the rate half of the claim. It can be read as attached to the message-rate half only, so this is a minor incomplete pointer. The reviewer's side remark that the latency gain ("at least 145x") exceeds one order of magnitude is an understatement, not an error.
Second check: another model agreed
Report a problem with this finding
Wording Text: "with VirtualAlloc the request rate drops by a factor of 4 when more than 16 MBs of memory is registered with the NIC"; in Figure 4 the VirtualAlloc series has already dropped at the 16M point (about 2x), sits at about 3x from 64M to 2G, and reaches 4x or more only at 4G–8G.
- p. 5 Section 3.1, paragraph describing Figure 4
factor of 4 when more than 16 MBs of memory is regis-
- p. 5 Figure 4, VirtualAlloc series
VirtualAlloc
Judge's note: Read the Figure 4 crop and the page 5 image. The VirtualAlloc series has 16 points (256k to 8G, doubling). By eye: about 8.5 up to 8M, about 4.0 at 16M, about 3.1 at 32M, about 2.6–2.9 from 64M to 2G, about 2.05 at 4G and about 1.6 at 8G. The printed threshold and factor are a loose summary of the plot. Values are read by eye, so this is a wording-precision point only.
Second check: another model agreed
Report a problem with this finding
Wording The conclusion says "it consistently achieves an order of magnitude better throughput and latency than main memory systems that use TCP/IP", while Section 4.2 reports "FaRM still achieves 8x better throughput relative to multi-gets of 24 keys and 3x better relative to multi-gets of 100" and a single-machine case where "the baseline can achieve 40 million lookups per second and FaRM achieves 26 million".
- p. 14 Section 6 Conclusion, last sentence
it consistently
- p. 12 Section 4.2, multi-get paragraph
FaRM still achieves 8x
- p. 12 Section 4.2, multi-get paragraph
better relative to multi-gets of 100
- p. 11 Section 4.2, single-machine paragraph
lookups per second and FaRM achieves 26 million
Judge's note: I read the conclusion on the page 14 image and the multi-get paragraph on the page 12 image; the single-machine sentence on page 11 was checked in the text layer only. The paper's own figures of 3x and 8x fall short of an order of magnitude, and on one machine the baseline is faster, so "consistently" overstates. The headline non-batched 20-machine comparison does support an order of magnitude, the paper discusses the multi-get latency penalty, and the single-machine case involves no network, so this is a minor wording point. I did not check the reviewers' Figure 13 readings (146, 18, 47) and do not rely on them.
Second check: another model agreed
Report a problem with this finding
Wording Section 4.3: "The throughput when logging to SSDs is 30% lower than without replication"; in Figure 14 the SSD-to-NoRep gap is about 30% only at 3–5 servers and about 18–25% from 8 to 20 servers (about 22–23% at 20).
- p. 12 Section 4.3, second paragraph
30% lower than without replication mostly due to the ad-
- p. 12 Figure 14, values at 20 servers
Figure 14: Key-value store: scalability with updates
- p. 12 Section 4.3, text after Figure 14
The throughput when logging to SSDs is 30% lower than without replication
Judge's note: Read Figure 14 on the page 12 image and the crop, by eye (roughly ±5 units). NoRep vs SSD: about 33 vs 23 at 3 servers, 45 vs 31 at 5, 64 vs 48 at 8, 87 vs 71 at 12, 118 vs 92 at 16, and 141 vs about 108–110 at 20. The reviewers' statement that no cluster size reaches 30% does not match my reading: the small clusters do. The headline 20-server point shows a smaller gap, and the text does not say which size the 30% refers to. Plot-reading uncertainty is material, so this is only a wording-precision observation.
Second check: another model agreed
Report a problem with this finding
Typo Footnote 1 writes "Mellanox ConnectX 3 NICs and SX1036 switches" while Section 4.1 writes "Mellanox ConnectX-3 RoCE NIC" and "Mellanox SX-1036 switch".
- p. 3 Footnote 1
Mellanox ConnectX 3 NICs and SX1036 switches
- p. 10 Section 4.1, first paragraph
Mellanox SX-1036 switch
Judge's note: Both forms are visible on the page 3 footnote and the page 10 Section 4.1 images. This is an internal styling inconsistency in product names; the same hardware is clearly meant. Cosmetic only, and which form is the vendor's is not something the files settle.
Second check: none (judge only)
Report a problem with this finding
Typo Section 3.3 has "maintained reliably using Zookeeper [24]" while Section 3.5 has "maintain leases with ZooKeeper".
- p. 7 Section 3.3, first paragraph on the page
using Zookeeper [24]
- p. 8 Section 3.5, paragraph on header versions
with ZooKeeper
- p. 7 Section 3.3
maintained reliably using Zookeeper [24]
- p. 8 Section 3.5
maintain leases with ZooKeeper
Judge's note: Both spellings are visible on the page 7 and page 8 images. Reference [24] in the list also prints "Zookeeper". This is an internal capitalisation inconsistency and purely cosmetic.
Second check: none (judge only)
Report a problem with this finding
Typo Section 3.6: "we add joint versions for adjacent pair of buckets" — number agreement; should be "adjacent pairs of buckets" or "each adjacent pair of buckets".
- p. 9 Section 3.6, paragraph on joint versions
joint versions for adjacent pair
Judge's note: Wording confirmed on the page 9 image, right column. Grammatical slip only.
Second check: none (judge only)
Report a problem with this finding
Typo Section 3.6: "shipping transactions to the machine that store the relevant shard" — should be "stores".
- p. 10 Section 3.6, first paragraph below Figure 11
ping transactions to the machine that store the relevant
- p. 10 Section 3.6, left column top
transactions to the machine that store the relevant
Judge's note: Confirmed on the page 10 image, first line under Figure 11. Subject-verb agreement slip.
Second check: none (judge only)
Report a problem with this finding
Typo Section 4: "a state-of-the art implementation" (partly hyphenated; the Introduction has "state-of-the-art"); Conclusion: "RDMA-aware key value and graph stores" (elsewhere "key-value").
- p. 10 Section 4, introductory paragraph
state-of-the art implementation
- p. 14 Conclusion
RDMA-aware key value and graph stores
Judge's note: The page 10 image shows "state-of-the art" mid-line, so it is not a line-break artefact. The page 14 image shows "key value" in the Conclusion, while the rest of the paper uses "key-value". Cosmetic hyphenation inconsistencies.
Second check: none (judge only)
Report a problem with this finding
Typo Figure 12 and Figure 13 legends print "Farm Uni", "Farm YCSB" and "Farm" whereas the system is written "FaRM" everywhere in the text.
- p. 11 Figure 12 and Figure 13 legends
Farm Uni
Judge's note: Legends read on the page 11 image. A cosmetic capitalisation inconsistency in figure legends; it may be a deliberate short label.
Second check: none (judge only)
Report a problem with this finding
Typo What appears to be the same co-author is spelled "WYCOFF, P." in reference [34] and "WYCKOFF, P." in reference [48].
- p. 15 References, entry [34]
WYCOFF, P.
- p. 15 References, entry [48]
WYCKOFF, P.
Only the authors can say what is right here.
Judge's note: Rests on outside knowledge: that both entries refer to the same person (P. Wyckoff) and which spelling is right. The page 15 image shows both spellings as quoted. The same initial, the shared co-authors (Liu/Wu, Panda) and the shared InfiniBand topic suggest one person, but the files cannot settle that or the correct spelling.
Second check: none (judge only)