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:

Pages: [1] 2 3

Author Topic: Firebrick finally adding automatic uplink speed detection  (Read 4253 times)

hopkins35

  • Member
  • **
  • Posts: 36
Firebrick finally adding automatic uplink speed detection
« on: February 20, 2021, 07:59:45 PM »

Of interest for those Firebrick users with bonded lines from Andrews & Arnold, the latest alpha releases feature the ability to auto detect the uplink speed of your lines:

Quote
Release notes from Alpha release 1.55.112 to Alpha release 1.55.113

PPPoE

    New option to pick up speed from connect message to set egress rate on PPP (ideal for bonding)

Note that because this is still in alpha you need support to enable alpha upgrades on your brick or wait until it makes it to beta!

Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Firebrick finally adding automatic uplink speed detection
« Reply #1 on: February 20, 2021, 09:12:26 PM »

Thank you for the note. I'm sure it will interest our friend Weaver.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Firebrick finally adding automatic uplink speed detection
« Reply #2 on: February 22, 2021, 04:09:13 PM »

I got a message from AA about this. Now when you PPP-connect, the connect response message that you see says "BBEUnnnnnnnn 1234567/123456" which is downstream/upstream speed, whereas before it was just the BBEU id. The speed units are sync rates presumably, will have to check that.

It mentioned that the Firebrick will have some new XML attribute which just means work out the upstream speed limits as x% of the upstream rate value seen in the connect response message. I’m assuming that I would perhaps have to rate conversion from sync rate to real IP rate and then further downrate that to taste, say 95% as I do currently. The first multiplication factor might either be 1 or the protocol efficiency factor (0.884434 for my situation with 32 bytes worth of overhead, ATM, and 1500 bytes PDUs), this multiplied by the 95% or whatever. But I’m assuming you just supply the combined multiplication factor, not the speed itself, and as the speed varies after any resync so the firebrick varies the rate limiting which will be superb.

This has been a long long time coming, but needed some imagination and changes to multiple systems. It’s going to really improve performance and reliability.

Do you know where there is any documentation for the XML for the new Firebrick software release?

I have already had to adjust some software I wrote in the light of the connect response change so as to strip off the down/up rates and leave just the BBEU id. The BBEU id is used to check whether or not the cables are plugged into the right lines, which it does by comparing the reality observed against a database which contains the correct expected values.

I think I will wait until it’s a factory full release before I change things. I will have to change some more software of mine. I have an iOS Shortcuts program for the iPad which does surgery on a Fredrick XML config file, generating a snippet containing <ppp /> elements that contain the the correct upstream rate limiter speeds, and inserting that snippet into the middle of the XML config before uploading the customised result. Currently this program gets the true current upstream rate by querying the modems and converting sync rates into IP PDU rates. It will need to be simplified to add in the new speed multipliers, whatever they are, and forget about the current "speed=" attributes setting absolute speeds. It can forget about querying modems and the only dynamic variable will be what I term the "modem loading factor (MLF)" which is the down-rating to taste, currently 95% and I’m assuming that will also need to be multiplied by the protocol efficiency (=IP PDU rate/sync rate) and that product of the two values put into some new attribute.
« Last Edit: February 24, 2021, 11:08:28 PM by Weaver »
Logged

Alex Atkin UK

  • Addicted Kitizen
  • *****
  • Posts: 5260
    • Thinkbroadband Quality Monitors
Re: Firebrick finally adding automatic uplink speed detection
« Reply #3 on: February 22, 2021, 07:26:10 PM »

I always assumed PPP must have a data rate to avoid trying to push more data down the link than is possible and was always puzzled why no routers seem to reveal this useful piece of information, let alone use it for setting QoS.  Although how does that work if you connect to PPP over a network with unknown capacity?

Then again, they also have the DSL sync rates and don't bother using those either.
Logged
Broadband: Zen Full Fibre 900 + Three 5G Routers: pfSense (Intel N100) + Huawei CPE Pro 2 H122-373 WiFi: Zyxel NWA210AX
Switches: Netgear MS510TXUP, Netgear MS510TXPP, Netgear GS110EMX My Broadband History & Ping Monitors

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Firebrick finally adding automatic uplink speed detection
« Reply #5 on: February 23, 2021, 03:42:46 PM »

I can see something called "auto-percent" defined as a ubyte in units of percent. Do we think that’s the new attribute we need?

And the next question is do I set it to 95% my choice of PPP IP modem loading factor (where 100% means flat out, the max the modem can take), or to 95 * 0.884434 including the protocol efficiency factor which is used to down-convert from sync rate to IP rate in my situation?
Logged

hopkins35

  • Member
  • **
  • Posts: 36
Re: Firebrick finally adding automatic uplink speed detection
« Reply #6 on: February 23, 2021, 08:16:49 PM »

Do we think that’s the new attribute we need?

I think that's a fair bet judging by the description. I'll be setting mine to 98 as I currently just multiply the uplink sync rate reported by my modems and/or the A&A control pages by 0.98.

I'm waiting for it to make it to beta before testing, I previously used one of the earlier betas that had a number of voip changes and had no problems with it. I left my brick set to auto update to factory releases and manually flashed the beta, then a couple of weeks later it flashed to the factory version once it was released with no drama
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Firebrick finally adding automatic uplink speed detection
« Reply #7 on: February 23, 2021, 09:48:20 PM »

Is the 98 the protocol efficiency for VDSL for you ?

I am using the protocol efficiency figure calculated for ADSL/ATM which for me is (1500+32 bytes ) / 48 = rounded up to 32 ATM cells, so 32 * (48 + 5) bytes per cell,  so the protocol efficiency is 1500 / (32 * (48+5)) = 0.884434, which would correspond to flat out, so the new attribute max for me would be 88% and I normally run at 95% of flat out, which would be 84% = 88%* 0.95
Logged

hopkins35

  • Member
  • **
  • Posts: 36
Re: Firebrick finally adding automatic uplink speed detection
« Reply #8 on: February 24, 2021, 08:41:28 AM »

Is the 98 the protocol efficiency for VDSL for you ?

I can't remember how I came by that number, it's been a few years now, it's entirely possible that I plucked it out of thin air
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Firebrick finally adding automatic uplink speed detection
« Reply #9 on: February 24, 2021, 10:30:35 AM »

This is my assumption either flat out = auto-percent=100, or else auto-percent=protocol_efficiency, where protocol efficiency is the conversion factor from sync rate to IP rate. And I favour the latter, where auto-percent=88 for flat-out adsl or 97 for flat-out VDSL. If you were using 98% before, then I assume you need 98% * 0.88 for adsl or 98% * 0.97 for ADSL.

Make sense? Let me know what works for you. But I would be surprised if the same number is right for auto-percent because I’m assuming that different units are being used there between sync rate and IP PDU rate. But I could easily be wrong; AA could already be including an intelligent conversion factor like my ‘protocol efficiency’.

I will test it by starting with my favourite 88% (=assumed 100% * protocol efficiency for ADSL) and then increasing it a lot in order to watch and see if performance gets faster or else no change or even gets worse because I’m overdriving the links.

« Last Edit: February 24, 2021, 11:04:50 PM by Weaver »
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Firebrick finally adding automatic uplink speed detection
« Reply #10 on: February 24, 2021, 02:09:18 PM »

I emailed AA to request clarification and the reply was that my opinion earlier is correct. Their recommended value auto-percent=88 for flat-out ADSL.

Alternatively, I would think auto-percent=97 for flat-out FTTC/VDSL2.

From AA’s reply to my email:
Quote
88% I think was calculated as an optimum level to shape to account for overheads and reduce packet loss.
I was talking about ADSL/ATM specifically in that context.

So again if you’re using VDSL2 it would I think be correct to use auto-percent=97 for flat-out, or say (97 * 0.95) or a bit higher, as a first experiment, which will avoid the risks of packet loss.
Logged

hopkins35

  • Member
  • **
  • Posts: 36
Re: Firebrick finally adding automatic uplink speed detection
« Reply #11 on: February 24, 2021, 02:10:32 PM »

Thanks @weaver, that's very helpful
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Firebrick finally adding automatic uplink speed detection
« Reply #12 on: March 11, 2021, 05:29:03 PM »

I’ve just upgraded my FB2900 to v1.56 Jacoby and am now using the new auto-percent attribute, set at 84%, for ADSL2, assuming flat-out=88.4%, calculated from the protocol efficiency in terms of byte bloat, and then taking 95% of that, as I mentioned when we were talking about this before.

If I use 100% of 0.884, then the links are broken! It seems that that represents a massive overload. So 95% seems like a very good guess. The https://speedtest.aa.net.uk results are disappointing though, with upstream at around 1.0 Mbps :-( as opposed to an expected 1.25-1.6 Mbps (varies wildly, don’t know why, and that’s even with conducting multiple tests and taking only the max, to get rid of statistical noise or other users being active).

BTW I got lost trying to find the release notes for this latest factory FB2900 release (Jacoby). Can anyone help me find them?
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Firebrick finally adding automatic uplink speed detection
« Reply #13 on: March 11, 2021, 05:48:09 PM »

BTW I got lost trying to find the release notes for this latest factory FB2900 release (Jacoby). Can anyone help me find them?

It appears that the website has not yet been updated, as the "Release notes from Factory release 1.54.101 to Factory release 1.55.111" are shown as current.

Factory release 1.55.111 was given the name "Hamman".
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Firebrick finally adding automatic uplink speed detection
« Reply #14 on: March 11, 2021, 05:55:50 PM »

Ah, look under the "Factory and Beta" tab on the website page, where "2021-03-11 Latest Beta release 1.56.000 (Jacoby)" is listed.

Quote from: Firebrick
Release notes from Factory release 1.55.111 to Beta release 1.56.000

  * Fix a bug in the flash logging, which could cause logging to stop working after a while

CQM

  * Graphs used to show a damping level even when damping not in use (i.e. l2tp damping not set), removed

DHCP

  * Added "circuit" to the matching rules for DHCP server IP pool (circuit being Agent Info option 82 circuit sub option 1)

ETUN

  * Add tx/rx packet stats

IPsec

  * Additional logging and status information for roaming pools
  * Add manually triggerable IKE clearing

L2TP

  * Issue with DOS limit on outgoing L2TP fixed

PPPoE

  * New option to pick up speed from connect message to set egress rate on PPP (ideal for bonding)

VoIP

  * Additional debug

Web control pages

  * Setup wizard bug when IPv6 defined
« Last Edit: March 11, 2021, 06:00:59 PM by burakkucat »
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.
Pages: [1] 2 3
 

anything