All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <ef84de89c2597793d4cca5eee446ba90@localhost>

diff --git a/a/1.txt b/N1/1.txt
index e49debc..8af23d6 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,25 +1,48 @@
 
 On Thu, 19 May 2011 08:52:10 +0200, Alexander Zimmermann wrote:
 
+
+
 >> #define TCP_RTO_MAX     ((unsigned)(120*HZ))
+
 >> #define TCP_RTO_MIN     ((unsigned)(HZ/5))
+
 >> 
+
 >> So we're talking about a [200ms ; 120s] range no matter what.
+
 > 
+
 > Why is 200ms a valid lower bound for initRTO? I'm aware of
+
 > measurements that 1s is save for Internet, but I don't know of any
+
 > studies that 200ms is save... 
 
+
+
 TCP_RTO_MAX and TCP_RTO_MIN is the lower/upper bound for the RTO in
+
 general, not for the initial RTO. RFC 2988 specify a lower bound of 1
+
 second but all operating system choose a lower one because at the time
+
 where RFC 2988 was written the clock granularity was not that accurate. The
+
 minimum RTO for FreeBSD is even 30ms! Furthermore, analysis had
+
 demonstrated that a minimum RTO of 1 second badly breaks throughput in
+
 environments faster then 33kB with minor packet loss rate (e.g. 1%).
 
+
+
 So yes, it CAN be wise to choose other lower/upper bounds. But keep in
+
 mind that we should NOT artificial limit ourself. I can image data center
+
 scenarios where a initial RTO of <1 match perfectly.
 
+
+
 Hagen
diff --git a/a/content_digest b/N1/content_digest
index 49f4038..8acb310 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -27,27 +27,50 @@
  "\n"
  "On Thu, 19 May 2011 08:52:10 +0200, Alexander Zimmermann wrote:\n"
  "\n"
+ "\n"
+ "\n"
  ">> #define TCP_RTO_MAX     ((unsigned)(120*HZ))\n"
+ "\n"
  ">> #define TCP_RTO_MIN     ((unsigned)(HZ/5))\n"
+ "\n"
  ">> \n"
+ "\n"
  ">> So we're talking about a [200ms ; 120s] range no matter what.\n"
+ "\n"
  "> \n"
+ "\n"
  "> Why is 200ms a valid lower bound for initRTO? I'm aware of\n"
+ "\n"
  "> measurements that 1s is save for Internet, but I don't know of any\n"
+ "\n"
  "> studies that 200ms is save... \n"
  "\n"
+ "\n"
+ "\n"
  "TCP_RTO_MAX and TCP_RTO_MIN is the lower/upper bound for the RTO in\n"
+ "\n"
  "general, not for the initial RTO. RFC 2988 specify a lower bound of 1\n"
+ "\n"
  "second but all operating system choose a lower one because at the time\n"
+ "\n"
  "where RFC 2988 was written the clock granularity was not that accurate. The\n"
+ "\n"
  "minimum RTO for FreeBSD is even 30ms! Furthermore, analysis had\n"
+ "\n"
  "demonstrated that a minimum RTO of 1 second badly breaks throughput in\n"
+ "\n"
  "environments faster then 33kB with minor packet loss rate (e.g. 1%).\n"
  "\n"
+ "\n"
+ "\n"
  "So yes, it CAN be wise to choose other lower/upper bounds. But keep in\n"
+ "\n"
  "mind that we should NOT artificial limit ourself. I can image data center\n"
+ "\n"
  "scenarios where a initial RTO of <1 match perfectly.\n"
  "\n"
+ "\n"
+ "\n"
  Hagen
 
-a7a3b36fe06d3beebcef221c1485283f15f4580b8b150bd2c2ece34e741eb3c4
+27dc8c99b3a4ee120858a02a6029a5561a01ba407debb0922eeea6fe18285da5

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.