Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

Ah, thank you. Does this mean that 1.56 Jacoby is now a factory release, not a beta? Because I told myself I would not risk betas.

I’d be interested to know what upstream speeds anyone else is getting before and after changing to auto-percent.

[burakkucat]

Ah, thank you. Does this mean that 1.56 Jacoby is now a factory release, not a beta?

Your guess is as good as mine. Perhaps the page has not yet been updated? 

[Weaver]

My FB2900 is set to not update its software automatically; it requires a manual download and update. It tells you in its status webpage when there is a new release available. I seem to remember something about allowing beta releases to be downloaded, or allowing only full releases. I don’t know about the ‘new release available’ displayed in the UI, whether or not that shows you beta releases. Or alternatively maybe the allow-beta thing is only concerned with automatic upgrades. When will it prompt you about availability of a beta, does anyone know?

I do want to know whether or not I’m downloading a beta, as I am definitely not a risky early adopter.


Btw, as an experiment, I changed my ‘modem load factor’ (ie. auto_percent = modem_load_factor * protocol_efficiency; protocol_efficiency=0.8844 for my ADSL2) from 95% to 98%, and the system wasn’t happy at all. So (95% * protocol_efficiency) seems to be a really good choice for the auto-percent attribute, pretty close to the limit. I’m not sure, would have to check again, but I wrote down a note for myself that A&A’s protocol_efficiency value is 87.9%. Guesswork: The difference might be to do with their assumptions about typical PDU size, based as I do on the MTU, and they might be using an assumed PDU size = MTU = 1492 in their calculations rather than 1500 as do I. AA’s figure might be more realistic, for whatever reason, and mine might be optimistic.

[burakkucat]

Guesswork: The difference might be to do with their assumptions about typical PDU size, based as I do on the MTU, and they might be using an assumed PDU size = MTU = 1492 in their calculations rather than 1500 as do I. AA’s figure might be more realistic, for whatever reason, and mine might be optimistic.

You may well be right but, given that A&A are strong advocates of 1500 as the MTU, I am a little surprised that they appear to use the smaller value.

[Weaver]

If they use the smaller value, it could be the precautionary principle; it does no harm if a rate is a little bit under the critical value but things collapse if you push a link too hard.

[burakkucat]

Ah, yes. A good point and, probably, the fundamental reason.

[Alex Atkin UK]

This got me curious, checked the pfSense logs and both my lines show:
ppp[20345]: [wan] Bundle: Status update: up 1 link, total bandwidth 64000 bps

This is especially interesting as Plusnet portal says:
Current Line Speed (Download): 68.8Mbps

I measured actual throughput of 66Mbit a few days ago with the modem straight into my laptop and Windows PPPoE, that strangely reduced to 64Mbit through pfSense (which starts to get curious).

Am I clutching at straws or is there some correlation here?  (although I seem to only be pulling 61Mbit today from each line)

[Weaver]

I tried the assumption that 68.8 is the sync rate and so roughly 68.8 * 0.9669 = 66.5 Mbps would be the IP PDU rate, so could one system be talking in different terms/units? Quoted figures will be reduced a lot further still if it’s TCP SDU rate, ie. payload that is being quoted. The figure of 0.9669 was something I wrote down as the overhead for VDSL2 with a normal level of error correction, and some users will have a much worse figure of 0.91 if using G.INP=high. I believe I got these numbers from Kitz, so I’m hoping I remembered correctly.

[hopkins35]

Does this mean that 1.56 Jacoby is now a factory release, not a beta?

Jacoby is still in beta. If your brick is set to auto update to factory releases only it will still prompt you that a beta release is available and does label it as such and you have to manually initiate the update which is what you must have done.

The new setting itself looks to work as expected and sets the egress rate to the same number that I would have manually calculated

[Weaver]

Ah. I was fooled by the prompt as I don’t do automatic updates, so I have indeed unwittingly installed a beta, it seems. 

[burakkucat]

I believe it is possible to roll-back to the previous image . . . assuming I am remembering correctly what I read in the FB2900 documentation.

[Weaver]

I think so indeed and I remember that it will roll back automatically under certain conditions if it crashes. I’m going to stick with it now though because I’ve just changed a lot of iPad software that I wrote in iOS Shortcuts so that it works with the new auto-percent feature and no longer queries modems to get sync rates and derive speed="xxx" attribute values inserted into the config. I could roll such Shortcuts changes back but it’s a minor hassle. One example is a config upload routine that adapts the ppp elements in the config XML according to my config preferences before upload. I wrote the upload adaptation routine for the new auto-percent thing a while ago but couldn’t test it; luckily it worked first time when I switched it in. Now I actually don’t need the adaptation feature at all but kept it in in a new form because I can use it to experiment with tweaking the modem load factors (= fraction of max flat-out upstream speed) that I use to set the auto-percent values without editing the config XML by hand.

[burakkucat]

I see. That all make good sense. 

[Weaver]

I’ve been using the new “auto-percent” attribute feature for a while now and it works very nicely. Zero hassle from now on; no more  having to keep an eye out for changes in links’ upstream sync rates after which I then run my program that queries the modems, recalculates the upstream rates, inserts them in the <ppp /> elements in an XML config file template and uploads the derived config to the Firebrick. And the beta o/s has not given any problems. I will definitely upgrade to the next ‘factory’ release asap though, just to be on the safe side.

[burakkucat]

I’ve been using the new “auto-percent” attribute feature for a while now and it works very nicely. Zero hassle from now on; no more  having to keep an eye out for changes in links’ upstream sync rates after which I then run my program that queries the modems, recalculates the upstream rates, inserts them in the <ppp /> elements in an XML config file template and uploads the derived config to the Firebrick. And the beta o/s has not given any problems.

That's good to know and anything which minimises what you have to do is a definite bonus.
 

I will definitely upgrade to the next ‘factory’ release asap though, just to be on the safe side.

If I have fully understood the Firebrick (or, more specifically, the Adrian Kennard) concept of alpha, beta and factory releases, the next factory release will be the beta version you have currently installed just renamed . . . sed 's/beta/factory/'

Assuming, of course, that there are no recently discovered bugs that require squishing.