Skip to content

Conversation

@pletessier
Copy link

The timeout has to be increased to handle pauses happening at start. The more the bandwidth is limited, the more the timeout should be.

Pierre Letessier added 3 commits July 26, 2016 14:51
…has to be increased to handle pauses happening at start. The more the bandwidth is limited, the more the timeout should be.
…has to be increased to handle pauses happening at start. The more the bandwidth is limited, the more the timeout should be.
@jbardin
Copy link
Owner

jbardin commented Jul 26, 2016

The -l option is used by the openssh scp source but isn't sent to the sink. Are you sure this does anything on the receiving side? (the test doesn't confirm if the bandwidth is actually altered)

@pletessier
Copy link
Author

Yes it works. I've tested it with several different bandwidth, and iftop always confirm the values. But you're right, it's not sent to the sink. In fact, I think scp tries to download the first packets, evaluate the rate, and then wait between every packets to not go over the given limit. So the first seconds are very chaotic, and after the bandwith stabilizes. You won't see it on small files.

scp.py Outdated
scp_command = (b'scp -t ', b'scp -r -t ')[recursive]
scp_command = b'scp -t '
scp_command += (b'', b' -r ')[recursive]
scp_command += (b'', b' -l '+ str(limit_bandwidth).encode() + b' ')[limit_bandwidth > 0]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't we use a proper if here?

if limit_bandwidth > 0:
    scp_command += b' -l ' + str(limit_bandwidth).encode() + b' '

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants