Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Author Topic: Algorithmic problem  (Read 512 times)

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Algorithmic problem
« on: May 23, 2019, 04:39:58 PM »

I have had this funny problem now with defining upstream rate limiter values for my links given that line 3 is so much slower upstream than the others - currently about 420 kbps sync instead of around 500 kbps.

For each link, I apply a tweak, a speed reduction factor which I have named a ‘modem loading factor’. This is multiplied by the sync rate and again multiplied by a protocol efficiency factor = 0.8844 for me to get the IP upstream rate that I need. The modem loading factor is tweaked to get the best performance but too high and things don’t work properly, and 100% is not good, which probably means that the theoretical maximum rate calculated from sync rate and protocol efficiency is too optimistic.

So the question: how to set the modem loading rates correctly and in a way that will accommodate change and stay correct?

I have always parametrised the modem loading factors with just a simple array of four values, set by hand. But what if things were ever to change? For example, say that the slow line went away or another line became the slow one. Could I write a more general piece of code to take flexible parameters and do the right thing even in the case where the distribution of sync rates is different?

Some of the cases that I can think of:

1. all rates roughly the same - but how close ?
2. one very slow link, link n. All the others roughly the same
3. As above but say that link n is only slightly slower, do we care?
4. One link is much slower, but there is also an additional slow link
5. The second slow link is the same as the slowest, or nearly so
6. The second slow link is faster than the slowest
7. The distribution is all over the place.

Right now, I am using a very low value for the modem loading factor for line 3. I don’t know why though. Measurement carried out very carefully demonstrates that this value is optimal, but I don’t have an algorithm that arrives at this value and justifies it. So if conditions unknown change then I will not know what to do.

I could write some code that says find the slowest link and apply the arbitrary modem loading factor of k_min to it and use the value of k_others for the other links. But this perhaps only works now while I am in case #2 above.

I could just go ahead and do that. Improvements might be to detect the case where the slowest link is hardly any slower and not apply the exceptional k_min value, or derive some other intermediate value from it on a sliding scale according to the size of the gap between the minimum and the rest. Set a band within which we ignore small sync rate differences as log as the values are all close and so we then say we don’t really have a minimum.

What to do if there is more than one slow value ? Split the exceptional k_min rate? Apply it to each slow value? Or apply it to each rescaled according to how low they are? There could be two equally slow minima.

Any suggestions to restore sanity?

Also suggestions for (i) functions to use to derive sliding intermediate values and (ii) classification algorithms.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Algorithmic problem
« Reply #1 on: May 29, 2019, 10:01:40 PM »

I wrote some code, which works. It takes the upstream sync rates of all the modems, picks the slowest and sets an exceptional modem loading factor on that one, and a different modem loading factor on the others. It now calculated what that for-the-slowest exceptional modem loading factor is (k_min). The value calculated depends on how close the slowest sync rate is to the rest, how bunched up or spread apart the sync rates are. The further the min is away from the rest, the lower the calculated k_min value is.

The function I have used to determine k_min, the modem loading factor of the slowest line, is a linear function y= max( min_clamp, min( max_clamp, y2+m * x )) where x is the size of the gap between the min sync speed rate and the mean of the other speed rates and y2, m, min_clamp and max_clamp are constants. All the sync values used in the calculation are pre-scaled to max=1.0 because the values don’t matter only the ‘closeness’ of the bunching.

I have some problems with this though. I don’t know what ‘far away enough from the rest’ means, the fuzzy boundary between close and not close. At some separation, I want to pick that as ‘well separated’ and set the function up so that at some particular x, y=k_min( x ) = y1 where y1 is some constant set by experience and scenario testing.

I have had line 3 down to 250kbps but at least it’s managing at 419 Kbps now while the rest are 525, 499, 499 kbps so that shows the separation. The min is ‘x’ away from the rest there and I rescale the sync rates so that sync rate=525 maps to a max x=1.0. Now the modem loading factor that they all use apart from the slowest is 0.95 and the slowest should be y = k_min = 0.7 in the setup that I have tested. If the slowest line gets better then that 0.7 is allowed to rise to become closer to 0.95. However how fast? and what happens if it gets even worse? Clamping of the allowed output value keeps it under control so it cannot go further below 0.7 which is only sensible.

I don’t take any account of the other values’ distribution in detail - if there is a second sync rate that is only just a small amount above the minimum, then that information is not used. Worst of all, if several values are equal to the min, then I don’t handle that case properly. I have no idea what to do any way. Set them all to the same value ? Split the total, so that say if there were two minimum equal values then set the y = 0.95 - (0.95 - 0.7) / n_min where n_min = 2?
Logged