Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Alex Liddiard on December 24, 2018, 11:56:44 AM
-
[Split from original topic - Roseway]
This is my first post here, hey everyone! :)
So earlier this month I got my line reset after it got banded. The line has settled down with an SNR or 3db and a sync speed of 68187kbps. However I'm facing this line speed cap because of rtx high (https://forum.kitz.co.uk/index.php/topic,22086.0.html). Below are my line stats from my modem, I was wondering if DLM would eventually swap it over to rtx low with stats like these?
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 22722 Kbps, Downstream rate = 70212 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 68187 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 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): 3.3 7.0
Attn(dB): 14.8 0.0
Pwr(dBm): 13.9 6.6
VDSL2 framing
Bearer 0
MSGc: -6 20
B: 243 239
M: 1 1
T: 0 64
R: 10 0
S: 0.1139 0.3819
L: 17833 5028
D: 8 1
I: 254 120
N: 254 240
Q: 8 0
V: 0 0
RxQueue: 77 0
TxQueue: 11 0
G.INP Framing: 18 0
G.INP lookback: 11 0
RRC bits: 0 24
Bearer 1
MSGc: 154 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 6.4000 0.0000
L: 40 0
D: 3 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 70390685
OHFErr: 0 54
RS: 2153253568 209734134
RSCorr: 19351 0
RSUnCorr: 0 0
Bearer 1
OHF: 26774100 0
OHFErr: 0 0
RS: 267740389 0
RSCorr: 63 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 199 0
rtx_c: 190 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 68172 0
errFreeBits: 447261294 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 558633149 0
Data Cells: 1157042822 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 0 19
SES: 0 2
UAS: 23 23
AS: 430044
Bearer 0
INP: 59.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 6.13
OR: 0.01 33.91
AgR: 68257.02 20033.74
Bearer 1
INP: 4.50 0.00
INPRein: 4.50 0.00
delay: 3 0
PER: 16.06 0.01
OR: 79.68 0.01
AgR: 79.68 0.01
Bitswap: 4065/4065 3253/3253
Total time = 4 days 23 hours 27 min 47 sec
FEC: 19351 0
CRC: 0 54
ES: 0 19
SES: 0 2
UAS: 23 23
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FailedRetr: 0
Latest 15 minutes time = 12 min 47 sec
FEC: 40 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FailedRetr: 0
Previous 15 minutes time = 15 min 0 sec
FEC: 35 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: N/A
HostInitRetr: N/A
FailedRetr: N/A
Latest 1 day time = 23 hours 27 min 47 sec
FEC: 3708 0
CRC: 0 2
ES: 0 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FailedRetr: 0
Previous 1 day time = 24 hours 0 sec
FEC: 4242 0
CRC: 0 45
ES: 0 11
SES: 0 2
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FailedRetr: 0
Since Link time = 4 days 23 hours 27 min 23 sec
FEC: 19351 0
CRC: 0 54
ES: 0 19
SES: 0 2
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FailedRetr: 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
To make matters worse I've been further capped because the BRAS seems to think I'm at an older 64731kbps sync speed, I haven't had that speed since December 15th when DLM dropped my SNRM from 4db to 3db. I know this sync speed shown on my modem is correct and not actally 64731kbps because somehow the BT Wholesale line checker knows about it (shown as the "max observed downstream"). I'm really hoping that DLM does do something, and that is sorts this whole situation out.
-
Do you use a combined modem/router or 2 separate units?
The IP profile can be fixed by powering off your router for 5 mins and leaving it (modem can be left untouched).
If it's a combined unit just power it off for 5 minutes.
You can quickly check the IP profile here.
https://windows.mouselike.org/be/index.asp?DoAction=BrasChecker
If this doesn't work then it needs an extended downtime, about 15-30 minutes. 5 minutes is usually enough though.
It actually only needs the PPP to be left off for 5 minutes but most home routers don't offer this feature so turning the device off does the same thing.
Apart from the IP profile the line isn't capped in anyway.
If you want to change from Retx High to ReTx Low you will need to physically cap the line.
I'd recommend a cap around 60Mb.
Leave it capped till DLM resyncs the line lowering the Retx protection to Low.
-
Hey John, thanks for the reply.
It's 2 seperate units, an Asus RT-AC88U and a Technicolor DGA4132. Strangely enough I disconnected the PPPoE session through the ASUS web interface for about 45 minutes last light. It had no effect on the IP profile. I'll try again today, maybe I should I try a complete power off of the router?
I'm a bit reluctant to touch the modem yet, are you sure its necessary to cap the speed? I was under the impression that it was controlled depending on the amount of errors.
Edit:
I'm going to try turn my router off overnight and see if that fixes the IP profile, I'll post back tomorrow.
-
It should be based on errors yes.
In all my time looking at stats I've seen 1, that's 1, Broadcom based modem with a 3dB SBRM target change to Retransmission Low without the user setting a cap.
Have a read of this thread
https://forum.kitz.co.uk/index.php/topic,22086.msg379469.html#msg379469
You will be waiting a long time on it changing by itself.
In my experience never.
If you apply the cap I suggested it will change within a few days.
As for the IP profile being stuck I've no idea. Dropping the PPP usually fixes it.
You could try powering off the router.
-
That was spooky, I edited my message exactly when you posted!
Thanks for the clarification John. So the plan is I'll turn off my router tonight and turn it back on in the morning. I'll wait another week and see if anything happens with regards to the rtx profile. If not I'll cap it to 60mbps and hope for the best.
-
"So the plan is I'll turn off my router tonight and turn it back on in the morning." - then you need to cap the line, which will cause another re-sync (send the command via telnet or DSL stats). Then you need to leave it alone and wait for DLM to act.
As advised: adsl configure --maxDataRate 60000 20000 100000
Once ReTx High is removed, it never seems to re-appear which is nice :)
-
Turned on the router this morning, the IP profile hasn't budged still. Seems its gotten stuck really well!
As for the high rtx, comparing the error rates with those for the capped lines in the other thread seems to indicate the DLM should kick in. Unless maybe I need higher SNRM as thats the only thing I appear to be lacking with my current sync. I'm going to keep the current modem sync going for 11 days before trying a cap (currently sitting at 6 days 4 hours).
-
As for the high rtx, comparing the error rates with those for the capped lines in the other thread seems to indicate the DLM should kick in.
What error rates are you comparing?
We have no idea what figures DLM looks at when deciding if the line should go to Retx Low.
It's 100% NOT looking at ES, which is what DLM usually watches. It's also not LEFTERS, which to me would be the most relevant Retransmission counter.
For nearly 6 months I had 0 ES everyday and 1 LEFTERS in that time and DLM didn't budge. My modem was in sync for 142 days over this time also.
I capped my line and 8-9 days later it dropped to ReTx Low.
My FEC count was the only counters that decreased when I capped my line. Obviously the SNRM also increased.
The thread linked to above shows others had similar.
If it makes you feel better then wait another 5 days before trying a cap.
I'm confident another 5 months would still see you on Retx High though.
I would suggest contacting your ISP regarding the IP Profile being stuck.
What you have already tried is the only thing I'm aware of that an end user can try themselves.
-
I'm looking at all the errors I can see (FEC, CRC, ES, SES, UAS, LOS, LOF, LOM, the G.INP stuff like the retransmit counters,LEFTRS). If my error numbers are not clearly lower I worked out the hourly/daily rate and compared. The stats I'm comparing to are whatever I could find in this thread: https://forum.kitz.co.uk/index.php/topic,22086.0.html, Reply #44 by Hitman, Reply #59 by NewtronStar, Reply #84 by pooclah, Reply #94 by JordanBlack68.
Main reason I'm waiting is because I figured it would help others know if the SNRM really matters to make the DLM kick in. :)
-
All knowledge is appreciated :)
Could you post your current stats again?
A few days more worth of the error stats would help.
-
Oh my it actually happened!! I can't believe it, I read your message just now and went to post the stats and...
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 22317 Kbps, Downstream rate = 69347 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 68256 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 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): 3.3 7.0
Attn(dB): 14.8 0.0
Pwr(dBm): 13.9 6.6
VDSL2 framing
Bearer 0
MSGc: -6 20
B: 243 239
M: 1 1
T: 0 64
R: 10 0
S: 0.1138 0.3819
L: 17851 5028
D: 8 1
I: 254 120
N: 254 240
Q: 8 0
V: 0 0
RxQueue: 55 0
TxQueue: 11 0
G.INP Framing: 18 0
G.INP lookback: 11 0
RRC bits: 0 24
Bearer 1
MSGc: 154 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 6.4000 0.0000
L: 40 0
D: 3 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 3304648
OHFErr: 0 0
RS: 706711240 211483294
RSCorr: 1076 0
RSUnCorr: 0 0
Bearer 1
OHF: 1257027 0
OHFErr: 0 0
RS: 12569650 0
RSCorr: 2 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 21 0
rtx_c: 21 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 68234 0
errFreeBits: 624963412 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 2650297647 0
Data Cells: 10007412 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 10 28
SES: 10 2
UAS: 63 53
AS: 20191
Bearer 0
INP: 49.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 6.13
OR: 0.01 33.91
AgR: 68325.92 20033.74
Bearer 1
INP: 4.50 0.00
INPRein: 4.50 0.00
delay: 3 0
PER: 16.06 0.01
OR: 79.68 0.01
AgR: 79.68 0.01
Bitswap: 43/43 175/175
Total time = 6 days 22 hours 55 min 50 sec
FEC: 26296 0
CRC: 0 63
ES: 10 28
SES: 10 2
UAS: 63 53
LOS: 1 0
LOF: 1 0
LOM: 0 0
Retr: 1
HostInitRetr: 0
FailedRetr: 0
Latest 15 minutes time = 10 min 50 sec
FEC: 47 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FailedRetr: 0
Previous 15 minutes time = 15 min 0 sec
FEC: 78 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: N/A
HostInitRetr: N/A
FailedRetr: N/A
Latest 1 day time = 22 hours 55 min 50 sec
FEC: 3281 0
CRC: 0 5
ES: 10 5
SES: 10 0
UAS: 40 30
LOS: 1 0
LOF: 1 0
LOM: 0 0
Retr: 1
HostInitRetr: 0
FailedRetr: 0
Previous 1 day time = 24 hours 0 sec
FEC: 3596 0
CRC: 0 4
ES: 0 4
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FailedRetr: 0
Since Link time = 5 hours 36 min 29 sec
FEC: 1076 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FailedRetr: 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
:D :D :D
I'm going to reboot the router soon when I get the change and see if the IP profile adjusts.
So that proves it, its all about the errors! :)
Edit:
So I haven't done anything with the the router yet as its in use, but I've ran a BT wholesale test and the IP profile hasn't budged yet (still 59.56mbps). I have a feeling I'm going to have to go through a long conversation with my ISP again...
-
Hmm the more I look at my stats the more I feel like my line is being held back (almost equivalently to a cap) because of having strangely low but stable SNR. Severe cross-talk? Maybe I should make another thread about this.
-
Update on what has happened so far:
Yesterday I contacted my ISP, they have raised the IP profile problem with the Openreach complex faults team, I should get a response from them within 48 hours. They also ran some more tests on the line, I have attached the reports for these. They found no issues except that the download speeds are below the promised minimum of 60mbps. Today using the ASUS web interface I closed the PPPoE session and started a new one 2 minutes later. After that I ran a BT wholesale speed test again and the IP profile is now 62880Kbps, up from 59564Kbps. The modem is currently syncing at 68256kbps with 3db SNR and ReTx Low and has been since about 5am on 26th December, which means the ReTx problem is solved but the IP profile problem is not.
Some more info about the IP profile:
The last three IP profiles have been 54140kbps, 59564kbps and 62880Kbps. 54140kbps was what I got right after I had a DLM reset on the 7th December, it stayed like that up to the 16th, even after 3 DLM resyncs during that time. 59564kbps is what I got on the 16th after I carefully restarted my modem and router. It stayed like that after a modem/router restart on the 18th and one on the 19th, after restarting the PPPoE session, after leaving the router off overnight, and even after the DLM resync on the 26th December. Today the IP profile changed to 62880Kbps after restarting the PPPoE session.
So from this limited info I have it appears I am experiencing a combination of two bugs:
1. When a DLM resync occurs the PPPoE session is not restarting and applying a new IP profile. This can be seen from the fact the IP profile has never changed without restarting the PPPoE session manually.
2. The DLM system/BRAS is using outdated sync and line profile information. More specifically, it appears to be using information from whatever the line configutation was right before the latest DLM intervention. This is harder to see, whenever the IP profile has updated it has never been correct for the current sync speed and ReTx setting, it has been for a previous one:
.The change to 59564Kbps corresponds to a sync speed of 64743Kbps on ReTx High, at the time my line was: 68164Kbps, 3db, ReTx High (after DLM intervention) and before that was 64731Kbps, 4db, ReTx High. Also see that the fresh test results from my ISP show this old line profile.
.The change to 62880Kbps corresponds to a sync speed of 68347Kbps on ReTx High, at the time my line was: 68256Kbps, 3db, ReTx Low (after DLM intervention) and before that was 68187Kbps, 3db, ReTx High. I suspect that if another GEA test was performed it will now show this old line profile.
Of course this is just speculation from patterns that seem to be emerging, but certainly the automated systems aren't working properly and I hope Openreach complex faults team can see a problem and fix it.
-
Your the 1st IP profile issue I've seen in a couple years that killing the PPP for a while hasn't fixed.
DLM resets usually aren't an issue.
Years ago IP profile issues were commonplace but the system works much better now.
The IP profile for Retx High can be anywhere between 91-92.*% of the sync speed.
No IP profile can be used to exactly calculate the sync of a line running Retx High, and vice versa.
With Retx Low the IP Profile is always an exact percentage of the sync speed (96.69%).
This means you can work out the IP profile from sync and vice versa with Retx Low.
The above only applies to Broadcom chipsets.
-
I don't suppose a different router has been tried to see if that sorts out the IP profile updating?
I think I've seen one or two cases of someone's IP profile never updating when they were using Asus routers.
-
The DGA4132 being used as a modem can quickly be reconfigured to establish the PPPoE session.
If using another router to do this instead of reconfiguring the DGA4132 make sure to power that off for a bit if not already tried.
-
Thanks for the info, so that means the IP profile with the current sync should be 68164 * 0.9669 = 65996Kbps (within margin of error) which it currently isn't. The variation in ReTx high IP profiles also explains why the 3rd and 4th sync speeds highlighted in bold don't quite match up as closely as the first two (in both cases I assumed 92% IP profile for ReTx high). I wish I had more evidence to back up the 2nd bug, but unfortunately it seems like the 1st bug with PPPoE covered up a lot of it during those 3 DLM interventions from December 7th to 16th. That was the time when DLM progressively shifted my line from a default profile, to 6db with ReTx disabled, then to 5db with ReTx high, then to 4db with ReTx high.
As for the router, no I haven't tried any other another router. I think I have a Plusnet Hub One in the loft I could try instead of the Asus router. It's an all in one, can those work just in router mode? Ah yes I could reconfigure the DGA4132, could that be done without a resync?
As a side note, I've ordered a Raspberry Pi W and plan to set DSL Stats on it.
Edit: I see the DGA4132 has ifconfig, would something wlike this work on it? https://www.netbsd.org/docs/network/pppoe/
Edit 2: On second thought, I think I'll leave the DGA4132 alone as last time I tried touching the network config I almost locked myself out of the modem. Would it be good enough to connect a computer directly to establish PPPoE?
Edit 3: I've attachd a log of the recent PPPoE connections that my ISP sent me, might be useful.
-
Quick update, I managed to establish a PPPoE directly on a Windows 7 PC and ran another BT Wholesale speed test. Sadly, the IP profile hasn't changed. :(
-
So I have some interesting observations to report.
I have done some fiddling around with the modem and router settings to see if anything will make a difference. The only major tweaks were I disabled NAT acceleration, and moved the job of tagging traffic with VLAN 101 from the modem to the router, I doubt this had any effect. In the process I had to resync the modem, after everything was up and running again I checked the modem stats and they are now:
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 23354 Kbps, Downstream rate = 69878 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 68348 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 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): 3.3 7.7
Attn(dB): 14.9 0.0
Pwr(dBm): 13.9 6.7
VDSL2 framing
Bearer 0
MSGc: -6 20
B: 243 239
M: 1 1
T: 0 64
R: 10 0
S: 0.1137 0.3819
L: 17875 5028
D: 8 1
I: 254 120
N: 254 240
Q: 8 0
V: 0 0
RxQueue: 55 0
TxQueue: 11 0
G.INP Framing: 18 0
G.INP lookback: 11 0
RRC bits: 0 24
Bearer 1
MSGc: 154 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 6.4000 0.0000
L: 40 0
D: 3 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 195601
OHFErr: 0 0
RS: 41849808 12517645
RSCorr: 34 0
RSUnCorr: 0 0
Bearer 1
OHF: 74396 0
OHFErr: 0 0
RS: 743346 0
RSCorr: 0 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 0 0
rtx_c: 0 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 68343 0
errFreeBits: 1245648 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 157068087 0
Data Cells: 7325524 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 0 0
SES: 0 0
UAS: 23 23
AS: 1195
Bearer 0
INP: 49.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 6.13
OR: 0.01 33.91
AgR: 68417.78 20033.74
Bearer 1
INP: 4.50 0.00
INPRein: 4.50 0.00
delay: 3 0
PER: 16.06 0.01
OR: 79.68 0.01
AgR: 79.68 0.01
Bitswap: 53/53 1/1
Total time = 20 min 18 sec
FEC: 34 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 23 23
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FailedRetr: 0
Latest 15 minutes time = 5 min 18 sec
FEC: 8 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FailedRetr: 0
Previous 15 minutes time = 15 min 0 sec
FEC: 26 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 23 23
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: N/A
HostInitRetr: N/A
FailedRetr: N/A
Latest 1 day time = 20 min 18 sec
FEC: 34 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 23 23
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FailedRetr: 0
Previous 1 day time = 0 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
Retr: 0
HostInitRetr: 0
FailedRetr: 0
Since Link time = 19 min 55 sec
FEC: 34 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FailedRetr: 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
The sync speed has changed from 68256Kbps to 68348Kbps, a small increase of 98kbps. I then ran another BT Wholesale speed test, to my surprise the IP profile has changed from 62880kbps to 62970kbps, a small iincrease of 90kbps.
So it appears the IP profile is updating, but not to the expected speed. According to the router stats I appear to be on a ReTx low profile, which should mean the IP profile is 68348 * 0.9669 = 66085Kbps. However it seems to have calculated the new profile as if I am on a ReTx high profile (62970/68348 = 0.9213, about 92.1%).
The only logical explanations I have are:
1. I really am actually on a ReTx high profile.
2. There is a bug going on which is causing an incorrect calculation.
3. The modem is reporting a sync speed higher than the DSLAM, in which case the DSLAM is reporting a sync speed of 62970 / 0.9669 = 65125Kbps. However the BT line checker reports a max observed speed of 68.16Mbps, which is fairly consistent with the sync speed reported by the modem, which makes me doubtful of this possibility.
I feel like I'm stumbling around in the dark with this problem at the moment, Does anyone have any other ideas as to what could be going on?
P.S. Plusnet/Openreach have not come back with any response yet, probably won't get anything until Monday now.
-
A GEA test will confirm the line profile, Retx Low or High.
The problem there is that the line profile shown on the GEA test is 13 days old so would need to wait.
No idea if out of date line profile only affects Plusnet or all ISP's though.
I switched to Plusnet in October. By the start of November my line was Retx Low and the IP profile updated instantly to reflect this.
-
Update, got a reply from Plusnet. They ran another GEA test, below are the results.
GEA Test Detail
Test Outcome Pass
Test Outcome Code GTC_FTTC_SERVICE_0000
Description GEA service test completed and no fault found.
Main Fault Location OK
Sync Status In Sync
Downstream Speed 68.7 Mbps
Upstream Speed 20.0 Mbps
Appointment Required N
Fault Report Advised N
NTE Power Status PowerOn
Voice Line Test Result Pass
Bridge Tap Not Detected
Radio Frequency Ingress Not Detected
Repetitive Electrical Impulse Noise Not Detected
Cross Talk Not Detected
Estimated Line Length In Metres 401.1
Upstream Rate Assessment Very Good
Downstream Rate Assessment Reasonable
Interference Pattern Not Detected
Service Impact No Impact Observed
Home Wiring Problem Not Detected
Downstream Policing Discard Rate 0.0
Customer Traffic Level Upstream and Downstream Traffic Detected
Technology VDSL
Profile Name 0.128M-80M Downstream 3dB, Retransmission High - 0.128M-20M Upstream, Error Protection Off
Time Stamp 2018-12-18T15:45:00
Parameters MIN MAX AVG
Down Stream Line Rate 68.1 Mbps 68.3 Mbps 68.2 Mbps
Up Stream Line Rate 20.0 Mbps 20.0 Mbps 20.0 Mbps
Up Time 0.0 Sec 900.0 Sec 894.9 Sec
Retrains 0.0 1.0 0.0
Current and Last 15 Minute Bin Performance
Parameters Last Traffic Count(Upto 15 mins) Current Traffic Count(Upto 15 mins)
Start Time Stamp 2018-12-31T15:12:44Z 2018-12-31T15:27:44Z
Ingress Code Violation 2 0
Egress Code Violation 0 0
Errored Seconds 0 0
Severely Errored Seconds 0 0
Unavailable Seconds 0 0
BT Estimates WP Profile CLT NIC
80000 - 60000 Generic Speed 62600 No Time Out Pass Pass
Their summary was this:
2TP on radius (probably due to the fixed ip, but possibly provisioned on the old network) may have something to do with the throughput issue.
If the eu doesn't use it for anything specific (eg CCTV) might be an idea to remove it to see if it solves anything.
If provisioned on the old network it would not make a difference however, it will remain L2TP.
Also possible issue with huawei and hub one
Will call to discuss
So it seemss I am still on a ReTx high profile. I only have static IP set up for a ping quality monitor so I will ask them to switch me over to dynamic IP and see if it improves anything. I have noticed something fishy in the last two GEA tests I have had, look at the two dates shown in the tests I have sent:
Time Stamp Start Time Stamp
Test 1 2018-12-18T15:45:00 2018-12-31T15:12:44
Test 2 2018-12-13T13:45:00 2018-12-26T13:12:46
The times in the 2nd column are the times when the GEA test was actually done.
Why are the times in the 1st column 12 days, 23 hours, 27 mins behind those in the 2nd column? Is this a bug or is it always like this?
Edit: So I've seen some more GEA tests online and seems the time difference is normal, anyone know why it is like this?
-
So it seemss I am still on a ReTx high profile. I only have static IP set up for a ping quality monitor so I will ask them to switch me over to dynamic IP and see if it improves anything. I have noticed something fishy in the last two GEA tests I have had, look at the two dates shown in the tests I have sent:
As I said in my previous post, as I thought this might arise, the line profile shown on ALL of Plusnets GEA tests (maybe everyone's?) shows a profile from 13 days ago.
13 days ago you were on Retx High.
Ask them to run a GEA Test 14 days after you changed to Retx Low and it will reflect this.
edit: removed gibberish
-
Ah I see thanks for clearing that up for me. In your last message I thought you meant I should wait for a new test result from Plusnet/Openreach, I didn't realise you meant that the GEA test was always outdated. :P
I'll ask for another GEA test around the 8th Jan as it was the 26th December when DLM did something to the line. Also I have removed the static IP now and verified I have got a new IP and gateway after rebooting the router. The IP profile is still the same, but it has improved the actual download, its now much closer to the IP profile. :)
-
So I got a new GEA test result today, here are the details:
GEA Test Detail
Test Outcome Pass
Test Outcome Code GTC_FTTC_SERVICE_0000
Description GEA service test completed and no fault found.
Main Fault Location OK
Sync Status In Sync
Downstream Speed 68.4 Mbps
Upstream Speed 20.0 Mbps
Appointment Required N
Fault Report Advised N
NTE Power Status PowerOn
Voice Line Test Result Pass
Bridge Tap Not Detected
Repetitive Electrical Impulse Noise Not Detected
Estimated Line Length In Metres 401.1
Upstream Rate Assessment Very Good
Downstream Rate Assessment Reasonable
Interference Pattern Not Detected
Service Impact No Impact Observed
Home Wiring Problem Not Detected
Downstream Policing Discard Rate 0.0
Customer Traffic Level Upstream and Downstream Traffic Detected
Technology VDSL
Profile Name 0.128M-80M Downstream 3dB, Retransmission Low - 0.128M-20M Upstream, Error Protection Off
Time Stamp 2018-12-29T08:45:00
Parameters MIN MAX AVG
Down Stream Line Rate 68.2 Mbps 68.7 Mbps 68.5 Mbps
Up Stream Line Rate 20.0 Mbps 20.0 Mbps 20.0 Mbps
Up Time 0.0 Sec 900.0 Sec 894.2 Sec
Retrains 0.0 1.0 0.0
Current and Last 15 Minute Bin Performance
Parameters Last Traffic Count(Upto 15 mins) Current Traffic Count(Upto 15 mins)
Start Time Stamp 2019-01-11T08:12:42Z 2019-01-11T08:27:42Z
Ingress Code Violation 2 0
Egress Code Violation 0 0
Errored Seconds 0 0
Severely Errored Seconds 0 0
Unavailable Seconds 0 0
So this confirms it, the line is using ReTx low now. However still the IP profile is being calculated as if I'm on ReTx high.
-
I notice from your 2 GEA tests right under the "profile name" field is a "timestamp" field.
The date on the timestamp field on both tests is 13 days prior to the date of the test.
I'd never noticed this until now.
It certainly confirms what I said about the profile listed being 13 days out of date.
Since you posted this we've had 2 members with the same problem.
Their line is Retx Low but the IP profile is that of an Retx High sync.
https://forum.kitz.co.uk/index.php/topic,22971.0.html
-
Strange indeed.
For possible reference, I updated my router FW last Saturday which interrupted 277 days of line synch, have remained on G.Inp Re-Tx low profile (as verified by line stat's) with unchanged IP profile, ie., 38.67/40.00*100 = 96.67%.
Obviously I am only on 40/10 service where the 3 other parties are on 80/20 service, probably not relevant ?
-
I'm on 80/20 and retx low with the correct IP profile of 96.69%.
I don't think the package will be relevant
-
I don't think the package will be relevant
Most likely the case but have you had a DSL session re-connect/re-synch on your line since the observations by the 3 other parties came to light ?
-
I resynced my line a couple days ago when upgrading my zyxel firmware.
This isn't new though... 1 of the 3 with this issue has had the problem since the very first time they went retx low (many months ago), 1 since a fairly recent DLM reset and the other didn't specify a duration the problem has existed.
jelv also has a full 80Mb sync with the correct IP profile so it isn't only those who reach the full 80Mb or those on that package.
If this becomes more widespread I'm sure we'll see it across a range of speed packages.
3 examples isn't enough to draw any conclusions.
-
I notice from your 2 GEA tests right under the "profile name" field is a "timestamp" field.
The date on the timestamp field on both tests is 13 days prior to the date of the test.
I'd never noticed this until now.
I certainly have and have said so many times.
I first noticed the time lag shortly after G.INP mk1 was introduced. There should be several posts on the Plusnet forum back in ~2015 with me stating that the GEA was using historic data. As well as informing a couple of the forum staff Matty? several times that they were issuing out of date DLM profile data, I also brought it to the attention of Bob Pullen and another PN staff member who was writing a test interface for EU line data.
Bob is certainly aware that the data is not current and I have specifically pointed out the Time stamp under the profile name, but according to them, they don't appear to be able to get anything more up to date.
I must admit I always thought it was a couple of weeks out of date, but you are quite correct when you say it is exactly 13 days.
This is the results of a GEA test I specifically asked PN to run when pointing out the delay to them.
Test Outcome Pass
Test Outcome Code GTC_FTTC_SERVICE_0001
Description GEA service test completed and no fault found but unable to check for customer equipment connected to modem.
Main Fault Location OK
Sync Status In Sync
Downstream Speed 80.0 Mbps
Upstream Speed 20.0 Mbps
Appointment Required N
Fault Report Advised N
NTE Power Status PowerOn
Voice Line Test Result Pass
Bridge Tap Not Detected
Radio Frequency Ingress Not Detected
Repetitive Electrical Impulse Noise Not Detected
Cross Talk Not Detected
Profile Name 40M-80M Downstream, Error Protection Off - 10M-20M Upstream, Error Protection Off
Time Stamp 2015-05-31T12:00:00
Parameters MIN MAX AVG
Down Stream Line Rate 79.9 Mbps 79.9 Mbps 79.9 Mbps
Up Stream Line Rate 20.0 Mbps 20.0 Mbps 20.0 Mbps
Up Time 850.0 Sec 900.0 Sec 899.9 Sec
Retrains 0.0 0.0 0.0
Current and Last 15 Minute Bin Performance
Parameters Last Traffic Count(Upto 15 mins) Current Traffic Count(Upto 15 mins)
Start Time Stamp 2015-06-13T11:00:10.244+01:00 2015-06-13T11:15:10.244+01:00
Ingress Code Violation 0 0
Egress Code Violation 0 0
Errored Seconds 0 0
Severely Errored Seconds 0 0
Unavailable Seconds 0 0
I have lots more including the new GUI test data in 2016 all of which show the DLM data delay.
-
No idea if out of date line profile only affects Plusnet or all ISP's though.
I have in the past wondered if it is just Plusnet and even asked the guy who was writing the GUI if there was anywhere else they could pull data from Openreach that would give a more up to date record, but told no because he was trying to collate everything in one place of all the data that could be obtained about a particular line. I was shown the full data and it is pretty impressive just what information is available to the ISP.
The problem is Openreach seem quite happy to furnish the information, but it is entirely down to the ISP to write the GUI for the API data. The person who I spoke to about this no longer works at PN and the guy who was writing the GUI was doing it more as a personal project, rather than something Plusnet officially decided to fully implement within their systems.
Plusnet seem about the only ISP that is willing to give out GEA data to their EU's and I've mentioned more than once in the past that there is only really one other ISP I could think of who would perhaps go so far as to write their own GUI - that being AAISP.
However, that should not stop any ISP being able to run a standard GEA test. I wonder if there is anyone using FTTC with AAISP who is able to ask them to run one on their behalf.
-
I had one of my lines tested in December, result attached.
-
Thank you vm Vic :flower:
Test performed 10-12-2018
DLM info
2018-11-27T11:00:00 0128M-80M Downstream 3dB Retransmission High
I think that conclusively confirms the 13 day delay for DLM info is not specific just to Plusnet.
-
Indeed that's very helpful.
I've wondered if it was a Plusnet oddity for some time.