Jump to content
  • 0

Occasional Super Slow Connections


Firerouge

Question

Most every read operation finishes so quickly that it's almost impossible to even see the connection speeds for them in the log.

 

Occasionally, maybe one read per 100gigs, I'll get an incredibly slow read operation download. Occasionally taking over a minute to download the 20MB chunk (longest I've seen was a minute 50), with speeds around 200-500kb/s.

 

These slow reads tend to block other operations for the program I'm using. This is pretty bad.

 

To try and circumvent this. I edited the IoManager_ReadAbort line in advanced settings, down from 1:55, to :30 seconds.

However, this command doesn't work as expected, instead of aborting the read and retrying, if a connection exceeds this timeframe, it actually disconnects the drive (unmounts it), and presents the retry and reauthorize options in clouddrive UI. Retry will always reconnect it right away, but this doesn't solve the errant slow connection issue.

 

 

I believe the IoManger_ReadAbort would be better suited if it actually just reattempted the read connection on a timeout, instead of assuming a full provider failure.

 

With that in mind, I propose that if IoManager_ReadAbort is triggered it should utilize the IoManager_ReadRetries variable to attempt a specified number of reconnects.

 

Alternatively, a new flag, IoManager_MinSustainedReadSpeed (defined in kb/s) could be implemented, to specifically retry connections with very slow read speeds, which would likely detect and rectify these connections quicker than waiting for a timeout period before retrying.

Link to comment
Share on other sites

8 answers to this question

Recommended Posts

  • 0

The settings you're trying to mess with don't do what you think.

 

You want "IoManager_HttpConnectionTimeoutMS" here, as that is closer to what you want. 

 

 

That said, could you enable drive tracing and reproduce the issue? 

http://wiki.covecube.com/StableBit_CloudDrive_Drive_Tracing

Link to comment
Share on other sites

  • 0

The settings you're trying to mess with don't do what you think.

 

You want "IoManager_HttpConnectionTimeoutMS" here, as that is closer to what you want. 

That said, could you enable drive tracing and reproduce the issue? 

http://wiki.covecube.com/StableBit_CloudDrive_Drive_Tracing

 

I just now noticed that setting in the wiki as well, it isn't listed in the default config, I'm going to experiment with some variations of that setting as a solution.

 

 

As for recording it, I've only ever noticed it twice, and that was just luck of glancing at the technical log at the right time and noticing that it had dropped to one single read request, which upon a detailed look, showed the slow speed and the 1min+ connection timer. I'll try and create logs, but I might not have much luck locking it down.

 

 

 

 

Minor side point while I have your attention, a brand new windows VPS running almost exclusively 854+rtorrent+rclone rarely has unexpected reboots during peak disk i/o. The problem seems to be described in issue 27416, ostensibly fixed a month ago, but in a seemingly unreleased version 858. Can we expect a new RC soon? The issue tracker seems to imply internally you're already past version 859 even.

Link to comment
Share on other sites

  • 0

I just now noticed that setting in the wiki as well, it isn't listed in the default config, I'm going to experiment with some variations of that setting as a solution.

 

 

As for recording it, I've only ever noticed it twice, and that was just luck of glancing at the technical log at the right time and noticing that it had dropped to one single read request, which upon a detailed look, showed the slow speed and the 1min+ connection timer. I'll try and create logs, but I might not have much luck locking it down.

 

 

 

 

Minor side point while I have your attention, a brand new windows VPS running almost exclusively 854+rtorrent+rclone rarely has unexpected reboots during peak disk i/o. The problem seems to be described in issue 27416, ostensibly fixed a month ago, but in a seemingly unreleased version 858. Can we expect a new RC soon? The issue tracker seems to imply internally you're already past version 859 even.

 

861 is the latest. You can download betas below.

 

http://dl.covecube.com/CloudDriveWindows/release/download

Link to comment
Share on other sites

  • 0

I caught it happening on 861. As you can see a 2+ minute read operation on one chunk...

 

18WUnqi.png

 

I've attempted to trace this (I didn't get the start, but It should have recorded this read). Upon completion of the connection, it jumped back up to its normal one to two dozen parallel write operations (most in a variant of the SharedWait state)

 

I'll hopefully be switching to a faster transit VPS shortly, in an effort to disprove network misconfiguration as the cause.

 

I realize also, that this is in part a limitation in the program utilizing the clouddrive, as it seems to wait until all (or most) of the burst of operations complete before starting the next wave, so even a relatively slow 20 second read can have blocking implications on additional writes. However, a fast fix for the worst offenders (multi minute connections) would be quite beneficial.

Link to comment
Share on other sites

  • 0

My, you're right, it is, thank you. Wonder why the update checker never gave me it though.

Because it's not a public build (eg, not pushed out), and we should have a new build pushed out soon. 

 

I caught it happening on 861. As you can see a 2+ minute read operation on one chunk...

 

18WUnqi.png

 

I've attempted to trace this (I didn't get the start, but It should have recorded this read). Upon completion of the connection, it jumped back up to its normal one to two dozen parallel write operations (most in a variant of the SharedWait state)

 

I'll hopefully be switching to a faster transit VPS shortly, in an effort to disprove network misconfiguration as the cause.

 

I realize also, that this is in part a limitation in the program utilizing the clouddrive, as it seems to wait until all (or most) of the burst of operations complete before starting the next wave, so even a relatively slow 20 second read can have blocking implications on additional writes. However, a fast fix for the worst offenders (multi minute connections) would be quite beneficial.

 

Okay, thank you for grabbing the screenshot. 

 

And where you able to grab the logs for when this happened specifically? 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...