On resource constrained devices like the ESP32, it can cause a bit of trouble that the QAD probes all go out at the exact same time.
It would be good if there was some kind of staggered approach, or maybe max_concurrent_qad_probes config.
I realize that this isn't an issue for most normal devices, but on the ESP32 this is a big problem. You get some quiet period and then a flurry of activity.
W (792528) tracing::span: reportgen-actor;
W (792528) iroh::net_report: QADv4; relay_url=https://aps1-1.relay.n0.iroh.link./
W (792538) iroh::net_report: QADv4; relay_url=https://euc1-1.relay.n0.iroh.link./
W (792538) iroh::net_report: QADv4; relay_url=https://use1-1.relay.n0.iroh.link./
W (792548) iroh::net_report: QADv4; relay_url=https://usw1-1.relay.n0.iroh.link./
I (792798) iroh::socket::transports: poll_send; network_path=Ip { remote: 5.223.65.62:7842, local: None } len=1200
I (792818) iroh::socket::transports: poll_send; network_path=Ip { remote: 87.99.151.110:7842, local: None } len=1200
I (792838) iroh::socket::transports: poll_send; network_path=Ip { remote: 5.78.69.43:7842, local: None } len=1200
I (792908) smart_fan_esp32: DHT22: 26.1°C 42.9% fan=off (threshold 41°C)
I (792938) iroh::socket::transports: poll_send; network_path=Ip { remote: 91.99.237.97:7842, local: None } len=1200
I (792998) iroh::socket::transports: poll_send; network_path=Relay { url: RelayUrl("https://euc1-1.relay.n0.iroh.link./"), endpoint_id: PublicKey(2c775aa58042b090dc83e84cd5cf9e804fb988a956a41edaac29386aac0ec60a) } len=49
I (793038) iroh::socket::transports: poll_send; network_path=Relay { url: RelayUrl("https://euc1-1.relay.n0.iroh.link./"), endpoint_id: PublicKey(2c775aa58042b090dc83e84cd5cf9e804fb988a956a41edaac29386aac0ec60a) } len=49
I (793058) tracing::span: tx;
I (793068) tracing::span: tx;
I (793178) iroh::socket::transports: poll_send; network_path=Ip { remote: 87.99.151.110:7842, local: None } len=1200
I (793208) iroh::socket::transports: poll_send; network_path=Ip { remote: 87.99.151.110:7842, local: None } len=48
I (793298) iroh::socket::transports: poll_send; network_path=Ip { remote: 91.99.237.97:7842, local: None } len=1200
I (793338) iroh::socket::transports: poll_send; network_path=Ip { remote: 87.99.151.110:7842, local: None } len=48
I (793358) iroh::socket::transports: poll_send; network_path=Ip { remote: 91.99.237.97:7842, local: None } len=48
I (793458) iroh::socket::transports: poll_send; network_path=Ip { remote: 5.223.65.62:7842, local: None } len=1200
I (793488) iroh::socket::transports: poll_send; network_path=Ip { remote: 91.99.237.97:7842, local: None } len=48
I (793518) iroh::socket::transports: poll_send; network_path=Ip { remote: 5.223.65.62:7842, local: None } len=48
I (793608) iroh::socket::transports: poll_send; network_path=Ip { remote: 5.78.69.43:7842, local: None } len=1200
I (793638) iroh::socket::transports: poll_send; network_path=Ip { remote: 5.223.65.62:7842, local: None } len=48
I (793668) iroh::socket::transports: poll_send; network_path=Ip { remote: 5.78.69.43:7842, local: None } len=48
I (793698) iroh::socket::transports: poll_send; network_path=Ip { remote: 5.78.69.43:7842, local: None } len=48
I (793748) iroh::socket::transports: poll_send; network_path=Ip { remote: 87.99.151.110:7842, local: None } len=87
I (793818) iroh::socket::transports: poll_send; network_path=Ip { remote: 91.99.237.97:7842, local: None } len=87
I (793838) iroh::socket::transports: poll_send; network_path=Ip { remote: 87.99.151.110:7842, local: None } len=138
W (793848) tracing::span: QADv4;
I (793908) iroh::socket::transports: poll_send; network_path=Ip { remote: 5.223.65.62:7842, local: None } len=87
I (793928) iroh::socket::transports: poll_send; network_path=Ip { remote: 91.99.237.97:7842, local: None } len=138
I (793958) iroh::socket::transports: poll_send; network_path=Ip { remote: 87.99.151.110:7842, local: None } len=99
W (793968) tracing::span: QADv4;
I (793988) iroh::socket::transports: poll_send; network_path=Ip { remote: 91.99.237.97:7842, local: None } len=99
I (793998) iroh::socket::transports: poll_send; network_path=Ip { remote: 5.223.65.62:7842, local: None } len=138
W (794018) tracing::span: QADv4;
I (794048) iroh::socket::transports: poll_send; network_path=Ip { remote: 91.99.237.97:7842, local: None } len=99
I (794068) iroh::socket::transports: poll_send; network_path=Ip { remote: 5.223.65.62:7842, local: None } len=99
I (794098) iroh::socket::transports: poll_send; network_path=Ip { remote: 87.99.151.110:7842, local: None } len=99
I (794118) iroh::socket::transports: poll_send; network_path=Ip { remote: 5.78.69.43:7842, local: None } len=54
I (794148) iroh::socket::transports: poll_send; network_path=Ip { remote: 87.99.151.110:7842, local: None } len=99
I (794168) iroh::socket::transports: poll_send; network_path=Ip { remote: 5.78.69.43:7842, local: None } len=54
I (794208) iroh::socket::transports: poll_send; network_path=Ip { remote: 91.99.237.97:7842, local: None } len=99
I (794248) iroh::socket::transports: poll_send; network_path=Ip { remote: 87.99.151.110:7842, local: None } len=99
I (794258) iroh::socket::transports: poll_send; network_path=Relay { url: RelayUrl("https://euc1-1.relay.n0.iroh.link./"), endpoint_id: PublicKey(b988207d73b6273e41cee352446635a301f6dacb9ae5db3885d27bd40f0b083a) } len=44
I (794288) iroh::socket::transports: poll_send; network_path=Ip { remote: 91.99.237.97:7842, local: None } len=99
I (794318) iroh::socket::transports: poll_send; network_path=Ip { remote: 87.99.151.110:7842, local: None } len=99
I (794328) tracing::span: tx;
I (794368) iroh::socket::transports: poll_send; network_path=Ip { remote: 5.223.65.62:7842, local: None } len=99
I (794398) iroh::socket::transports: poll_send; network_path=Ip { remote: 5.223.65.62:7842, local: None } len=99
I (794418) iroh::socket::transports: poll_send; network_path=Ip { remote: 5.223.65.62:7842, local: None } len=99
I (794438) iroh::socket::transports: poll_send; network_path=Ip { remote: 5.223.65.62:7842, local: None } len=99
I (794468) iroh::socket::transports: poll_send; network_path=Relay { url: RelayUrl("https://euc1-1.relay.n0.iroh.link./"), endpoint_id: PublicKey(b988207d73b6273e41cee352446635a301f6dacb9ae5db3885d27bd40f0b083a) } len=36
I (794488) tracing::span: tx;
On resource constrained devices like the ESP32, it can cause a bit of trouble that the QAD probes all go out at the exact same time.
It would be good if there was some kind of staggered approach, or maybe max_concurrent_qad_probes config.
I realize that this isn't an issue for most normal devices, but on the ESP32 this is a big problem. You get some quiet period and then a flurry of activity.