Pipe-Viewer problem with changing Rate-Limit

Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
I'm using pv for sending files via ssh.
I can change "active pv" the limit at under 100M without any problem.
When i set active pv process to 100M or 1G or higher I cant change rate anymore...
BUT! if i change 5-10 times 1M to 2M, 2M to 1M pv can set sometimes to new rate.
I couldn't find any solution for the problem. Any idea?
Examples:
pv -R "15778" -f -F "%p***%t***%e***%r***%b" -L 1M
pv -R "15778" -f -F "%p***%t***%e***%r***%b" -L 1G
pv -R "15778" -f -F "%p***%t***%e***%r***%b" -L 1M (not working anymore)
linux pv
add a comment |Â
up vote
2
down vote
favorite
I'm using pv for sending files via ssh.
I can change "active pv" the limit at under 100M without any problem.
When i set active pv process to 100M or 1G or higher I cant change rate anymore...
BUT! if i change 5-10 times 1M to 2M, 2M to 1M pv can set sometimes to new rate.
I couldn't find any solution for the problem. Any idea?
Examples:
pv -R "15778" -f -F "%p***%t***%e***%r***%b" -L 1M
pv -R "15778" -f -F "%p***%t***%e***%r***%b" -L 1G
pv -R "15778" -f -F "%p***%t***%e***%r***%b" -L 1M (not working anymore)
linux pv
@roaima its hard to show live process. But i will edit with examples
â Morphinz
Jan 24 at 13:13
Looks like a bug
â roaima
Jan 24 at 13:25
... or some sort of buffering perhaps â I see the limit being applied even with a single request, however it does take a very long time!
â Stephen Kitt
Jan 24 at 13:36
I wondered about buffering too. Maybe running an unchangeablepv -L 10M </dev/zeroas a source to thepvunder test can exclude a possible buffering issue
â roaima
Jan 24 at 14:00
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I'm using pv for sending files via ssh.
I can change "active pv" the limit at under 100M without any problem.
When i set active pv process to 100M or 1G or higher I cant change rate anymore...
BUT! if i change 5-10 times 1M to 2M, 2M to 1M pv can set sometimes to new rate.
I couldn't find any solution for the problem. Any idea?
Examples:
pv -R "15778" -f -F "%p***%t***%e***%r***%b" -L 1M
pv -R "15778" -f -F "%p***%t***%e***%r***%b" -L 1G
pv -R "15778" -f -F "%p***%t***%e***%r***%b" -L 1M (not working anymore)
linux pv
I'm using pv for sending files via ssh.
I can change "active pv" the limit at under 100M without any problem.
When i set active pv process to 100M or 1G or higher I cant change rate anymore...
BUT! if i change 5-10 times 1M to 2M, 2M to 1M pv can set sometimes to new rate.
I couldn't find any solution for the problem. Any idea?
Examples:
pv -R "15778" -f -F "%p***%t***%e***%r***%b" -L 1M
pv -R "15778" -f -F "%p***%t***%e***%r***%b" -L 1G
pv -R "15778" -f -F "%p***%t***%e***%r***%b" -L 1M (not working anymore)
linux pv
edited Jan 24 at 13:15
roaima
39.7k545108
39.7k545108
asked Jan 24 at 13:10
Morphinz
13110
13110
@roaima its hard to show live process. But i will edit with examples
â Morphinz
Jan 24 at 13:13
Looks like a bug
â roaima
Jan 24 at 13:25
... or some sort of buffering perhaps â I see the limit being applied even with a single request, however it does take a very long time!
â Stephen Kitt
Jan 24 at 13:36
I wondered about buffering too. Maybe running an unchangeablepv -L 10M </dev/zeroas a source to thepvunder test can exclude a possible buffering issue
â roaima
Jan 24 at 14:00
add a comment |Â
@roaima its hard to show live process. But i will edit with examples
â Morphinz
Jan 24 at 13:13
Looks like a bug
â roaima
Jan 24 at 13:25
... or some sort of buffering perhaps â I see the limit being applied even with a single request, however it does take a very long time!
â Stephen Kitt
Jan 24 at 13:36
I wondered about buffering too. Maybe running an unchangeablepv -L 10M </dev/zeroas a source to thepvunder test can exclude a possible buffering issue
â roaima
Jan 24 at 14:00
@roaima its hard to show live process. But i will edit with examples
â Morphinz
Jan 24 at 13:13
@roaima its hard to show live process. But i will edit with examples
â Morphinz
Jan 24 at 13:13
Looks like a bug
â roaima
Jan 24 at 13:25
Looks like a bug
â roaima
Jan 24 at 13:25
... or some sort of buffering perhaps â I see the limit being applied even with a single request, however it does take a very long time!
â Stephen Kitt
Jan 24 at 13:36
... or some sort of buffering perhaps â I see the limit being applied even with a single request, however it does take a very long time!
â Stephen Kitt
Jan 24 at 13:36
I wondered about buffering too. Maybe running an unchangeable
pv -L 10M </dev/zero as a source to the pv under test can exclude a possible buffering issueâ roaima
Jan 24 at 14:00
I wondered about buffering too. Maybe running an unchangeable
pv -L 10M </dev/zero as a source to the pv under test can exclude a possible buffering issueâ roaima
Jan 24 at 14:00
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
3
down vote
accepted
This is caused by accounting in pv, which effectively means its rate-limiting is read-limited rather than write-limited. Looking at the source code shows that rate-limiting is driven by a âÂÂtargetâÂÂ, which is the amount remaining to send. If rate-limiting is on, once per rate limit evaluation cycle, the target is increased by however much weâÂÂre supposed to send according to the rate limit; the target is then decreased by however much is actually written. This means that if you set the rate limit to a value larger than the actual write capacity, the target will keep going up; reducing the rate limit wonâÂÂt then have any effect until pv has caught up with its target (including what itâÂÂs allowed to write according to the new rate limit).
To see this in action, start a basic pv:
pv /dev/zero /dev/null
Then control that:
pv -R 32605 -L 1M; sleep 10; pv -R 32605 -L 1G; sleep 1; pv -R 32605 -L 1M
YouâÂÂll see the impact of the target calculations by varying the duration of the second sleep...
Because of the write limitation, this only causes an issue when you set the rate limit to a value greater than the write capacity.
In a little more detail, hereâÂÂs how the accounting works with a flow initially limited to 1M, then to 1G for 5s, then back to 1M, on a connection capable of transmitting 400M:
Time Rate Target Sent Remaining
1 1M 1M 1M 0
2 1G 1G 400M 600M
3 1G 1.6G 400M 1.2G
4 1G 2.2G 400M 1.8G
5 1G 2.8G 400M 2.4G
6 1G 3.4G 400M 3G
7 1M 3001M 400M 2601M
8 1M 2602M 400M 2202M
9 1M 2203M 400M 1803M
10 1M 1804M 400M 1404M
11 1M 1405M 400M 1005M
12 1M 1006M 400M 606M
13 1M 607M 400M 207M
14 1M 208M 208M 0
15 1M 1M 1M 0
It takes 7s for the rate limit to be applied again. The longer the time spent with a high rate limit, the longer it takes for the reduced rate limit to be enforced...
The fix for this is quite straightforward, if you can recompile pv: in loop.c, change line 154 to target = (from target +=), resulting in
|| (cur_time.tv_sec == next_ratecheck.tv_sec
&& cur_time.tv_usec >=
next_ratecheck.tv_usec)) {
target =
((long double) (state->rate_limit)) /
(long double) (1000000 /
RATE_GRANULARITY);
Once thatâÂÂs done, rate limit reductions are applied immediately (well, within one rate-limit cycle).
I know I'm not supposed to say +1 but I'm going to do so. At least for a little while. This is a great answer to a question that piqued my curiosity.
â roaima
Jan 24 at 15:13
add a comment |Â
up vote
0
down vote
It seems to be a buffering issue. Here is my test-bed:
pv --pidfile /tmp/pv.pid --rate-limit 1K </dev/zero |
ssh remote 'cat>/dev/null'
and here is my control:
pv --rate-limit 100M --remote $(cat /tmp/pv.pid)
sleep 1
pv --rate-limit 1K --remote $(cat /tmp/pv.pid)
With a one second interval it takes around 13 seconds for the running pv to reduce from its attempt at 100MB/s (1Gb/s) down to its final target of 1KB/s. Increasing the sleep interval by 1 second increases the time to achieve the final target by almost 10 seconds:
Sleep Delay
1 13
2 22
3 28
4 37
Four samples isn't really enough for a trend line so I'm going to avoid suggesting it's a linear correlation.
Can you try 500M or 1000M ? I have the problem only when i set higher than 100M i believe.
â Morphinz
Jan 24 at 14:26
YouâÂÂll only get the problem with rate-limits higher than your line capacity (see my answer for the explanation). Presumably your line capacity is ~100M.
â Stephen Kitt
Jan 24 at 14:36
@StephenKitt I'm running GbE so I have a theoretical maximum upper limit of 100MB/s, yes.
â roaima
Jan 24 at 15:08
Sorry roaima, I was addressing @MorphinzâÂÂs comment ;-).
â Stephen Kitt
Jan 24 at 15:11
@StephenKitt no my line capacity is 10G and i have 40G fiber too. I only set 500 or 1G.
â Morphinz
Jan 24 at 15:29
 |Â
