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: Rate equalisation by forced tweaking  (Read 1143 times)

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Rate equalisation by forced tweaking
« on: November 22, 2018, 03:39:33 AM »

Currently my four lines are running at downstream sync rates of 3.19, 3.02, 3.12, 3.11. My current modems, ZyXEL VMG 1312-B10As, are tweakable. I had rather an odd idea: Say I tweak the slowest to raise it to 3.11 Mbps, at some risk, or tweak three to raise them all to 3.19Mbps. That ought to give me another 320kbps. Question: would the benefit be actually more than that though, because the lines would then all be at an identical speed ?

Yes, I know, trying it is the answer.

Jitter, in a sense, variation in arrival times depending on which line a transmitted packet is allocated to would be non-existent if the lines were all at the same speed. (Assuming the system is not already smart enough to compensate for such timing variations by controlling the time of each packet-send appropriately depending on each line rate and the length of the ingress queue into each modem. Both should be knowable, provided line rate info is supplied.) Would elimination of jitter make a receiving TCP, or even both TCP entities, happier?

Actually getting the tweaking right though would not be easy. I have no idea what the tweak values need to be. Burrakucat has supplied me with the equation to convert dB of SNRM into the required parameter value for the appropriate magic Broadcom tweak command. That doesn’t help me without a knowledge of how to map dB SNRM into sync rates. And repeated attempts, groping to get the values correct, getting it wrong again and again, might upset the DLM Gods. Also, I would need to pick a time of day when noise levels are favourable.

An alternative plan would be to pick the time of day when SNR is at the lowest and then equalise speeds to some other speed that is attainable at that time. That way, I would not be pushing any line too hard, increasing risk of failure by raising the weakest line too much.

Most radical of all, would be to lower the faster lines by raising target SNRM, not by choosing time-of-day. If equality really dies give some extra benefit, I wonder if I could get back some of, or even more than, that which I lose.
« Last Edit: November 22, 2018, 03:49:05 AM by Weaver »
Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Rate equalisation by forced tweaking
« Reply #1 on: December 12, 2018, 03:13:25 PM »

How's your downstream load balancing carried out, is it packet by packet or are they fragmented?  Are you thinking that packets might overtake and arrive out of order if the speeds are unequal?
Logged

j0hn

  • Kitizen
  • ****
  • Posts: 4093
Re: Rate equalisation by forced tweaking
« Reply #2 on: December 12, 2018, 04:07:45 PM »

It should in theory make no difference what so ever, as the Firebrick would still need to order the packets between the lines exactly as before.

The easiest way to have all lines matching exactly is use of the maxdatarate command.
By lowering the target SNRM on slower lines and setting a maxdatarate on all lines, you should be able to get them to match.

Perhaps ask Firebrick if they think it would help?
Logged
Talktalk FTTP 550/75 - Speedtest - BQM

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Rate equalisation by forced tweaking
« Reply #3 on: December 13, 2018, 02:06:09 PM »

@aesmith unfortunately it’s by whole IP packets, not fragmented.

Does PPP-multilink fragment its payload to get one single E.g. IP packet down the n links faster? I am told that for some reason PPP multilingual implementations have not been friendly with systems where the links are not all speed-matched. Don’t know if it’s true. And I don’t know if that could be fixed by more intelligent code.

I don’t know the details of the Firebrick’s multi-line IP load scheduling. There is something in the manual about it, which is available in the web, but I am too stupid to understand it.

I could write a scheduler that doesn’t get things out of order per flow for certain flow types, with an L4-snooper and rules about traffic types, plus correct info concerning the link speeds. It would be a design decision how strict to be as this might have some performance hindering consequences if taken too far. Presumably some receiving TCPs or other L4 protocols might be more or less upset about receiving out of order packets. I don’t actually know though how often one would get into a situation where there is a really severe tension between the last ounce of speed and an absolutely strict no crucially significant reordered per-flow arrival requirement.

I don’t think one would want to be intentionally fragmenting IPv4 using the IPv4 native mechanism, as firstly it would be madness, and then secondly there are DF packets, thirdly there is IPv6 in which there is no intermediate node fragmentation iirc, and lastly, it would be utter madness.
Logged
 

anything