Add some notes about the methodology of the test data.

1 files changed, 19 insertions, 0 deletions

diff --git a/docs/latency_results.txt b/docs/latency_results.txt
index c8c8576..d42447a 100644
--- a/docs/latency_results.txt
+++ b/docs/latency_results.txt
@@ -1,3 +1,22 @@
+This data is raw copy from the latency tester set to send a frame with
+a little over 2000 KB of data every 10ms.
+
+The number of packets sent and received is just a visual counter and
+is just the total when I chose to stop the test (around 3000 or so
+packets).
+
+The latency measure are from the point the packet was sent to when it
+was received back again in milliseconds. One notable data point
+missing from this is how long it actually took for the client to send
+3000 packets because sending large packets can put load on the browser
+and it may be a lot longer than 10ms before the timer to send the next
+event fires. So even with low latency numbers, the actual send rate
+may be fairly low because sending the WebSockets frames is impacting
+the performance of the browser in general.
+
+
+------------------------------------------------------------
+
 Native WebSockets implementations, 2000 byte payload, 10ms delay
 
 Chrome 8.0.552 - native WebSockets