show 6 more comments
up vote
0
down vote
I am correcting myself; pv can change speed..
I don't know why but it need just some time according to your speed limit...
If you set it to 1G, you have to wait 45 sec to reduce speed.
5G - 5 min.
10G - 7 min.
For example:
Commands:
pv --pidfile /tmp/pv.pid --rate-limit 10G </dev/zero | ssh 10.1.1.5 'cat>/dev/null'
pv --rate-limit 1M --remote $(cat /tmp/pv.pid)
-ON 10Gb/s network card:
3.99GiB 0:02:26 [ 157MiB/s] (Right here i just changed to 1M)
26.1GiB 0:02:30 [ 160MiB/s]
77.6GiB 0:09:38 [1.01MiB/s]
After 7 minutes the speed changed finally...
-ON 1Gb/s network card:
I started again with 10G limit.
770MiB 0:00:07 [ 112MiB/s]
44.5GiB 0:06:49 [ 111MiB/s]
46.4GiB 0:07:31 [1.00MiB/s]
Results are the same.
If you change speed 10G to 1M you need to wait 7min at least.
But if you change speed 1M to 10G you don't need to wait any second.
I don't think its just about with buffer because 7min (45Gb) must too big for buffer. but this is just my opinion.
Right, my use of the term âÂÂbufferingâ was incorrect and misleading, âÂÂaccountingâ is more appropriate. IâÂÂve added an example to my answer which hopefully will clarify things.
â Stephen Kitt
Jan 25 at 8:46
@StephenKitt Do you have any other idea about the problem? Upgrade works great. Downgrade needs time but why?
â Morphinz
Jan 25 at 13:46
Did you see the example in my updated answer? When downgrading, it takes a while for the target to catch up, andpvdoesnâÂÂt limit its output.
â Stephen Kitt
Jan 25 at 13:49
@StephenKitt Yes I saw. But 7 min is too long. Can i speed up downgrading?
â Morphinz
Jan 26 at 7:28
You can if youâÂÂre able to recompilepv, see my updated answer. I sent the patch to thepvauthor, perhaps it will be included in a future release.
â Stephen Kitt
Jan 26 at 7:56
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
This is caused by accounting in pv, which effectively means its rate-limiting is read-limited rather than write-limited. Looking at the source code shows that rate-limiting is driven by a âÂÂtargetâÂÂ, which is the amount remaining to send. If rate-limiting is on, once per rate limit evaluation cycle, the target is increased by however much weâÂÂre supposed to send according to the rate limit; the target is then decreased by however much is actually written. This means that if you set the rate limit to a value larger than the actual write capacity, the target will keep going up; reducing the rate limit wonâÂÂt then have any effect until pv has caught up with its target (including what itâÂÂs allowed to write according to the new rate limit).
To see this in action, start a basic pv:
pv /dev/zero /dev/null
Then control that:
pv -R 32605 -L 1M; sleep 10; pv -R 32605 -L 1G; sleep 1; pv -R 32605 -L 1M
YouâÂÂll see the impact of the target calculations by varying the duration of the second sleep...
Because of the write limitation, this only causes an issue when you set the rate limit to a value greater than the write capacity.
In a little more detail, hereâÂÂs how the accounting works with a flow initially limited to 1M, then to 1G for 5s, then back to 1M, on a connection capable of transmitting 400M:
Time Rate Target Sent Remaining
1 1M 1M 1M 0
2 1G 1G 400M 600M
3 1G 1.6G 400M 1.2G
4 1G 2.2G 400M 1.8G
5 1G 2.8G 400M 2.4G
6 1G 3.4G 400M 3G
7 1M 3001M 400M 2601M
8 1M 2602M 400M 2202M
9 1M 2203M 400M 1803M
10 1M 1804M 400M 1404M
11 1M 1405M 400M 1005M
12 1M 1006M 400M 606M
13 1M 607M 400M 207M
14 1M 208M 208M 0
15 1M 1M 1M 0
It takes 7s for the rate limit to be applied again. The longer the time spent with a high rate limit, the longer it takes for the reduced rate limit to be enforced...
The fix for this is quite straightforward, if you can recompile pv: in loop.c, change line 154 to target = (from target +=), resulting in
|| (cur_time.tv_sec == next_ratecheck.tv_sec
&& cur_time.tv_usec >=
next_ratecheck.tv_usec)) {
target =
((long double) (state->rate_limit)) /
(long double) (1000000 /
RATE_GRANULARITY);
Once thatâÂÂs done, rate limit reductions are applied immediately (well, within one rate-limit cycle).
I know I'm not supposed to say +1 but I'm going to do so. At least for a little while. This is a great answer to a question that piqued my curiosity.
â roaima
Jan 24 at 15:13
add a comment |Â
up vote
3
down vote
accepted
This is caused by accounting in pv, which effectively means its rate-limiting is read-limited rather than write-limited. Looking at the source code shows that rate-limiting is driven by a âÂÂtargetâÂÂ, which is the amount remaining to send. If rate-limiting is on, once per rate limit evaluation cycle, the target is increased by however much weâÂÂre supposed to send according to the rate limit; the target is then decreased by however much is actually written. This means that if you set the rate limit to a value larger than the actual write capacity, the target will keep going up; reducing the rate limit wonâÂÂt then have any effect until pv has caught up with its target (including what itâÂÂs allowed to write according to the new rate limit).
To see this in action, start a basic pv:
pv /dev/zero /dev/null
Then control that:
pv -R 32605 -L 1M; sleep 10; pv -R 32605 -L 1G; sleep 1; pv -R 32605 -L 1M
YouâÂÂll see the impact of the target calculations by varying the duration of the second sleep...
Because of the write limitation, this only causes an issue when you set the rate limit to a value greater than the write capacity.
In a little more detail, hereâÂÂs how the accounting works with a flow initially limited to 1M, then to 1G for 5s, then back to 1M, on a connection capable of transmitting 400M:
Time Rate Target Sent Remaining
1 1M 1M 1M 0
2 1G 1G 400M 600M
3 1G 1.6G 400M 1.2G
4 1G 2.2G 400M 1.8G
5 1G 2.8G 400M 2.4G
6 1G 3.4G 400M 3G
7 1M 3001M 400M 2601M
8 1M 2602M 400M 2202M
9 1M 2203M 400M 1803M
10 1M 1804M 400M 1404M
11 1M 1405M 400M 1005M
12 1M 1006M 400M 606M
13 1M 607M 400M 207M
14 1M 208M 208M 0
15 1M 1M 1M 0
It takes 7s for the rate limit to be applied again. The longer the time spent with a high rate limit, the longer it takes for the reduced rate limit to be enforced...
The fix for this is quite straightforward, if you can recompile pv: in loop.c, change line 154 to target = (from target +=), resulting in
|| (cur_time.tv_sec == next_ratecheck.tv_sec
&& cur_time.tv_usec >=
next_ratecheck.tv_usec)) {
target =
((long double) (state->rate_limit)) /
(long double) (1000000 /
RATE_GRANULARITY);
Once thatâÂÂs done, rate limit reductions are applied immediately (well, within one rate-limit cycle).
I know I'm not supposed to say +1 but I'm going to do so. At least for a little while. This is a great answer to a question that piqued my curiosity.
â roaima
Jan 24 at 15:13
add a comment |Â
up vote
3
down vote
accepted
up vote
3
down vote
accepted
This is caused by accounting in pv, which effectively means its rate-limiting is read-limited rather than write-limited. Looking at the source code shows that rate-limiting is driven by a âÂÂtargetâÂÂ, which is the amount remaining to send. If rate-limiting is on, once per rate limit evaluation cycle, the target is increased by however much weâÂÂre supposed to send according to the rate limit; the target is then decreased by however much is actually written. This means that if you set the rate limit to a value larger than the actual write capacity, the target will keep going up; reducing the rate limit wonâÂÂt then have any effect until pv has caught up with its target (including what itâÂÂs allowed to write according to the new rate limit).
To see this in action, start a basic pv:
pv /dev/zero /dev/null
Then control that:
pv -R 32605 -L 1M; sleep 10; pv -R 32605 -L 1G; sleep 1; pv -R 32605 -L 1M
YouâÂÂll see the impact of the target calculations by varying the duration of the second sleep...
Because of the write limitation, this only causes an issue when you set the rate limit to a value greater than the write capacity.
In a little more detail, hereâÂÂs how the accounting works with a flow initially limited to 1M, then to 1G for 5s, then back to 1M, on a connection capable of transmitting 400M:
Time Rate Target Sent Remaining
1 1M 1M 1M 0
2 1G 1G 400M 600M
3 1G 1.6G 400M 1.2G
4 1G 2.2G 400M 1.8G
5 1G 2.8G 400M 2.4G
6 1G 3.4G 400M 3G
7 1M 3001M 400M 2601M
8 1M 2602M 400M 2202M
9 1M 2203M 400M 1803M
10 1M 1804M 400M 1404M
11 1M 1405M 400M 1005M
12 1M 1006M 400M 606M
13 1M 607M 400M 207M
14 1M 208M 208M 0
15 1M 1M 1M 0
It takes 7s for the rate limit to be applied again. The longer the time spent with a high rate limit, the longer it takes for the reduced rate limit to be enforced...
The fix for this is quite straightforward, if you can recompile pv: in loop.c, change line 154 to target = (from target +=), resulting in
|| (cur_time.tv_sec == next_ratecheck.tv_sec
&& cur_time.tv_usec >=
next_ratecheck.tv_usec)) {
target =
((long double) (state->rate_limit)) /
(long double) (1000000 /
RATE_GRANULARITY);
Once thatâÂÂs done, rate limit reductions are applied immediately (well, within one rate-limit cycle).
This is caused by accounting in pv, which effectively means its rate-limiting is read-limited rather than write-limited. Looking at the source code shows that rate-limiting is driven by a âÂÂtargetâÂÂ, which is the amount remaining to send. If rate-limiting is on, once per rate limit evaluation cycle, the target is increased by however much weâÂÂre supposed to send according to the rate limit; the target is then decreased by however much is actually written. This means that if you set the rate limit to a value larger than the actual write capacity, the target will keep going up; reducing the rate limit wonâÂÂt then have any effect until pv has caught up with its target (including what itâÂÂs allowed to write according to the new rate limit).
To see this in action, start a basic pv:
pv /dev/zero /dev/null
Then control that:
pv -R 32605 -L 1M; sleep 10; pv -R 32605 -L 1G; sleep 1; pv -R 32605 -L 1M
YouâÂÂll see the impact of the target calculations by varying the duration of the second sleep...
Because of the write limitation, this only causes an issue when you set the rate limit to a value greater than the write capacity.
In a little more detail, hereâÂÂs how the accounting works with a flow initially limited to 1M, then to 1G for 5s, then back to 1M, on a connection capable of transmitting 400M:
Time Rate Target Sent Remaining
1 1M 1M 1M 0
2 1G 1G 400M 600M
3 1G 1.6G 400M 1.2G
4 1G 2.2G 400M 1.8G
5 1G 2.8G 400M 2.4G
6 1G 3.4G 400M 3G
7 1M 3001M 400M 2601M
8 1M 2602M 400M 2202M
9 1M 2203M 400M 1803M
10 1M 1804M 400M 1404M
11 1M 1405M 400M 1005M
12 1M 1006M 400M 606M
13 1M 607M 400M 207M
14 1M 208M 208M 0
15 1M 1M 1M 0
It takes 7s for the rate limit to be applied again. The longer the time spent with a high rate limit, the longer it takes for the reduced rate limit to be enforced...
The fix for this is quite straightforward, if you can recompile pv: in loop.c, change line 154 to target = (from target +=), resulting in
|| (cur_time.tv_sec == next_ratecheck.tv_sec
&& cur_time.tv_usec >=
next_ratecheck.tv_usec)) {
target =
((long double) (state->rate_limit)) /
(long double) (1000000 /
RATE_GRANULARITY);
Once thatâÂÂs done, rate limit reductions are applied immediately (well, within one rate-limit cycle).
edited Jan 26 at 7:55
answered Jan 24 at 14:25
Stephen Kitt
142k22308371
142k22308371
I know I'm not supposed to say +1 but I'm going to do so. At least for a little while. This is a great answer to a question that piqued my curiosity.
â roaima
Jan 24 at 15:13
add a comment |Â
I know I'm not supposed to say +1 but I'm going to do so. At least for a little while. This is a great answer to a question that piqued my curiosity.
â roaima
Jan 24 at 15:13
I know I'm not supposed to say +1 but I'm going to do so. At least for a little while. This is a great answer to a question that piqued my curiosity.
â roaima
Jan 24 at 15:13
I know I'm not supposed to say +1 but I'm going to do so. At least for a little while. This is a great answer to a question that piqued my curiosity.
â roaima
Jan 24 at 15:13
add a comment |Â
up vote
0
down vote
It seems to be a buffering issue. Here is my test-bed:
pv --pidfile /tmp/pv.pid --rate-limit 1K </dev/zero |
ssh remote 'cat>/dev/null'
and here is my control:
pv --rate-limit 100M --remote $(cat /tmp/pv.pid)
sleep 1
pv --rate-limit 1K --remote $(cat /tmp/pv.pid)
With a one second interval it takes around 13 seconds for the running pv to reduce from its attempt at 100MB/s (1Gb/s) down to its final target of 1KB/s. Increasing the sleep interval by 1 second increases the time to achieve the final target by almost 10 seconds:
Sleep Delay
1 13
2 22
3 28
4 37
Four samples isn't really enough for a trend line so I'm going to avoid suggesting it's a linear correlation.
Can you try 500M or 1000M ? I have the problem only when i set higher than 100M i believe.
â Morphinz
Jan 24 at 14:26
YouâÂÂll only get the problem with rate-limits higher than your line capacity (see my answer for the explanation). Presumably your line capacity is ~100M.
â Stephen Kitt
Jan 24 at 14:36
@StephenKitt I'm running GbE so I have a theoretical maximum upper limit of 100MB/s, yes.
â roaima
Jan 24 at 15:08
Sorry roaima, I was addressing @MorphinzâÂÂs comment ;-).
â Stephen Kitt
Jan 24 at 15:11
@StephenKitt no my line capacity is 10G and i have 40G fiber too. I only set 500 or 1G.
â Morphinz
Jan 24 at 15:29
 |Â
