dashboard: where a stream's lag comes from

A stream's lag in the tooltip of `behind: …` was one figure, from when
a node logged a message to when the page had it: a second and a half
for a node a LAN away said nothing of where it went.

The node now stamps each `messages` event with when it sent it
(`{"sent": …, "messages": […]}`), and the tooltip splits each stream's
lag: how long its batches waited in the node, from logging the first
message to sending the batch (the node's own clock: exact), and how
long they took on the way, from sending to arriving. This node's own
stream is always listed, beside the three slowest.

1 files changed, 7 insertions, 4 deletions

diff --git a/docs/dashboard.md b/docs/dashboard.md
index 0d1500b..28f31a1 100644
--- a/docs/dashboard.md
+++ b/docs/dashboard.md
@@ -147,9 +147,12 @@ the time its node logged it, taken back by how far that node's clock is ahead of
 node's (as the map chains the clocks), a while behind real time. How far behind
 (`behind: …` after the sliders) is the most any stream lagged within the last 30 s and
 a tenth of a second more; its tooltip shows how it came about (which node's stream
-lagged the most, by how much, and the margin) and the three slowest streams, each with
-the most and the least it lagged, so a slow path shows. Lags are measured by the
-browser's clock against this node's: one that is off adds to all of them alike. Messages of different nodes then run as far apart as they went,
+lagged the most, by how much, and the margin) and the three slowest streams and this
+node's own, each with the most and the least it lagged, and of that how long its
+batches waited in their node (from logging the first message to sending the batch: the
+node's own clock, exact) and took on the way (from sending to arriving), so a slow node
+or a slow path shows. Lags are measured by the browser's clock against this node's:
+one that is off adds to all of them alike. Messages of different nodes then run as far apart as they went,
 give or take how well their clocks are known (within the bounds the clock chain has). A
 message the page knows only from its receiver (its sender's messages aren't read: not
 subscribed) arrives at the time its receiver logged it, starting a crossing before.
@@ -484,7 +487,7 @@ members compared, none is.
 **Messages**, on the map and in the console, come from a log the node keeps only while
 someone looks (`traffic::MessageLog`, the latest 1000), sent as a `messages` event as
 they come: a tenth of a second after the first of those since the last, the latest 500
-of them. The per-peer message counts in the state (`/peers`, `traffic`) give the rates
+of them, with when the node sent the event (`{"sent": …, "messages": […]}`). The per-peer message counts in the state (`/peers`, `traffic`) give the rates
 and what was delivered.
 
 **The document** is read through the store API, a level at a time as it is opened