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.