show 6 more comments
up vote
0
down vote
It seems to be a buffering issue. Here is my test-bed:
pv --pidfile /tmp/pv.pid --rate-limit 1K </dev/zero |
ssh remote 'cat>/dev/null'
and here is my control:
pv --rate-limit 100M --remote $(cat /tmp/pv.pid)
sleep 1
pv --rate-limit 1K --remote $(cat /tmp/pv.pid)
With a one second interval it takes around 13 seconds for the running pv to reduce from its attempt at 100MB/s (1Gb/s) down to its final target of 1KB/s. Increasing the sleep interval by 1 second increases the time to achieve the final target by almost 10 seconds:
Sleep Delay
1 13
2 22
3 28
4 37
Four samples isn't really enough for a trend line so I'm going to avoid suggesting it's a linear correlation.
Can you try 500M or 1000M ? I have the problem only when i set higher than 100M i believe.
â Morphinz
Jan 24 at 14:26
YouâÂÂll only get the problem with rate-limits higher than your line capacity (see my answer for the explanation). Presumably your line capacity is ~100M.
â Stephen Kitt
Jan 24 at 14:36
@StephenKitt I'm running GbE so I have a theoretical maximum upper limit of 100MB/s, yes.
â roaima
Jan 24 at 15:08
Sorry roaima, I was addressing @MorphinzâÂÂs comment ;-).
â Stephen Kitt
Jan 24 at 15:11
@StephenKitt no my line capacity is 10G and i have 40G fiber too. I only set 500 or 1G.
â Morphinz
Jan 24 at 15:29
 |Â
