-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Significant overhead/latency (about 50ms) #54
Comments
Naively 50 ms seems pretty crazy high on the loopback interface? I expect this is more a Julia issue than a problem in this package but if we can invent a workaround that's great. Thanks @xgdgsc for the link :-) |
The linked issue has a comment where Jeff says that the culprit is the "Nagle algorithm". It can be disabled: help?> Sockets.nagle
nagle(socket::Union{TCPServer, TCPSocket}, enable::Bool)
Enables or disables Nagle's algorithm on a given TCP server or socket.
│ Julia 1.3
│
│ This function requires Julia 1.3 or later. Should we use |
Correct, you should not be using Nagle's algorithm for interactive sockets - it's intended for high-bandwidth, high-latency TCP connections (such as data downloads). |
PR created. The effect was a 74x reduction in overhead, from adding a single line! |
I mentioned in a comment on this issue that I had some latency issues when using RemoteREPL for my Raspberry Pi. But I just checked using a local host, so no SSH, and having everything running on the same, modern computer. I found that there is STILL almost 50 ms of latency from just evaluating
1
and returning the result:By running
using ProfileView
and then@profview @remote 1
, I get the following flamegraph:From the top, the call-sites that make up the flamegraph are
I am not sure if this can be improved, or if this wait-time is necessary when dealing with networks. But investigations should be made into the possibility of avoiding this ~50 ms latency to every remote call.
The text was updated successfully, but these errors were encountered: