mirror of
https://github.com/agessaman/meshcore-bot.git
synced 2026-08-15 07:00:15 +00:00
agessaman
3a4d7aab33
Keeps the advert series — nodes by their closest observed path — and adds arriving flood packets by how far they had already travelled. The two answer different questions and, on the live mesh, disagree usefully: nodes peak at 2-3 hops and fall away quickly, while flood traffic peaks at 5 and holds a long tail past 16. A close-in neighbourhood absorbing flood from well beyond it. One series counts nodes (2.8k) and the other packets (156k), so raw counts on a shared axis would flatten the node series into the baseline. Both are drawn as a share of their own total, with absolute counts in the tooltip, and padded onto one contiguous hop range so the bars line up. They also cover different spans — 7 days of adverts against whatever packet_stream retains — so each is labelled with its own window instead of being presented as one period. Watch the units. observed_paths.path_length is a BYTE count, so hops are path_length / bytes_per_hop. packet_stream.path_len is already a HOP count, with the byte length carried separately as path_byte_length. A 17-hop 3-byte path is path_length 51 in one table and path_len 17 in the other. Applying either rule to the other silently rescales the axis and the only symptom is a chart that looks a bit off, so both conventions are now pinned by tests against the shapes real rows take. Flood packets carry no sender identity and observed_paths holds only adverts, so the flood series cannot be reduced to a shortest path per node the way the advert series is. It is a per-packet distribution, and the tooltip says so.