show 6 more comments
up vote
0
down vote
up vote
0
down vote
It seems to be a buffering issue. Here is my test-bed:
pv --pidfile /tmp/pv.pid --rate-limit 1K </dev/zero |
ssh remote 'cat>/dev/null'
and here is my control:
pv --rate-limit 100M --remote $(cat /tmp/pv.pid)
sleep 1
pv --rate-limit 1K --remote $(cat /tmp/pv.pid)
With a one second interval it takes around 13 seconds for the running pv to reduce from its attempt at 100MB/s (1Gb/s) down to its final target of 1KB/s. Increasing the sleep interval by 1 second increases the time to achieve the final target by almost 10 seconds:
Sleep Delay
1 13
2 22
3 28
4 37
Four samples isn't really enough for a trend line so I'm going to avoid suggesting it's a linear correlation.
It seems to be a buffering issue. Here is my test-bed:
pv --pidfile /tmp/pv.pid --rate-limit 1K </dev/zero |
ssh remote 'cat>/dev/null'
and here is my control:
pv --rate-limit 100M --remote $(cat /tmp/pv.pid)
sleep 1
pv --rate-limit 1K --remote $(cat /tmp/pv.pid)
With a one second interval it takes around 13 seconds for the running pv to reduce from its attempt at 100MB/s (1Gb/s) down to its final target of 1KB/s. Increasing the sleep interval by 1 second increases the time to achieve the final target by almost 10 seconds:
Sleep Delay
1 13
2 22
3 28
4 37
Four samples isn't really enough for a trend line so I'm going to avoid suggesting it's a linear correlation.
answered Jan 24 at 14:24
roaima
39.7k545108
39.7k545108
Can you try 500M or 1000M ? I have the problem only when i set higher than 100M i believe.
â Morphinz
Jan 24 at 14:26
YouâÂÂll only get the problem with rate-limits higher than your line capacity (see my answer for the explanation). Presumably your line capacity is ~100M.
â Stephen Kitt
Jan 24 at 14:36
@StephenKitt I'm running GbE so I have a theoretical maximum upper limit of 100MB/s, yes.
â roaima
Jan 24 at 15:08
Sorry roaima, I was addressing @MorphinzâÂÂs comment ;-).
â Stephen Kitt
Jan 24 at 15:11
@StephenKitt no my line capacity is 10G and i have 40G fiber too. I only set 500 or 1G.
â Morphinz
Jan 24 at 15:29
 |Â
