Optimize data transfer delay #2328
Comments
|
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. |
please refer to the
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 |
|
@flub By tracing the code, I found the code that causes the delay. In the 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 #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. |
## Description Fix for #2328: Enumerating network devices is slow on windows and causes delays in the magicsock actor. This makes sure that this operation does not block the remainder of the actor. Also bumps netdev to v0.27.0 , to fix #2327. --------- Co-authored-by: Floris Bruynooghe <flub@devork.be>
|
@zh522130 this can be closed now or are you still getting delays? |
yes, close it |
## Description Fix for n0-computer/iroh#2328: Enumerating network devices is slow on windows and causes delays in the magicsock actor. This makes sure that this operation does not block the remainder of the actor. Also bumps netdev to v0.27.0 , to fix n0-computer/iroh#2327. --------- Co-authored-by: Floris Bruynooghe <flub@devork.be>
## Description Fix for n0-computer/iroh#2328: Enumerating network devices is slow on windows and causes delays in the magicsock actor. This makes sure that this operation does not block the remainder of the actor. Also bumps netdev to v0.27.0 , to fix n0-computer/iroh#2327. --------- Co-authored-by: Floris Bruynooghe <flub@devork.be>
## Description Fix for n0-computer/iroh#2328: Enumerating network devices is slow on windows and causes delays in the magicsock actor. This makes sure that this operation does not block the remainder of the actor. Also bumps netdev to v0.27.0 , to fix n0-computer/iroh#2327. --------- Co-authored-by: Floris Bruynooghe <flub@devork.be>
## Description Fix for #2328: Enumerating network devices is slow on windows and causes delays in the magicsock actor. This makes sure that this operation does not block the remainder of the actor. Also bumps netdev to v0.27.0 , to fix #2327. --------- Co-authored-by: Floris Bruynooghe <flub@devork.be>
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 #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:
The text was updated successfully, but these errors were encountered: