ACC: more ramp down logics

[Libra]

As a happy user of Gargoyle, I've of course enabled this great Active Congestion Control since my connection speed, like most, isn't constant throughout the day.

I've noticed that most of the time, the Link limit is much lower than my real connection speed at that exact time.
If I run an FTP download for some time, it slowly increases to reach more than 80% the initial speed.
Here's an example :
Total Download Bandwidth: 6000 kbps
Initial Link limit: 5400 kbps
Link limit after some time unattended: 2446 kbps
Link limit after 5 minutes of FTP download: about 4400 kbps
The Link limit can easily get wrongly ramped down by 1000 kbps in one hour.

So, I was wondering why my Link limit was often getting so low after some time.
I was first thinking my ISP was at fault, but then I found the explanation:
When the Link load reaches 30% of the Link limit, the ACC starts pinging.
Then each time the Filtered ping gets temporarily higher than the Ping time limit, the Link limit is ramped down.
The problem is that since the Link load isn't at more than 95% of the Link limit, the Link limit doesn't get ramped up when the ping gets lower than the low Ping time limit.

So, to resume, if the Link load isn't near the Link limit, it can just go (slowly) down. Then we need a long download using up all bandwidth to get back our full connection speed. Not really the intended purpose of the ACC, right?

Now, what's the point of slowly ramping down the Link limit when we're far from it? Is it to ensure the ACC will keep pinging in case the Link limit is actually much overestimated (which could prevent the Link load to reach the 30%, making the ACC blind) ?

Here's a suggestion for the ramp down logic:
- When we are at low monitoring speed (>30% but <95%): no slow ramp down
-- At lms, if the ping average stays up for say 10 seconds, use the average speed during these 10 seconds as the new Link limit
Then:
- When we are at high link load (near 95%), slowly ramp down the Link limit

This would also reduce the time needed to get a Link limit that prevents high pings, in cases where the connection capacity has decreased a lot after some time without being used.

[pbix]

The ACC logic is not what you described. The only reason the ACC will lower the link limit is if the ping times are higher than the ping limit and the download speed is greater than 15% of the speed you put in as you download link speed.

It is true that the ACC increases speed at a slower rate than it decreases speed. This is to achieve the fast response to a high ping that you suggest you want.

If your link limit is going down even when you have less than 30% utilization then your ping limit is too low. What limits are you using and what are your speeds? Try increasing your limit 2x.

There was an issues will such behaviour in earlier versions of Gargoyle. Are you using the current version?

[Libra]

The ACC logic is not what you described. The only reason the ACC will lower the link limit is if the ping times are higher than the ping limit and the download speed is greater than 15% of the speed you put in as you download link speed.

That's what I thought I meant, but I guess I wasn't as clear as I wanted to be.

If your link limit is going down even when you have less than 30% utilization then your ping limit is too low. What limits are you using and what are your speeds? Try increasing your limit 2x.

Well, it seems I have a hard time explaining myself.
Since I don't have any realtime class active, the pinging starts at 30% utilization, so there's no way my link limit could change below that 30% utilization limit. I didn't set a manual ping limit.

It is true that the ACC increases speed at a slower rate than it decreases speed. This is to achieve the fast response to a high ping that you suggest you want.

What I mean is that from time to time, while at >30% utilization but much less than 95% (by example at 50% utilization), my ping time shown in the ACC can get too high for a second or two. It's very temporarily but the ACC takes action and decreases my link limit. After some time, my link limit can get much lower than it should because of that.

So, I was wondering: what's the point of slowly decreasing my link limit because of a too high ping when the utilization is at 50%? If the link limit goes from 5000 kbps to 4975 kpbs (0.5% reduction) or even to 4900 kbps (2% reduction, when in realtime mode) while the utilization is at 50%, meaning a bandwidth of 2500 kbps, that new link limit won't help at all to reduce the ping. And since the link limit can be decreased once per second, with a 25 kbps decrease per second it will take 100 seconds before the link limit can begin to have any influence on the ping times.

That's why I was suggesting, in those cases (lower than 95% utilization), to average the ping time over a few seconds and then, if the ping is consistently too high, to set a new link limit at the current averaged bandwidth speed.
Then, the slow link limit adjustments could proceed to get the link as close as possible to to its maximum.

So, the slow link limit increase/decrease would be only active at at least 95% utilization and there would be fast link limit decrease when the average ping stays high for a few seconds.

It would speed up the ACC reaction to high pings, useful by example if the link hasn't been fully used for a few hours and if at that time the real link bandwidth was much higher than now (because by example we are now in the peak hours).
And at the same time, it would fix my problem with temporary high pings.

There was an issues will such behaviour in earlier versions of Gargoyle. Are you using the current version?

I'm using Gargoyle 1.5.10.

[pbix]

The ping times used by ACC are already filtered and the ramp down of the link limit should be much faster than 100 seconds. The actual ramp is proportional to the amount of ping error there is. Ping error is the difference between the target ping and the measure ping. I would say in not more than 20 seconds it should go from 100% to 20% if required to recover the ping.

Are you saying that your system takes 100 seconds to recover the ping times to normal? How long is it taking to recover the ping times in the scenario you describe?