diff --git a/Performance/Sep2011.md b/Performance/Sep2011.md
index 47a3ff5..8afa3d9 100644
--- a/Performance/Sep2011.md
+++ b/Performance/Sep2011.md
@@ -22,10 +22,14 @@ significantly with larger k.
 
 ## MDMF (trunk)
 
-MDMF is fast! Trunk downloads 1MB/10MB/100MB MDMF files at around 4MBps. The
-download speed seems unaffected by k (from 1 to 60). Partial reads take the
-expected amount of time: O(data_read), slightly quantized near the 128KiB
-segment size.
+MDMF is fast! Trunk downloads 1MB/10MB/100MB MDMF files at around 4MBps.
+~~The download speed seems unaffected by k (from 1 to 60)~~. Partial
+reads take the expected amount of time: O(data_read), slightly quantized
+near the 128KiB segment size.
+
+(update 25-Sep: the test harness appears to have been flawed, and all
+MDMF files were actually k=3. A new test is in the works to get proper
+data on how MDMF read speed varies with k).
 
 * MDMF read versus k, 100MB [MDMF-100MB-vs-k.png](../raw/attachments/Performance/Sep2011/MDMF-100MB-vs-k.png) (timing5.out)
 * MDMF partial reads, 100MB [MDMF-100MB-partial.png](../raw/attachments/Performance/Sep2011/MDMF-100MB-partial.png) (timing6.out)
@@ -73,8 +77,8 @@ Likely fixes include:
 > alacrity)
 * use unencrypted HTTP for share reads
 
-readv() is the least-work/most-promising, since MDMF has readv() and achieves
-high speeds. First step is to do whatever MDMF is doing
+readv() is the least-work/most-promising, ~~since MDMF has readv() and
+achieves high speeds. First step is to do whatever MDMF is doing~~
 
 ## Future Tests