DHT Sync Lag
Measure lag time between an agent publishing data and other peers being able to see it. This scenario has two roles:
write: A simple job that just creates entries with a timestamp field. Those entries are linked to a known base hash. For each write, the metricws.custom.dht_sync_sent_countis incremented.record_lag: A job that repeatedly queries for links from the known base hash. It keeps track of records that it has seen and when a new record is found, and calculates the time difference between the timestamp of the new record and the current time. That time difference is then recorded as a custom metric calledwt.custom.dht_sync_lag.
After each behaviour loop the metric ws.custom.dht_sync_recv_count is incremented.
-
record_lag(1 agent) -
write(1 agent)
Warning CPU p99 reached 93.8%
Warning Memory growing at 640.93 MB/s
Critical Heavy swap usage (39.0% swap used)
Additional Host Metrics
//efi-boot/etc/hostname/etc/hosts/etc/resolv.conf/nix/storeValidation Receipts
Creates an entry, wait for required validation receipts, then repeat. Records the amount of time it took to accumulate the required number of receipts for all DHT operations. This is measured to the nearest 20ms so that we don't keep the agent too busy checking for receipts.
Each agent in this scenario waits for a certain number of peers to be available or for up to two minutes, whichever happens first, before starting its behaviour.
By default, this scenario will wait for a complete set of validation receipts before committing the next record. If the NO_VALIDATION_COMPLETE environment variable is set, it will instead publish new records on every round, building up an ever-growing list of action hashes to check on.
-
default(1 agent)
Warning CPU p99 reached 90.8%
Warning Memory growing at 474.02 MB/s
Critical Heavy swap usage (39.0% swap used)
Additional Host Metrics
//boot/efi-boot/etc/hostname/etc/hosts/etc/resolv.conf/nix/store