1 files changed, 24 insertions, 22 deletions
diff --git a/docs/dashboard.md b/docs/dashboard.md
index 54aefa7..0b1b10d 100644
--- a/docs/dashboard.md
+++ b/docs/dashboard.md
@@ -137,32 +137,33 @@ drawn hollow) is drawn as the other end reports it, which its tooltip says. Then
 
 Messages this node exchanges run along its links as dots, from sender to receiver, all
 at one speed: over a longer link they arrive later. Each follows the line it went over:
-a subscribed node's PING or PONG of the paths layer, which names the address it went
-to, the line of that address's transport (curved, beside the one in use); any other
-(this node's own come as counts, without addresses), the line in use.
-They come from the per-peer message counts, which arrive every 2 s: what was sent and
-received since is spread over the next 2 s, at most 6 dots per link and direction,
-shared out by message kind, each kind in its colour (named in the legend; the console
-colours them alike). Counts that come after a gap (the computer slept, the stream
-stalled), and those that were queued meanwhile and come at once with them, show no
-dots: they would all run at once. A dot is as large as its kind's messages were on average
-(by the size's logarithm: a ping small, a large sync message large); the `size` slider
+a PING or PONG of the paths layer, which names the address it went to, the line of
+that address's transport (curved, beside the one in use); any other, the line in use.
+They come from the node's message log as it goes: the node sends what it logged a tenth
+of a second after the first of them, so a message runs soon after it went, and the
+messages of a moment start as far apart as they were sent. Of more than 6 in a moment
+on a link and way, 6 run, shared out by message kind, spread over the moment; each kind
+in its colour (named in the legend; the console colours them alike). After a gap (the
+computer slept, the stream stalled), only the last 2 s of what then comes runs. A dot
+is as large as its message (by the size's logarithm: a ping small, a large sync message
+large; shared out, as its kind's messages on average); the `size` slider
 right after their legend makes all dots larger or smaller, and the `speed` slider after
 it makes them run faster or slower (0.1 to 0.9 map units per millisecond, 0.3 at
 first: a link of 200 in about 0.7 s); both are kept in the browser. A picture
 of the traffic, not a record of it. A subscribed node's messages with its peers run
-along its links too, from its messages of each 2 s (read from it with the page's token,
-as its links are). Each message runs once, as it left, from its sender where the page
-reads the sender (this node's counts, or a subscribed node's messages): so it runs the
+along its links too, from its message log as it goes (read from it with the page's
+token, as its links are). Each message runs once, as it left, from its sender where the
+page reads the sender (this node's, or a subscribed node's): so it runs the
 way it went, also where it never arrived. Only a message from a node the page doesn't
 read runs as it arrived, from its receiver's. Links between other members show none.
 
 Where the page reads both ends of a link, what one sent the other should count
 received: a message sent and not received within 5 s makes the link breathe red once,
 its tooltip saying how many didn't arrive. Every kind counts but the paths and
-identity layers' (PINGs, WHO), which this node counts under addresses, not nodes; a
-tick of a subscribed node's messages that came short (more than 500 in 2 s) starts the
-count afresh, so it never takes what it didn't see as lost.
+identity layers' (PINGs, WHO), which this node counts under addresses, not nodes. This
+node's side is its counts, which come with the state every 2 s, hence the 5 s; a
+subscribed node's messages that came short (more than 500 at once) start the count
+afresh, so it never takes what it didn't see as lost.
 `messages: dots` after the sliders switches to `messages: flash`: each message crosses
 its link as fast as it did (half the link's round trip, as the map has it; 50 ms where
 none is measured), a streak widening to its head, which then draws back into where it
@@ -350,8 +351,8 @@ clock, to the millisecond), which way (`→` sent, `←` received, `↛` refused
 transport wouldn't send it), with whom, the type (`HELLO`, `SYNC`, `STATUS_REPLY`,
 `PING`, …, in its kind's colour, as on the map) and the size. The latest 500, the
 newest at the bottom; scrolled along while at the bottom, which `following…` beside the
-title says. `clear` empties it; what comes from then on fills it again. They arrive with every update
-(every 2 s). The PINGs the paths layer sends on its own, and the PONGs it answers
+title says. `clear` empties it; what comes from then on fills it again. They arrive as
+they come (a tenth of a second after the first of a moment's). The PINGs the paths layer sends on its own, and the PONGs it answers
 PINGs with, are listed too: under the node at the address they went to, where it is
 known, else under the address. Not listed: WHO and ME, which stay in the layers
 below the node (they are counted, [`measurements.md`](measurements.md), Traffic).
@@ -464,10 +465,11 @@ takes each against their median: a member more than
 `--clock-skew-warn` off it, beyond the chained bound, is ringed. With fewer than three
 members compared, none is.
 
-**Messages on the map** come from the per-peer message counts in the state (`/peers`,
-`traffic`), not from messages of their own. **The console's** come from a log the node
-keeps only while the producer runs (`traffic::MessageLog`, the latest 1000), sent as a
-`messages` event every 2 s with those since the last.
+**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
+and what was delivered.
 
 **The document** is read through the store API, a level at a time as it is opened
 (`GET /store?shallow=true`, then `/store/<path>?shallow=true` for each map opened, and