show 6 more comments
Can you try 500M or 1000M ? I have the problem only when i set higher than 100M i believe.
â Morphinz
Jan 24 at 14:26
YouâÂÂll only get the problem with rate-limits higher than your line capacity (see my answer for the explanation). Presumably your line capacity is ~100M.
â Stephen Kitt
Jan 24 at 14:36
@StephenKitt I'm running GbE so I have a theoretical maximum upper limit of 100MB/s, yes.
â roaima
Jan 24 at 15:08
Sorry roaima, I was addressing @MorphinzâÂÂs comment ;-).
â Stephen Kitt
Jan 24 at 15:11
@StephenKitt no my line capacity is 10G and i have 40G fiber too. I only set 500 or 1G.
â Morphinz
Jan 24 at 15:29
Can you try 500M or 1000M ? I have the problem only when i set higher than 100M i believe.
â Morphinz
Jan 24 at 14:26
Can you try 500M or 1000M ? I have the problem only when i set higher than 100M i believe.
â Morphinz
Jan 24 at 14:26
YouâÂÂll only get the problem with rate-limits higher than your line capacity (see my answer for the explanation). Presumably your line capacity is ~100M.
â Stephen Kitt
Jan 24 at 14:36
YouâÂÂll only get the problem with rate-limits higher than your line capacity (see my answer for the explanation). Presumably your line capacity is ~100M.
â Stephen Kitt
Jan 24 at 14:36
@StephenKitt I'm running GbE so I have a theoretical maximum upper limit of 100MB/s, yes.
â roaima
Jan 24 at 15:08
@StephenKitt I'm running GbE so I have a theoretical maximum upper limit of 100MB/s, yes.
â roaima
Jan 24 at 15:08
Sorry roaima, I was addressing @MorphinzâÂÂs comment ;-).
â Stephen Kitt
Jan 24 at 15:11
Sorry roaima, I was addressing @MorphinzâÂÂs comment ;-).
â Stephen Kitt
Jan 24 at 15:11
@StephenKitt no my line capacity is 10G and i have 40G fiber too. I only set 500 or 1G.
â Morphinz
Jan 24 at 15:29
@StephenKitt no my line capacity is 10G and i have 40G fiber too. I only set 500 or 1G.
â Morphinz
Jan 24 at 15:29
 |Â
