Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Weaver on May 25, 2019, 01:06:49 AM
-
I have just learned something. I did not know that G.Fast has SRA - at last ! I have G.992.3/G.992.5 and I don’t have it, even though it is badly needed.
(I would need to tap into some source of speed info for upstream rate, because my Firebrick router wants me to set the upstream rates for each modem correctly so that the split of upstream traffic between modems is correct.
I already have all of the above speed querying set up for my ZyXEL/Johnson custom firmware modem.)
-
Happy to swap you for this - https://www.thinkbroadband.com/speedtest/1558774170321317355 - which runs everything my family needs very nicely indeed.
:)
-
I don't want to go too much off the topic but... I'm sorry, mods.
I have just learned something. I did not know that G.Fast has SRA - at last ! I have G.992.3/G.992.5 and I don’t have it, even though it is badly needed.
At last? :P Seamless Rate Adaptation was introduced with G.992.3 and was also implemented in G.992.5, and even G.993.2 - though the ITU has said it is optional rather than mandatory. Some UK ISPs on LLU implemented it on G.992.3/5 back in the day - UKOnline, Be/O2 if I can recall correctly. As for G.993.2, it has been trialled on the Openreach network. To be honest, it would not be that beneficial to speed unless you had spare margin - it may make it less prone to losing sync when noise levels increase, but it would be sync'd lower in that case.
For G.9701 (G.fast), SRA is mandatory according to ITU. There's also Fast Rate Adaptation (FRA), which is also mandatory on G.fast. Information regarding this can be found here (https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.9701-201412-S!!PDF-E&type=items) (Recommendation G.9701 (12/14)) on p.268 and p.269, which is under section 13.1.1. I understand this document has been superseded, but I am not a TIES user and do not have access to 03/19.
SRA:
Seamless rate adaptation (SRA) is used to reconfigure the NDR by modifying the bits and gains (bi, gi), the data frame parameters (BDR, BD), and the DTU size (parameters KFEC, RFEC and Q).
FRA:
Fast rate adaptation (FRA) provides fast adaptation of the bit rate. FRA changes the bit-loading (bi) of some groups of subcarriers (sub-bands).
Happy to swap you for this - https://www.thinkbroadband.com/speedtest/1558774170321317355 - which runs everything my family needs very nicely indeed.
:)
I wonder, is it justified paying for 80/20 then (as your sig says)?
-
...
I wonder, is it justified paying for 80/20 then (as your sig says)?
I was originally on a cheap shareholder deal many years ago and each time my contract renews I barter with them to keep the price half decent. At present I am paying a bit more than I need to, but I'm always concerned that changing to a 52/10 service would invoke a DLM reset that I rather wouldn't have.
:)
-
@re0 I’m with you. By ‘at last’ I meant that although it’s in the spec of G.992.3, even though I now have G.992.5 and .3 I still I have no SRA, and I didn’t mean to imply that no one had it. :-) (I had forgotten what Kitz, maybe, said about the availability of SRA on non-BT wholesaled (wholesold?) services.)
AA, my ISP, gets speed change reports from BT - somehow. Does anyone know how? I’m not sure whether or not Kitz has written this up.
But AA seem to get events, unless they have to poll (shudders). They do some black magic rate reduction fraction (‘fudge factor’) to down-calculate from sync rate to PPP PDU rate (approx equal to IP PDU rate, near enough) by multiplication by a fixed factor it seems and then set their routers accordingly to rate limit the downstream traffic and split the traffic correctly across bonded line sets. You can (effectively) set the the fudge factor yourself in their clueless server’s UI. You can see speed changes noted with records in the log.
I ought to be doing the same thing myself for the upstream rate and upstream traffic but I don’t have any source of events. I would have to poll. Really it should be my Firebrick that is doing that. Don’t know why / how AA can do this but my own Firebrick cannot. If I had an appropriate server I could use that to monitor things, watch the link rates, and control the Firebrick. But all of that is really the Brick’s job but it is an impossible task as the details of it all are so widely variable. I can do a one-off manual check-and-reconfigure by running a one-click program that I have in my iPad, which queries the modems, does the calculations according to protocol efficiency and preferences, and then reconfigures the Firebrick live. But I don’t have any such thing that I can leave running.
With SRA, I might be in trouble. AA might or might not get a lot of events, and I’m assuming things would just work in the same way as other DSL speed changes after a retrain ?
So unfortunately I might have to turn it off, despite my praise and love of beautiful SRA, because of my problems with traffic splitting.
-
Hi
I had SRA for a time on ADSL2+ LLU line, didn't make any difference to stability or increase speed. Because a line typically sync's at its best speed, then all SRA does is reduce speed as some noise appears, then brings it back up to where it was before more or less even though the modem could have ridden the increase of noise without needing to reduce speed, this is why we have a margin in the first place.
From my observations, any noise that would have knocked out the sync on a modem without SRA, would also knock the modem out with SRA enabled.
Without SRA the SNR margin fluctuates with changes in noise whilst the sync stays the same, with SRA the sync speed fluctuates whilst the margin stays the same, but anything so bad that can knock out the connection completely, still does.
Sure we've had this conversation before :-)
Regards
Phil
-
Without SRA the SNR margin fluctuates with changes in noise whilst the sync stays the same, with SRA the sync speed fluctuates whilst the margin stays the same, but anything so bad that can knock out the connection completely, still does.
Its going to depend on the line.
When I was on adsl, my line suffered from sudden large drops on snr. Even with interleaving it would usually knock out the line, if the line wasnt knocked out, the sync would be generating errors in very high numbers and the connection would be not in a normal operating state (high packet loss). This happened every office working day all year round, the only breaks were weekends, bank holidays and christmas.
I joined ukonline and after a while I managed to get SRA enabled on the line, the benefit was immediate and long lasting. I had gone from dropping sync every day (either manually or by the line been knocked out) to able to hold a sync for over a year. When the noise bursts started, there would still be temporary packet loss before SRA kicked in, but it was for a few seconds only.
So from my experience I would say the prime situation for SRA to provide a benefit, is when a line receives sudden bursts of noise unpredictably that bitswapping cannot handle.
Of course its true SRA cannot increase sync speed over its initial sync, but thats fine, think of the alternatives. Either you resync during a noise burst and maybe hold the sync for a while but forever at the low speed event during periods of no noise, or you just keep dropping the sync every time the noise comes and goes. With SRA you would sync up at the optimal time, highest possible sync, it would automatically lower the sync speed when the burst starts with a few seconds of packet loss. Then the sync would automatically recover when the noise burst ends.
Now with my line it was so bad that without SRA if I synced up during a noise burst, I would not be able to hold the sync 24/7, because my noise bursts only ever happened during office hours in the daytime, and a day time sync would drop out at night because the high tones would get wiped out, syncing the line at night would load up the tones that get wiped out by the noise bursts, so in other words without SRA my line couldnt stay stable 24/7. Even on BT wholesale's most aggressive profile 15db noise margin with interleaving it couldnt hold out. Probably one of the worst lines on the openreach network and SRA dealt with it.
When ukonline closed up, the shock of losing SRA was just too much for the useability and I moved to a congested virgin media service. Didnt come back to dsl until VDSL was available. Luckily for me the problem was E side so now on VDSL I dont get the bursts anymore.
-
My crappy overhead line is exposed to the rain. SRA helps to reduce the amount of resyncs. An example how speed and SNRM changes over time:
(https://abload.de/thumb/sra.speed9ujwg.png) (https://abload.de/img/sra.speed9ujwg.png) (https://abload.de/thumb/sra.snrmkwjwt.png) (https://abload.de/img/sra.snrmkwjwt.png)
-
We should be seeing a lot more plots like that as SRA is being trialled on VDSL2 by OpenReach at the moment.
Without SRA the line plotted above would no doubt have resynced.
-
Hauwei only right?
-
SRA would be a marvellous thing for my nightmare line3 upstream, with a low-half+high-half (v approx) of the day SNRM. It would dig me out of the chaos.
-
yeah the behaviour of that line is primed for SRA.
-
Here is an example of a bit of nasty noise, causing SNRM to fluctate and CRCs. SRA/FRA seems to made some adjustments just prior to 14:48. Beyond that, it only looks like the attainable was impacted.