Closed zh522130 closed 3 months ago
Not conclusive, but I suspect the netcheck logs are there just by chance because it happens regularly - about every 30s. If you look at the logs before this you might be able to see why netcheck was triggered.
Looking at where the gaps are in the timestamps it looks like always around two locations:
Is it possible you only enabled logs for the iroh-net crate? Otherwise you might also see activity from the DNS library and the HTTP & TLS libraries around these points I suspect.
Not conclusive, but I suspect the netcheck logs are there just by chance because it happens regularly - about every 30s
please refer to the INFO-level.log
file, It seems that most of the time, the recurring high latency only takes a few seconds.
Is it possible you only enabled logs for the iroh-net crate? Otherwise you might also see activity from the DNS library and the HTTP & TLS libraries around these points I suspect.
I am still learning Rust and am not very proficient. How can I enable logs for other crates? I tried printing through the following code.
let subscriber = tracing_subscriber::registry()
.with(
tracing_subscriber::fmt::layer()
.with_writer(Arc::new(log_file)
.with_max_level(tracing::Level::DEBUG))
.with_ansi(false),
)
.with(
tracing_subscriber::fmt::layer()
.with_writer(std::io::stdout.with_max_level(tracing::Level::DEBUG)),
);
subscriber.init();
Cargo.toml:
iroh-base = { version = "0.17.0", features = [
"key",
] }
iroh-net = { version = "0.17.0", features = ["test-utils"]}
iroh-metrics = { version = "0.17.0", default-features = false }
I have re-uploaded two log files. The INFO-level.log
file mainly tests for the occurrence cycle, and the TRACE-level.log
file mainly records the complete TRACE-level log from the start of the code execution to the first occurrence of high latency.
@flub By tracing the code, I found the code that causes the delay. In the magicsock.rs
file, The function call path is as follows:
async fn handle_actor_message(&mut self, msg: ActorMessage) -> bool {
match msg {
ActorMessage::NetcheckReport(report, why) => {
>> self.handle_netcheck_report(report).await
>> self.store_endpoints_update(report).await
>> let LocalAddresses {
regular: mut ips,
loopback,
} = LocalAddresses::new() >> let ifaces = netdev::interface::get_interfaces();
}
}
Ultimately, netdev::interface::get_interfaces() introduces additional latency. On my laptop, even after the fix through https://github.com/n0-computer/iroh/issues/2327, netdev::interface::get_interfaces() still takes over 10ms-20ms (on the Windows platform, unsure if the delay is related to device performance or platform). Consequently, in relay mode, a extra latency occurs at regular intervals.
@zh522130 this can be closed now or are you still getting delays?
@zh522130 this can be closed now or are you still getting delays?
yes, close it
I noticed that when the connection type is
ConnectionType::Mixed
, the data transfer delay seems to include the delay fromnetcheck
, and under the network environment mentioned at https://github.com/n0-computer/iroh/issues/2327, the transfer delay can be further amplified. The log only captures instances where the transmission delay was very high. I'm not certain if other connection types include this part of the delay. However, from my test results, it seems that iroh's average delay is somewhat higher than that of Tailscale, possibly slower by about 1ms in a local area network condition (this is not very precise, as the router itself can also have fluctuations).Code:
Log: