Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: KingJ on January 24, 2018, 08:23:11 PM
-
Hi folks,
Around 4 months ago, I moved my FTTC line to a different property, sticking with Zen. My line is pretty stable but towards the lower end of the speed estimates.
I've been logging my stats up to MyDSLWebStats since the line went live and things generally seem OK;
- SNR ranges from 5.8-6.2dB downstream and 6.1-7.4dB upstream
- Errored Seconds per Hour tend to be 0-2
- Attenuation constant 16.4dB
- hlog shows a nice smooth exponential curve
- Rarely resyncs - most resyncs have been because i've powercycled the modem and I rarely do this. There's only been one DLM initiated resync in the last few months (which I think was due to my SNR being above target)
- Roughly 450m from the cabinet, by road rather than as the crow files
However, my actual sync speed is around 10-12mbit below the modem's 'attainable' speed stat and my interleaving is set at what seems to be weirdly high - 1,432 down and 363 up. It also seems a little odd that even though the line has been active for over 4 months and i'm connected to a Huawei cabinet i've not had G.INP applied or had the target SNR decreased from 6 dB. I know this can take a little bit of time to apply, but poking around a few other threads on here it seems most people have had it applied by the 4 month mark on a new line.
I'm not sure if i'm misreading the stats and my line is actually performing well, but the high interleaving seems a little off to me given the stability of the line. I would appreciate if anyone can offer any insight! I'm currently using a Zyxel VMG1312-B10D in bridge mode, having switched to that from a HG612 around 2 months ago. The modem is connected directly to the master socket, there's no internal phone wiring connected. I did try performing a quiet line test and I heard a bit of static, however this could be because i'm using a cheap Argos Value cordless phone - unfortunately I don't have any other phones to test with! I did ask Zen about this too, but they mentioned that things seem to be all OK from their side without elaborating exactly what they checked.
Stats are available on MyDSLWebStats under the same username I use here. There is a G next to my name, but that's from when I was uploading under this username from the previous property, whose FTTC line was G.INP enabled!
Many thanks :)
-
Although I can't really offer a comment on your situation, I just want to point out that interleaving depth isn't a measurement you can use to determine if interleaving is high or not. Interleaving depth varies on a number of factors, but most importantly the sync rate, delay and INP values will adjust the interleaving depth.
To determine if you have 'high interleaving' it would be more useful to know what your delay and INP values are instead.
From your stats on MDWS I can see that you have an INP of 3 and a delay of 8ms on the downstream and an INP of 4 and a delay of 8ms on the upstream.
The lowest INP and delay applied by DLM is 3 with 8ms. This means your upstream is slightly higher than the lowest possible 'interleaving' that DLM applies.
The only thing I can say is that you're getting a reasonable amount of FEC errors per minute. I don't really know if DLM uses this as a possible way to say "no the line can't support lower INP/delay or such" or not, but my gut feeling would say that somehow it does as you appear to have been stuck on interleaving for some time. I also notice you're on a Huawei DSLAM, these support G.INP and 3 dB. I'm surprised your connection hasn't been switched to G.INP but there must be a reason I suppose. In the past the only way I've managed to encourage DLM to take positive action is by temporarily capping the connection sync rate on the modem myself, then leave it for a week or two (or a little longer).
-
My recommendation, if you can go a few days with a little less speed....
Cap the sync at 40Mb/14Mb
Leave it for a few days. Hopefully it will give DLM a kick and put the line on fastpath.
If there's high enough errors on fastpath it might apply G.INP.
I believe the command for your modem is..
adsl configure --maxDataRate 40000 14000 100000
It took 11 weeks for DLM to give me G.INP.
I was interleaved most of that time. A few days after I capped the line and shook interleaving I finally got G.INP
Or you can just wait patiently.
The default is that all lines with compatible modems should get G.INP but DLM seems to forget the odd few lines here and there.
-
Although I can't really offer a comment on your situation, I just want to point out that interleaving depth isn't a measurement you can use to determine if interleaving is high or not. Interleaving depth varies on a number of factors, but most importantly the sync rate, delay and INP values will adjust the interleaving depth.
Ah oops! I didn't realise that, thanks for the explanation!
From your stats on MDWS I can see that you have an INP of 3 and a delay of 8ms on the downstream and an INP of 4 and a delay of 8ms on the upstream.
The lowest INP and delay applied by DLM is 3 with 8ms. This means your upstream is slightly higher than the lowest possible 'interleaving' that DLM applies.
Interesting, so based off this DLM has applied interleaving, but at quite a low setting - so it's not quite as bad as I first thought.
My recommendation, if you can go a few days with a little less speed....
Cap the sync at 40Mb/14Mb
Leave it for a few days. Hopefully it will give DLM a kick and put the line on fastpath.
If there's high enough errors on fastpath it might apply G.INP.
I don't mind loosing a little bit of speed for a few days it it ultimately results in a long term gain. I've just run the command you've posted and it appears to have worked - the modem resynced and is currently connected at 40Mb/14Mb;
$ adsl info --state
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 21489 Kbps, Downstream rate = 69676 Kbps
Bearer: 0, Upstream rate = 14000 Kbps, Downstream rate = 39994 Kbps
If this does kick DLM in to gear, what should I expect to see in the next few days? Should DLM initate a resync and override the cap i've put on, or will I need to manually resync in a few days time to see if it's worked?
Thanks both for your help and explanations!
-
DLM should resync the line. My guess would be 2-3 days time.
The stats would show: Last Retrain Reason: 1 RDI
It will resync with the cap still in place. You need to reboot the modem or send another command to remove the cap.
Watch for a change in INP/Delay.
I'm pretty confident it will put the line back on fastpath.
Since your resync with the cap FEC's have dropped from around 5000/hour to practically nil. ES should also be much lower but after only an hour that's harder to tell.
If DLM removes interleaving (I think it will) I recommend you then remove the cap. ES numbers should shoot up quite a bit.
Then hopefully within a couple weeks DLM will apply G.INP.
-
DLM should resync the line. My guess would be 2-3 days time.
The stats would show: Last Retrain Reason: 1 RDI
It will resync with the cap still in place. You need to reboot the modem or send another command to remove the cap.
Watch for a change in INP/Delay.
I'm pretty confident it will put the line back on fastpath.
Since your resync with the cap FEC's have dropped from around 5000/hour to practically nil. ES should also be much lower but after only an hour that's harder to tell.
If DLM removes interleaving (I think it will) I recommend you then remove the cap. ES numbers should shoot up quite a bit.
Then hopefully within a couple weeks DLM will apply G.INP.
Wow yeah, i've just had a look at the B0 FEC graph myself and I had no idea it was that high before. To see it come down so dramatically is quite impressive.
I'll keep an eye out for a resync and then try and remove the cap after that, thanks for the information.
What's the best way to tell what 'path' my line is currently on?
-
The max attainable rate calculated while FEC/interleaving is on tends to be higher than what's actually possible. If FEC/interleaving gets switched off, I don't think you'll get what's currently reported as the max attainable rate.
-
DLM hasn't kicked in yet to resync the line, but it's only just been 2 days since I applied the cap so not expecting much yet!
Interestingly I had a huge burst in FEC errors over around 4 hours this afternoon, for no discernible reason. Things are back to normal now though with just a handful, odd all the same though!
Hoping DLM kicks in within the next couple of days and i'll update the thread when it does.
-
The max attainable rate calculated while FEC/interleaving is on tends to be higher than what's actually possible. If FEC/interleaving gets switched off, I don't think you'll get what's currently reported as the max attainable rate.
Having just had almost two days of interleaving, that was my experience.
The max attainable was showing as higher with interleaving on than it was either before the interleaving kicked in or afterwards.
-
So exactly 4 days and 49 minutes after I applied the cap, my line resynced during the day today with a reason of "1 Remote Defect Indicator/DLM"!
My downstream B0 INP value dropped from 3.5 to 0, so presumably that means Interleaving was removed? The upstream however has the same B0 INP value of 4. Tonight, I rebooted the modem to remove the cap and resync it and it resynced at 64mbit - a good 4mbit higher than before. As predicted by ejs too, now that interleaving has been removed the modem's predicted 'attainable' speed is now much closer to the actual sync speed (within 1mbit on the downstream).
So, everything's looking much better now! Hopefully within the next few days (upto 14?) DLM will kick in again and apply G.INP. My errored seconds have already shot up to 60.
Thanks everyone for your help so far, i'll keep this thread updated with how things go :)
I've also ordered a VMG1312-B10A to see if it performs any better on my line than my current VMG1312-B10D, but I won't swap it out until the line has stabilised so as not to be changing too many variables at once.
-
Excellent news. The downstream has returned to fastpath (No INP/interleaving/delay). Unfortunately the upstream is still interleaved but I'm not too surprised at that as it had a higher level of INP than the downstream.
Hopefully G.INP won't be too far behind. Fastpath gives higher sync and lower pings so still better than it was.
-
Unfortunately, DLM has just resynced the line again and interleaving has been applied back to the downstream. Sync has dropped and B0 INP is now back to 3.5 again. This happened just over 48 hours after DLM resynced the line to remove interleaving.
I wonder why it reapplied it? Do you think perhaps the fact I still had upstream interleaving even when capped meant that DLM never really 'forgot' about interleaving my line as a whole?
I'm willing to try recapping my line again, but would be interested to hear any suggestions first!
-
As an amateur, I'd say it was due to the huge amount of ES on the line.
-
Before I had a chance to re-apply a cap, the VMG1312-B10A arrived and so last night I ended up swapping the VMG1312-B10D for the VMG1312-B10A to see if it makes much of a difference.
Although not without problems (http://forum.kitz.co.uk/index.php/topic,20996.0.html), overall i've gained ~1mbit of sync. Attenuation has jumped from 16.4dB to 17.2dB which I understand is to be expected given the extra filtering built in to the VMG1312-B10A.
Interestingly though, both the bitswaps/min and the B0 FEC count has significantly dropped by about 5-10x, which is unexpected. Nothing else has changed in the interim so presumably this is all down to the improved filtering and chipset.
I'm going to leave the line for a few days, and then if DLM hasn't taken positive action i'm going to retry putting on the cap again but at a slightly lower setting, especially on the upstream.
-
I've just had DLM resync my line... and apply G.INP! Finally!
Sync has jumped up about 10mbit on the downstream to 69mbit, and up 3mbit on the upstream to 20mbit. With G.INP applied, interleaving has also gone away.
I'm wondering what ultimately made it happen? Was it the capping that partially removed interleaving for a few days? Or was it switching the modem from the VMG1312-B10D to the VMG1312-B10A and the susbsequent reduction in FEC error counts? Given the mystery around DLM i'm sure i'll never quite know what ultimately did it, but overall i'm very happy that i've finally had G.INP enabled, with the benefits to sync and latency reduction that it brings.
I'll keep an eye on things now to see if I get a reduced SNR applied too now that G.INP is enabled.
Thanks everyone here for their help!
-
I'd bet my mortgage that it was the capping of the line.
Your line did almost exactly what mine did, but I never changed modem inbetween.
You had sticky interleaving for months, no sign of G.INP.
You capped the line, interleaving dropped to fastpath.
You uncapped, interleaving returned. Within a short period G.INP was finally applied.
I've been watching this thread with great interest since I recommended the cap to see if it would work for you like it did for me.
My theory on this is that DLM simply gets "stuck". The cap simply gives DLM a nudge. When the profile changes to fastpath DLM wakes up and that line joins the orderly queue for G.INP.
There's a couple similar lines on MyDSLWebStats that I believe would have the exact same outcome if they capped their line to remove interleaving and give DLM a nudge.
-
:)
-
Nice, hopefully I won't be too far behind you!
-
I'd bet my mortgage that it was the capping of the line.
Your line did almost exactly what mine did, but I never changed modem inbetween.
You had sticky interleaving for months, no sign of G.INP.
You capped the line, interleaving dropped to fastpath.
You uncapped, interleaving returned. Within a short period G.INP was finally applied.
I've been watching this thread with great interest since I recommended the cap to see if it would work for you like it did for me.
My theory on this is that DLM simply gets "stuck". The cap simply gives DLM a nudge. When the profile changes to fastpath DLM wakes up and that line joins the orderly queue for G.INP.
There's a couple similar lines on MyDSLWebStats that I believe would have the exact same outcome if they capped their line to remove interleaving and give DLM a nudge.
That logic makes a lot of sense to me. Additionally, the resync today was at roughly the same time (early afternoon) as my resyncs when I applied the cap and when DLM removed the interleaving. Had the modem been the factor, I might have expected DLM to kick in around the time I switched out the modem (late evening).
Nice, hopefully I won't be too far behind you!
Fingers crossed! I've been watching your thread and i'm very interested to see if your connection follows the same pattern my one has!
-
sorry to hijack thought it best i post here instead of a new thread.
Im on Week 8 of a new line since moving house with no sign of g.inp, interleaved since day 1 with 8ms delay. Id be very interested in capping my line to speed things up a bit/give dlm a nudge but is it possible with a hg612 and custom firmware? Can someone maybe take a look at my stats and see if everything looks ok it would be greatly appreciated :baby:. having read this thread it seems possible dlm on my line is stuck. bt fault checker detected a fault on my line 1st week of install. openreach came and fixed it. they were here most of the day and in the end went up the pole and found quite a badly corroded junction box. my modem was flashing orange >blue >orange for around 6 hours :'( :no:
i do seem to lose connection once a day for around 5 minutes. the modem stays blue but the internet is completely gone and the bt splash page comes up. within a few minutes its back up
mdws username is markb G (the G is from our old house :'()
-
sorry to hijack thought it best i post here instead of a new thread.
Im on Week 8 of a new line since moving house with no sign of g.inp, interleaved since day 1 with 8ms delay. Id be very interested in capping my line to speed things up a bit/give dlm a nudge but is it possible with a hg612 and custom firmware? Can someone maybe take a look at my stats and see if everything looks ok it would be greatly appreciated :baby:. having read this thread it seems possible dlm on my line is stuck. bt fault checker detected a fault on my line 1st week of install. openreach came and fixed it. they were here most of the day and in the end went up the pole and found quite a badly corroded junction box. my modem was flashing orange >blue >orange for around 6 hours :'( :no:
i do seem to lose connection once a day for around 5 minutes. the modem stays blue but the internet is completely gone and the bt splash page comes up. within a few minutes its back up
mdws username is markb G (the G is from our old house :'()
Regarding applying your own banding/cap... all you need is an unlocked HG612, connect via telnet and run a specific command. See this thread (http://forum.kitz.co.uk/index.php/topic,16427.0.html) for more information.
-
great stuff and thank you. i have just read it over and im excited to get it done. but at what speed should i cap my line. im quite far from the cabinet so my sync speed is quite low to begin with. i will post my stats.
Uptime: 5 days 23 hours 56 min 25 sec
Resyncs: 0 (since 31 Jan 2018 17:50:52)
Downstream Upstream
Line attenuation (dB): 23.7 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 35469 7150
SNR margin (dB): 5.9 6.1
Power (dBm): 12.3 -0.5
Interleave depth: 695 1
INP: 3.00 0
G.INP: Not enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
-
Can you run the command xdslcmd info --stats and post the results. It provides much more info.
-
thank you for the reply. i have already gone ahead and capped the line at 18000 4000 so im unable to provide the old stats now. hopefully this is sufficinet enough. i assume theres some way of seeing them in mdws my username is 'markb'. 1 thing i noticed after the resync and cap is INP has gone from 3 to 3.5
new stats from cap:
# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 7037 Kbps, Downstream rate = 40444 Kbps
Bearer: 0, Upstream rate = 4000 Kbps, Downstream rate = 17998 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 16.1 11.6
Attn(dB): 23.7 0.0
Pwr(dBm): 12.4 -0.9
VDSL2 framing
Bearer 0
MSGc: 42 90
B: 31 110
M: 1 1
T: 64 20
R: 10 16
S: 0.0565 0.8797
L: 5952 1164
D: 577 1
I: 42 128
N: 42 128
Counters
Bearer 0
OHF: 418340 172415
OHFErr: 0 0
RS: 160572754 1752533
RSCorr: 532 0
RSUnCorr: 0 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 78624795 0
Data Cells: 3557927 0
Drop Cells: 0
Bit Errors: 0 0
ES: 250 217
SES: 11 0
UAS: 72 72
AS: 2276
Bearer 0
INP: 3.50 0.00
INPRein: 0.00 0.00
delay: 8 0
PER: 5.44 13.24
OR: 70.58 57.97
AgR: 18068.84 4058.14
Bitswap: 1868/1869 0/0
Total time = 1 days 2 hours 38 min 5 sec
FEC: 5107646 0
CRC: 4292 279
ES: 250 217
SES: 11 0
UAS: 72 72
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 8 min 5 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 414 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 2 hours 38 min 5 sec
FEC: 116059 0
CRC: 64 4
ES: 7 4
SES: 0 0
UAS: 45 45
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 556297 0
CRC: 96 33
ES: 29 30
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 37 min 55 sec
FEC: 532 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
-
Thanks. The cap looks more than sufficient and should return the line to fastpath.
Since Link time = 37 min 55 sec
FEC: 532 0
CRC: 0 0
ES: 0 0
Not much time to go by but FEC's look low enough for that period.
Your upstream isn't interleaved so didn't need capped but it won't do any harm.
The cap can be adjusted at anytime by sending the maxdatarate command again with your new figures.
-
when the line has reverted to fastpath will the dlm return the command to default or will i have to do it manually. the values being 80000 20000 100000 right? should i leave it in sync for some time before lifting the cap or is it best to lift it soon as ive noticed fastpath is enabled.
many thanks. mark
-
when the line has reverted to fastpath will the dlm return the command to default or will i have to do it manually. the values being 80000 20000 100000 right? should i leave it in sync for some time before lifting the cap or is it best to lift it soon as ive noticed fastpath is enabled.
many thanks. mark
The banding you've applied will remain in place after a re-sync (e.g. DLM intervention). You must either issue another command to change the banding or restart/power cycle the modem. As for the time, I'd leave it a few hours after DLM has intervened at the minimum, or maybe even an entire day to be very safe, but there should be no harm as long as you don't rapidly do consecutive re-syncs or too many within a 24 hour period full stop.
-
ive just realised being on infinty1 would the command be 52000 95000 100000 or would i put 80000 20000 100000 or something else to reset the command /lift the cap
many thanks
-
ive just realised being on infinty1 would the command be 52000 95000 100000 or would i put 80000 20000 100000 or something else to reset the command /lift the cap
many thanks
80000 20000 100000
This would make it 80/20.
-
48 hours after DLM intervened to apply G.INP, i've just had another resync that's changed my downstream SNR target to 5dB. As a consequence, sync has gone up by around 4Mbit to 73.8bit, excellent!
Hopefully in another 48 hours, it'll drop to 4dB and give me a little bit more speed.
Since the initial G.INP resync, the line itself has been perfectly stable. I can see on my stats now that G.INP is correcting a few errors through retransmissions and the number of Errored Seconds has remained completely flat at 0.
Very pleased that i've been able to finally get both G.INP and xdB on my line. It's providing a welcome increase in bandwidth and lowered latency. Thanks again for everyone's help.
I'll keep this thread updated if the SNR target decreases again or if I start to see any adverse behaviour.
-
Nice one, DLM seems to work much faster on some lines. Back when I was with an old ISP I had G.INP and dropping to 5dB (was all I needed to hit full speed) it took an age to change. You got both within two days! Go figure, maybe one of the more knowledgeable guys can shed some light. Or is it simply luck?
E: What modem are you using now btw? Still the VMG1312-B10A? I wonder if that would make a difference on my line....
-
Had a resync today after capping my line and im back to fast path. Great seeing 11ms ping. think i may leave it till tomorrow to lift the cap. Hopefully g.inp wont be to far behind
thanks for the help guys
-
E: What modem are you using now btw? Still the VMG1312-B10A? I wonder if that would make a difference on my line....
Yep, still on the B10A at the moment. I'd been using the B10D for a couple of months, including during the capping period, but switched it out with the B10A a short while ago, but before G.INP was applied.
Given that the B10A has the better chipset and noise filtering, I wanted to see if it would make a difference on my line. I stayed away from it in the past because I couldn't find a cheap one on eBay and also it doesn't support Baby Jumbo Frames (except via an unknown CLI command).
The B10A definitely seems to perform better on my line - without any DLM changes, I had an increase in sync and a decrease in error rates.
Once DLM has finished performing the xdB changes I might switch back to the B10D - if the line is syncing at max, with G.INP then I don't need the extra boost the B10A gives me and I can also get Baby Jumbo Frames working again.
(If anyone does know the rumoured CLI command to enable Baby Jumbo Frames on the B10A though, i'd much appreciate it!)
-
I see, i quite fancy trying something to replace the HG612, it seems fine, but it is old now and wonder if It could do with being replaced....
-
I see, i quite fancy trying something to replace the HG612, it seems fine, but it is old now and wonder if It could do with being replaced....
I did have a HG612 before. It was reliable and did a good job - and indeed it was the B10D that I replaced it with as I thought it might be slowly failing.
If you can find a cheap VMG1312-B10A on eBay (under 30) I say go for it! The ISP branded ones are easy to reset and upgrade.
Unfortunately from reading around here, there's often no 'best' router/modem for all lines. Different modems are better on different lines. Generally, the better chipset and noise filtering on the B10A works well for most people, but others find that other modems (and cables!) work better for them. Which is another reason why I wouldn't suggest paying a large amount for one - if it doesn't work any better and you end up switching back to your old modem at least then it's not a huge (financial) loss.
-
Yeah that's what I'm thinking as this line is historically noisy....
-
(If anyone does know the rumoured CLI command to enable Baby Jumbo Frames on the B10A though, i'd much appreciate it!)
Do you possess a copy of the ZyXEL VMG1312-B10A CLI Reference Manual? If not, then please send me a PM with your e-mail address and I'll send you a copy of the manual.
-
DLM initiated resync again after 48 hours, dropping the SNRM target by 1dB to 4dB.
Downstream SNRM dropped from 5.4dB to 4.4dB.
Downstream sync increased 3.5Mbit from 73.8Mbit to 77.3Mbit.
Attainable is currently floating somewhere between 79 and 80Mbit which is promising. Hopefully if DLM decides to take me down to a 3dB SNRM target, i'll be syncing at or very close to 80Mbit on the downstream! If the 48 hour resync pattern continues, i'd expect it to kick in again sometime on Monday afternoon.
Is it roughly known what parameters DLM looks at when deciding to lower the SNRM target? At a guess I would think it would be looking at the number of retransmissions - and only lower the target further if the retransmissions aren't excessive?
-
LEFTERS, ES, possibly rtx_uc.
We don't know to be honest, but I'd confidently guess the 1st 2.
-
LEFTERS, ES, possibly rtx_uc.
We don't know to be honest, but I'd confidently guess the 1st 2.
Thanks for that, I appreciate that what parameters DLM uses is a bit of an unknown but i'm glad to at least have some inkling of what it could be using :)
I've had one LEFTR spike to 10, but that was during yesterday's resync. Other than that, they've been 1 at most. Since the 4dB resync, i've only had them on the upstream and long periods without any.
Errored Seconds have remained low too, only really having any during resyncs.
G-Retransmit UnCorrected has remained solidly at 0, except for a spike to ~35k during yesterday's resyncs.
I'm hoping that overall, that looks quite good. It seems they only approach anywhere near 'bad' during resyncs which is quite probably to be expected? Fingers crossed therefore for 3dB on Monday afternoon!
-
It will definitely be Err/Secs and I strongly suspect LEFTRS.
I did ask someone who would know what params DLM looked for on G.INP a few years ago although I didn't get solid confirmation. I didn't get a denial either on LEFTRS if you get my drift, so may of that what you will ;)
-
Removed my line cap yesterday afternoon just over 48 hrs after getting a fastpath connection. Woke up this morning to 80ES/Hour on my line so i guess interleaving wont be to far away. fingers crossed for G.INP :fingers:
-
As you're with BT who use the Speed DLM profile, I think the ES threshold is 2880 a day, or 120/hour.
If you're on MyDSLWebStats is your top left traffic light amber or red?
Huawei cabs seem to favour interleaving over fastpath so I suspect it will apply interleaving at the current rate.
edit: just found you on mdws
-
Speed profile is indeed 2880 ES per day unless you've had some downtime (as it's based on MTBE).
-
My line resycned again today after 2 days at the earlier than usual time of 09:14. Alas, MyDSLWebStats didn't notify me by email so it wasn't til later in the day that I noticed! (Edit: the MyDSLWebStats email eventually came through shortly after I posted at 18:41, but confirming the resync at 09:14. Must have been a delay on the email!)
A 3dB SNRM target has now been applied and i'm now syncing at 3.4-3.5dB on the downstream.
Downstream sync increased 2.6Mbit from 77.3Mbit to 77.9Mbit. Technically it's at 79971Kbit - so close to a full 80Mbit! The attainable is around 81-82Mbit so perhaps if I manually resync during a time of 'good' line conditions i'll be able to clamp at the full 80/20. Still, definitely not complaining about syncing a mere 29Kbit out from the max!
Now that i'm on a 3dB SNRM target;
- G-Retransmit Corrections on the downstream are a little more frequent compared to before, but the per minute scale isn't above what it was previously.
- G-Retransmit Uncorrectable has remained at 0, with the exception of that large spike during Saturday's DLM resync for the 4dB SNRM profile application.
- G-LEFTR is around the same as before, with only the odd upstream one jumping to 1, aside again from a large spike during Saturday's DLM for the 4dB SNRM profile application.
Hopefully now that's the last of my DLM initated resyncs and I have a nice stable, fast, low-latency line!
Comparing things now to before I started trying to get G.INP and xdB applied to my line;
- Downstream Sync has jumped from 58Mbit to 80Mbit
- Upstream Sync has jumped from 17Mbit to 20Mbit
- Latency has decreased by 8ms
I'm very pleased with how things have turned out overall. When I first moved here, I never had any expectations that i'd be able to get a (near) full 80/20 sync given that i'm around 550m from the cabinet and have around 16-17dB of attenuation. I'm in a Virgin area so presumably that has helped reduce crosstalk at least, but my experiences here really goes to show just how much of a difference both G.INP and xdB can make to line speeds. A full 22Mbit gain on the downstream is certainly very pleasing!
I'm going to keep an eye on my line and hope that now DLM considers it stable enough to remain at the current sync rates, my other next step now that I am hopefully with a perfect line is to see if I can get Baby Jumbo Frames working with my Zyxel VMG1312-B10A. I will of course keep this thread updated if anything changes with regards to the line!
Thank you once again to everyone here on this thread who has helped me with this and to Kitz for both the general information on the site and providing a forum for knowledgeable users to gather and help out - i'm extremely grateful! I've tried to be as verbose as possible when documenting my issues and how the line has changed over time, and hopefully this will help other users in a similar situation when it comes to what potentially to expect with changes to their line. I've attached a few screenshots of my SNRM, Sync and G-Retransmit Correctable stats over the last 7 days as G.INP and xdB was applied - hopefully that helps illustrate the overall picture. The stats are of course up on MyDSLWebStats - use the dates of the posts here to refine the data view, they should be retained there til around this time 2019. (I also dropped a small donation (http://www.kitz.co.uk/sites/support.htm) to the site, if you've been following this thread either now or in the future and it's helped you out, please also consider dropping a small donation (http://www.kitz.co.uk/sites/support.htm) to support the future of the site :) )
-
mdws username is markb. currently top and middle left light is amber. bottom left light is red??. rest are green
heres my current stats after lifting the cap on my line
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 7991 Kbps, Downstream rate = 37900 Kbps
Bearer: 0, Upstream rate = 7991 Kbps, Downstream rate = 38029 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.1 6.1
Attn(dB): 23.7 0.0
Pwr(dBm): 12.4 -0.9
VDSL2 framing
Bearer 0
MSGc: 19 26
B: 239 239
M: 1 1
T: 64 42
R: 0 0
S: 0.2008 0.9543
L: 9560 2012
D: 1 1
I: 240 120
N: 240 240
Counters
Bearer 0
OHF: 34764425 1146335
OHFErr: 21304 81
RS: 0 1865191
RSCorr: 0 0
RSUnCorr: 0 0
Bearer 0
HEC: 30764 0
OCD: 1878 0
LCD: 1878 0
Total Cells: 3883081190 0
Data Cells: 233826399 0
Drop Cells: 0
Bit Errors: 0 0
ES: 2179 316
SES: 95 0
UAS: 148 137
AS: 112149
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 3.22 10.05
OR: 61.99 25.44
AgR: 38091.20 8016.68
Bitswap: 82501/82502 50/50
Total time = 1 days 6 hours 26 min 52 sec
FEC: 1037 92
CRC: 21415 100
ES: 2179 316
SES: 95 0
UAS: 148 137
LOS: 1 0
LOF: 8 0
LOM: 0 0
Latest 15 minutes time = 11 min 52 sec
FEC: 0 0
CRC: 824 0
ES: 51 0
SES: 3 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 255 0
ES: 21 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 6 hours 26 min 52 sec
FEC: 0 0
CRC: 8372 31
ES: 634 24
SES: 31 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 0
CRC: 12550 48
ES: 1134 38
SES: 40 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 1 days 7 hours 9 min 9 sec
FEC: 0 0
CRC: 21304 81
ES: 1813 64
SES: 73 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
-
@mbb I'm not sure of the significance of your MDWS stats reporting "G.Inp Inactive" and mine saying nothing at all!? Is that because at some point G.Inp WAS active?
-
@mbb I'm not sure of the significance of your MDWS stats reporting "G.Inp Inactive" and mine saying nothing at all!? Is that because at some point G.Inp WAS active?
Yes sir. that is from my old property when G.INP was activated.
Mark
-
7 days 21 hours 43 min 0 sec scince interleaving was re-applied to my line and no sign of G.INP :'( One thing ive noticed is my upload snr is fluctuating between 6 and 4db. its been on 4 for the past few days
Could it be my line is classed as a 'new' line having only just moved here in December that it needs a good few months before G.INP is applied
im also gettin daily dropouts around the same time everyday for a couple of minutes. the homehub stays in sync (blue light) but i lose all connection for approx 1-2 minutes with the bt splash page breifly appearing. any ideas what this could be?. it hasn't really bothered me that much compared to having an interleaved line. but my net has dropped in the middle of playing online games last couple of nights and could it possibly be the cause of no G.INP?
mark
-
Just a bit of an update here.
Since the DLM resync to 3dB, my line had been stable - no resycns, no drops just lovely fast speeds.
However, on Thursday (22nd) evening at 22:45, my line resynced due to Remote Defect/DLM. Looking at my stats around that time, since around 19:30 my Bitswaps/min on the downstream went to 0 and remained there til the resync. Consequently, this caused G-Retransmit Corrections to go from their usual low level to over 100,000 a minute.
I'm not quite sure why Bitswaps/min dropped to 0 like that, but clearly DLM was doing its job by resyncing the line and correcting the issue. After the resync, I gained a tiny bit extra on the downstream and now sync at the full 79999/19999. Interestingly, the modem's measured attainable sync post-resync increased by 1.5mbit on the downstream, and decreased by 1.5mbit on the upstream.
-
clearly DLM was doing its job by resyncing the line and correcting the issue.
I don't think it's clear at all that it was the DLM instigating the resync. Why couldn't it simply be one or other end of the connection determining that it can no longer maintain the connection due to whatever was going on causing the lack of bitswaps and/or large amounts of retransmission?
-
I don't think it's clear at all that it was the DLM instigating the resync. Why couldn't it simply be one or other end of the connection determining that it can no longer maintain the connection due to whatever was going on causing the lack of bitswaps and/or large amounts of retransmission?
Ah my bad for wording it like that. I meant moreso that the resync was initiated by an automated process. It is indeed unlike to be DLM as it wouldn't react this quickly from what I understand? (Given the daily batch nature of it).
My modem could have initiated it, but I don't know how to tell for sure - unfortunately I have no logs. Can the cab trigger resyncs if it notices abnormal line conditions?
The resync cause according to MDWS was "1 Remote Defect Indicator/DLM".
-
Can the cab trigger resyncs if it notices abnormal line conditions?
Yes. At the level of your connection, the cabinet based DSLAM is just the modem at the other end of the G.993.2 link which is paired with your modem. Either modem may initiate a circuit re-train.