show 6 more comments
up vote
0
down vote
I am correcting myself; pv can change speed..
I don't know why but it need just some time according to your speed limit...
If you set it to 1G, you have to wait 45 sec to reduce speed.
5G - 5 min.
10G - 7 min.
For example:
Commands:
pv --pidfile /tmp/pv.pid --rate-limit 10G </dev/zero | ssh 10.1.1.5 'cat>/dev/null'
pv --rate-limit 1M --remote $(cat /tmp/pv.pid)
-ON 10Gb/s network card:
3.99GiB 0:02:26 [ 157MiB/s] (Right here i just changed to 1M)
26.1GiB 0:02:30 [ 160MiB/s]
77.6GiB 0:09:38 [1.01MiB/s]
After 7 minutes the speed changed finally...
-ON 1Gb/s network card:
I started again with 10G limit.
770MiB 0:00:07 [ 112MiB/s]
44.5GiB 0:06:49 [ 111MiB/s]
46.4GiB 0:07:31 [1.00MiB/s]
Results are the same.
If you change speed 10G to 1M you need to wait 7min at least.
But if you change speed 1M to 10G you don't need to wait any second.
I don't think its just about with buffer because 7min (45Gb) must too big for buffer. but this is just my opinion.
Right, my use of the term âÂÂbufferingâ was incorrect and misleading, âÂÂaccountingâ is more appropriate. IâÂÂve added an example to my answer which hopefully will clarify things.
â Stephen Kitt
Jan 25 at 8:46
@StephenKitt Do you have any other idea about the problem? Upgrade works great. Downgrade needs time but why?
â Morphinz
Jan 25 at 13:46
Did you see the example in my updated answer? When downgrading, it takes a while for the target to catch up, andpvdoesnâÂÂt limit its output.
â Stephen Kitt
Jan 25 at 13:49
@StephenKitt Yes I saw. But 7 min is too long. Can i speed up downgrading?
â Morphinz
Jan 26 at 7:28
You can if youâÂÂre able to recompilepv, see my updated answer. I sent the patch to thepvauthor, perhaps it will be included in a future release.
â Stephen Kitt
Jan 26 at 7:56
add a comment |Â
up vote
0
down vote
I am correcting myself; pv can change speed..
I don't know why but it need just some time according to your speed limit...
If you set it to 1G, you have to wait 45 sec to reduce speed.
5G - 5 min.
10G - 7 min.
For example:
Commands:
pv --pidfile /tmp/pv.pid --rate-limit 10G </dev/zero | ssh 10.1.1.5 'cat>/dev/null'
pv --rate-limit 1M --remote $(cat /tmp/pv.pid)
-ON 10Gb/s network card:
3.99GiB 0:02:26 [ 157MiB/s] (Right here i just changed to 1M)
26.1GiB 0:02:30 [ 160MiB/s]
77.6GiB 0:09:38 [1.01MiB/s]
After 7 minutes the speed changed finally...
-ON 1Gb/s network card:
I started again with 10G limit.
770MiB 0:00:07 [ 112MiB/s]
44.5GiB 0:06:49 [ 111MiB/s]
46.4GiB 0:07:31 [1.00MiB/s]
Results are the same.
If you change speed 10G to 1M you need to wait 7min at least.
But if you change speed 1M to 10G you don't need to wait any second.
I don't think its just about with buffer because 7min (45Gb) must too big for buffer. but this is just my opinion.
Right, my use of the term âÂÂbufferingâ was incorrect and misleading, âÂÂaccountingâ is more appropriate. IâÂÂve added an example to my answer which hopefully will clarify things.
â Stephen Kitt
Jan 25 at 8:46
@StephenKitt Do you have any other idea about the problem? Upgrade works great. Downgrade needs time but why?
â Morphinz
Jan 25 at 13:46
Did you see the example in my updated answer? When downgrading, it takes a while for the target to catch up, andpvdoesnâÂÂt limit its output.
â Stephen Kitt
Jan 25 at 13:49
@StephenKitt Yes I saw. But 7 min is too long. Can i speed up downgrading?
â Morphinz
Jan 26 at 7:28
You can if youâÂÂre able to recompilepv, see my updated answer. I sent the patch to thepvauthor, perhaps it will be included in a future release.
â Stephen Kitt
Jan 26 at 7:56
add a comment |Â
up vote
0
down vote
up vote
0
down vote
I am correcting myself; pv can change speed..
I don't know why but it need just some time according to your speed limit...
If you set it to 1G, you have to wait 45 sec to reduce speed.
5G - 5 min.
10G - 7 min.
For example:
Commands:
pv --pidfile /tmp/pv.pid --rate-limit 10G </dev/zero | ssh 10.1.1.5 'cat>/dev/null'
pv --rate-limit 1M --remote $(cat /tmp/pv.pid)
-ON 10Gb/s network card:
3.99GiB 0:02:26 [ 157MiB/s] (Right here i just changed to 1M)
26.1GiB 0:02:30 [ 160MiB/s]
77.6GiB 0:09:38 [1.01MiB/s]
After 7 minutes the speed changed finally...
-ON 1Gb/s network card:
I started again with 10G limit.
770MiB 0:00:07 [ 112MiB/s]
44.5GiB 0:06:49 [ 111MiB/s]
46.4GiB 0:07:31 [1.00MiB/s]
Results are the same.
If you change speed 10G to 1M you need to wait 7min at least.
But if you change speed 1M to 10G you don't need to wait any second.
I don't think its just about with buffer because 7min (45Gb) must too big for buffer. but this is just my opinion.
I am correcting myself; pv can change speed..
I don't know why but it need just some time according to your speed limit...
If you set it to 1G, you have to wait 45 sec to reduce speed.
5G - 5 min.
10G - 7 min.
For example:
Commands:
pv --pidfile /tmp/pv.pid --rate-limit 10G </dev/zero | ssh 10.1.1.5 'cat>/dev/null'
pv --rate-limit 1M --remote $(cat /tmp/pv.pid)
-ON 10Gb/s network card:
3.99GiB 0:02:26 [ 157MiB/s] (Right here i just changed to 1M)
26.1GiB 0:02:30 [ 160MiB/s]
77.6GiB 0:09:38 [1.01MiB/s]
After 7 minutes the speed changed finally...
-ON 1Gb/s network card:
I started again with 10G limit.
770MiB 0:00:07 [ 112MiB/s]
44.5GiB 0:06:49 [ 111MiB/s]
46.4GiB 0:07:31 [1.00MiB/s]
Results are the same.
If you change speed 10G to 1M you need to wait 7min at least.
But if you change speed 1M to 10G you don't need to wait any second.
I don't think its just about with buffer because 7min (45Gb) must too big for buffer. but this is just my opinion.
edited Jan 26 at 7:40
answered Jan 24 at 16:50
Morphinz
13110
13110
Right, my use of the term âÂÂbufferingâ was incorrect and misleading, âÂÂaccountingâ is more appropriate. IâÂÂve added an example to my answer which hopefully will clarify things.
â Stephen Kitt
Jan 25 at 8:46
@StephenKitt Do you have any other idea about the problem? Upgrade works great. Downgrade needs time but why?
â Morphinz
Jan 25 at 13:46
Did you see the example in my updated answer? When downgrading, it takes a while for the target to catch up, andpvdoesnâÂÂt limit its output.
â Stephen Kitt
Jan 25 at 13:49
@StephenKitt Yes I saw. But 7 min is too long. Can i speed up downgrading?
â Morphinz
Jan 26 at 7:28
You can if youâÂÂre able to recompilepv, see my updated answer. I sent the patch to thepvauthor, perhaps it will be included in a future release.
â Stephen Kitt
Jan 26 at 7:56
add a comment |Â
Right, my use of the term âÂÂbufferingâ was incorrect and misleading, âÂÂaccountingâ is more appropriate. IâÂÂve added an example to my answer which hopefully will clarify things.
â Stephen Kitt
Jan 25 at 8:46
@StephenKitt Do you have any other idea about the problem? Upgrade works great. Downgrade needs time but why?
â Morphinz
Jan 25 at 13:46
Did you see the example in my updated answer? When downgrading, it takes a while for the target to catch up, andpvdoesnâÂÂt limit its output.
â Stephen Kitt
Jan 25 at 13:49
@StephenKitt Yes I saw. But 7 min is too long. Can i speed up downgrading?
â Morphinz
Jan 26 at 7:28
You can if youâÂÂre able to recompilepv, see my updated answer. I sent the patch to thepvauthor, perhaps it will be included in a future release.
â Stephen Kitt
Jan 26 at 7:56
Right, my use of the term âÂÂbufferingâ was incorrect and misleading, âÂÂaccountingâ is more appropriate. IâÂÂve added an example to my answer which hopefully will clarify things.
â Stephen Kitt
Jan 25 at 8:46
Right, my use of the term âÂÂbufferingâ was incorrect and misleading, âÂÂaccountingâ is more appropriate. IâÂÂve added an example to my answer which hopefully will clarify things.
â Stephen Kitt
Jan 25 at 8:46
@StephenKitt Do you have any other idea about the problem? Upgrade works great. Downgrade needs time but why?
â Morphinz
Jan 25 at 13:46
@StephenKitt Do you have any other idea about the problem? Upgrade works great. Downgrade needs time but why?
â Morphinz
Jan 25 at 13:46
Did you see the example in my updated answer? When downgrading, it takes a while for the target to catch up, and
pv doesnâÂÂt limit its output.â Stephen Kitt
Jan 25 at 13:49
Did you see the example in my updated answer? When downgrading, it takes a while for the target to catch up, and
pv doesnâÂÂt limit its output.â Stephen Kitt
Jan 25 at 13:49
@StephenKitt Yes I saw. But 7 min is too long. Can i speed up downgrading?
â Morphinz
Jan 26 at 7:28
@StephenKitt Yes I saw. But 7 min is too long. Can i speed up downgrading?
â Morphinz
Jan 26 at 7:28
You can if youâÂÂre able to recompile
pv, see my updated answer. I sent the patch to the pv author, perhaps it will be included in a future release.â Stephen Kitt
Jan 26 at 7:56
You can if youâÂÂre able to recompile
pv, see my updated answer. I sent the patch to the pv author, perhaps it will be included in a future release.â Stephen Kitt
Jan 26 at 7:56
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f419341%2fpipe-viewer-problem-with-changing-rate-limit%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
@roaima its hard to show live process. But i will edit with examples
â Morphinz
Jan 24 at 13:13
Looks like a bug
â roaima
Jan 24 at 13:25
... or some sort of buffering perhaps â I see the limit being applied even with a single request, however it does take a very long time!
â Stephen Kitt
Jan 24 at 13:36
I wondered about buffering too. Maybe running an unchangeable
pv -L 10M </dev/zeroas a source to thepvunder test can exclude a possible buffering issueâ roaima
Jan 24 at 14:00