Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: aneesh99 on November 30, 2016, 06:21:14 PM
-
I've been having a discussion with PN about our line.
The background to this is that our exchange was a hot VP. For whatever reason, no interleaving or G.INP would apply to our line so it tanked our speed instead. Engineer came on Sept 6th to confirm our line was fine but that the exchange was the cause. Line was reset on the 7th but the speed dropped again.
The profile was reset on the 25th after our line was migrated to a cooler vlan but before works were completed to expand the exchange (which was due on the 30th). There were still quite a few errors and speed fluctuation but nowhere near as bad - probably because interleaving.
It doesn't appear they ever reset our line after the work was completed because my profile has been the same since the 25th.
====================================================================================
VDSL Training Status: Showtime
Mode: VDSL2 Annex B
VDSL Profile: Profile 17a
G.Vector: Disable
Traffic Type: PTM Mode
Link Uptime: 0 day: 17 hours: 25 minutes
====================================================================================
VDSL Port Details Upstream Downstream
Line Rate: 20.063 Mbps 66.996 Mbps
Actual Net Data Rate: 19.999 Mbps 66.997 Mbps
Trellis Coding: ON ON
SNR Margin: 15.0 dB 7.7 dB
Actual Delay: 0 ms 0 ms
Transmit Power: 6.9 dBm 13.0 dBm
Receive Power: -8.2 dBm -3.5 dBm
Actual INP: 0.0 symbols 51.0 symbols
Total Attenuation: 0.0 dB 17.2 dB
Attainable Net Data Rate: 23.828 Mbps 74.509 Mbps
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 5.1 21.5 32.4 N/A N/A 12.0 27.6 42.1
Signal Attenuation(dB): 5.1 20.8 31.8 N/A N/A 13.3 27.4 42.1
SNR Margin(dB): 15.2 15.0 15.0 N/A N/A 7.6 7.6 7.7
TX Power(dBm): -3.2 -21.6 6.6 N/A N/A 9.6 7.9 6.9
====================================================================================
VDSL Counters
Downstream Upstream
Since Link time = 25 min 21 sec
FEC: 3620290 516
CRC: 0 93
ES: 0 81
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 3 min 2 sec
FEC: 2715 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: 10999 21
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 = 18 hours 18 min 2 sec
FEC: 3796872 518
CRC: 572 96
ES: 11 84
SES: 11 0
UAS: 192 181
LOS: 1 0
LOF: 8 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 3808220 701
CRC: 0 134
ES: 0 113
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Total time = 1 days 18 hours 18 min 2 sec
FEC: 7982827 21878
CRC: 572 354
ES: 11 296
SES: 11 1
UAS: 225 214
LOS: 1 0
LOF: 8 0
LOM: 0 0
====================================================================================
The stats have looked like this since the 25th, with the only difference being that the CRC errors and errors seconds cleared up completely after the work on the 30th. The interleaving never backed off after the work. I've attached the GEA test in a PDF below.
PN has said that GEA is reporting a sync speed of 64.1 and therefore, my profile isn't banded. But my VGM8324 is showing 66.9? They're adamant that this shows the profile band isn't impacting speed.
Secondly I'm curious as to why my line wasn't reset after the work was done?
I'm not really too knowledgeable about the intricacies of FTTC, I'm just trying to get PN to reset our line to see what it can do! :)
Edit: PN thread is here https://community.plus.net/t5/Fibre-Broadband/Could-my-speed-be-better/td-p/1388990 (https://community.plus.net/t5/Fibre-Broadband/Could-my-speed-be-better/td-p/1388990)
-
The background about the hot VLAN doesn't really fit with the current issue, in that the usage of the VLAN would have had absolutely no impact on the VDSL2 connection between your modem and the FTTC cabinet. It may have affected your download speeds, but would not have caused any of the error counts in the VDSL2 stats, nor would VLAN congestion issues have caused the DLM to do anything - the DLM would not be aware of it.
This is the second case I've seen where the test strangely reports a lower speed than the modem. Out of interest, can you show us your BT IP profile from the further diagnostics of the BT Speedtester (http://speedtest.btwholesale.com/) (ignore all the text in red about rebooting things)? I'd like to see if the BT IP profile is 96.7% of 64.1 or 67.
-
Attached below. Looks like 97%. (64.1x0.97=62.1)
That was the information provided to me by PN.
All I know if that I saw the CRC errors and errors seconds skyrocket, and they settled after the work that was done on the 30th. :-\
-
My opinion would be that you're definitely banded.
The SNRM of 7.7dB shows a little room for more sync, I'm sure someone else could give you a rough estimate.
No idea where Plusnet are coming from with regards to your current sync. It's definitely 66.9mb and not 64mb
-
There's something really weird going on with my line, for the past three days the DSL sync drops at 0030-0050am when no one is using it and reconnects immediately. There's nothing in the log apart from loss of sync and re-connection. I've looked at the historical stats, I did a firmware upgrade a few days ago. By these trends, it looks like there are a burst of errors overnight?
====================================================================================
VDSL Training Status: Showtime
Mode: VDSL2 Annex B
VDSL Profile: Profile 17a
G.Vector: Disable
Traffic Type: PTM Mode
Link Uptime: 0 day: 11 hours: 38 minutes
====================================================================================
VDSL Port Details Upstream Downstream
Line Rate: 20.063 Mbps 66.996 Mbps
Actual Net Data Rate: 19.999 Mbps 66.997 Mbps
Trellis Coding: ON ON
SNR Margin: 15.2 dB 7.6 dB
Actual Delay: 0 ms 0 ms
Transmit Power: 7.0 dBm 13.0 dBm
Receive Power: -8.2 dBm -3.4 dBm
Actual INP: 0.0 symbols 51.0 symbols
Total Attenuation: 0.0 dB 17.1 dB
Attainable Net Data Rate: 23.482 Mbps 74.490 Mbps
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 5.1 21.4 32.3 N/A N/A 12.0 27.5 41.9
Signal Attenuation(dB): 5.1 20.5 31.7 N/A N/A 13.2 27.3 41.9
SNR Margin(dB): 15.2 15.1 15.2 N/A N/A 7.8 7.8 7.4
TX Power(dBm): -3.2 -21.8 6.6 N/A N/A 9.6 7.9 6.9
====================================================================================
VDSL Counters
Downstream Upstream
Since Link time = 38 min 59 sec
FEC: 1077157 172
CRC: 0 36
ES: 0 36
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 11 min 45 sec
FEC: 39980 2
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: 66207 7
CRC: 0 1
ES: 0 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 12 hours 11 min 45 sec
FEC: 1096361 174
CRC: 538 37
ES: 10 37
SES: 10 0
UAS: 213 203
LOS: 1 0
LOF: 7 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 3951737 514
CRC: 0 100
ES: 0 79
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Total time = 1 days 12 hours 11 min 45 sec
FEC: 14647895 22709
CRC: 1110 516
ES: 21 435
SES: 21 1
UAS: 438 417
LOS: 2 0
LOF: 15 0
LOM: 0 0
====================================================================================
-
Has G.INP been activated on your line yet aneesh99??
I had DLM reset 12 days ago and I'm still waiting for G.INP to be re-enabled, instead it's applying a ton of interleave :(
-
Nope, my profile is stuck as is after it was. Line was never reset after the issue was fixed, DLM never did anything to my profile. The only thing that changed was that CRC errors and the error seconds have gone :'(
I'm hoping form some advice from y'all experts! I'm having a back and forth with PN about my profile being stuck and there are a few things going on.
The low estimate for my line is 63.8 and no one can seem to agree what constitutes low speed. The profile is banded at 67mbps, GEA and my modem are reporting the line rate at 67. The GEA 'download speed' (which PN is saying is the line rate???) is 64.1 and the BTw IP profile is 62.1. All of my real world speedtests are around 60-62mbps.
Kindly ejs has been posting very regularly but me, ejs and a few others that are disputing what PN is saying doesn't seem to be going anywhere. I'm hoping that a few more of you guys and gals could take a look at the thread and see that you think? I was thinking of cutting my loses after arguing on the forum for 3 weeks and reporting a fault but I'd rather be armed with all of the information I can gather before doing that.
Thanks!
https://community.plus.net/t5/Fibre-Broadband/Could-my-speed-be-better/td-p/1388990 (https://community.plus.net/t5/Fibre-Broadband/Could-my-speed-be-better/td-p/1388990)
-
I have looked and was rapidly reduced to a state of :wall:
Quite honestly, you need to raise this matter with entities "higher up the food chain" and "Anoush" needs to be sent on a training course before being allowed to respond to any further customer queries/complaints.
-
Suggestion . . .
Take a look at the Member's List (http://forum.kitz.co.uk/index.php?action=mlist) for this forum. Then sort the list by the Position (http://forum.kitz.co.uk/index.php?action=mlist;sort=id_group;start=0) column. Scroll down until you reach the those members classified as ISP Rep. (When I last checked, there were 28 names.)
Go through each of those names and identify the relevant members from Plusnet. Send a clearly worded PM to the right person and, in due course, this problem should be brought to a satisfactory conclusion.
-
Thanks for that! :D
Another questions (and bear in mind I am a total layman) - my understanding was the actual line rate was my sync to the DSLAM, and my max attainable rate is based on SNRM and bit loading. Because apparently according to Anoush:
'My faults colleague has explained that the line rate is basically a speed profile. It's not the sync.'
Either I've been wrong for years when I've been asking for resync's with PN on ADSL or Anoush has no idea what he's on about?
-
Because apparently according to Anoush:
'My faults colleague has explained that the line rate is basically a speed profile. It's not the sync.'
<snip> or Anoush has no idea what he's on about?
I really cannot comment, other than to recommend that you note the wise words from ejs in your Plusnet forum thread. :-X
-
I've finally found the other thread in which someone had the GEA FTTC test report a different speed (and hence had a lower than expected BT IP Profile, because it was 96.7% of what the test said the speed was). Probably also banded.
https://community.plus.net/t5/Fibre-Broadband/Line-Rate-and-Profile-Difference/m-p/1383224
It does not give any insight as to why the test reports a different speed to the modem.
-
Suggestion . . .
Take a look at the Member's List (http://forum.kitz.co.uk/index.php?action=mlist) for this forum. Then sort the list by the Position (http://forum.kitz.co.uk/index.php?action=mlist;sort=id_group;start=0) column. Scroll down until you reach the those members classified as ISP Rep. (When I last checked, there were 28 names.)
Go through each of those names and identify the relevant members from Plusnet. Send a clearly worded PM to the right person and, in due course, this problem should be brought to a satisfactory conclusion.
Just thought, that although (most) some of them still work at Plusnet, not all are still in CS.
I think James and Linn have moved on elsewhere so I will delete their tags.
Normally Bob/One of the Chris's are likely your best bet. However that said I was speaking to Bob about something else this morning.... and whilst technically hes not CS either, he's now off work until after Christmas hols.
-
It does not give any insight as to why the test reports a different speed to the modem.
There are instances whereby if the line does a really quick resync then the RAP (http://www.kitz.co.uk/adsl/DLM_system.htm#DLM_Management_Device) part of RAMBO does not always detect the resync. The RAP is separate to DLM and is responsible for informing the bRAS of changes in sync speed so that IPprofiles are adjusted accordingly. It's also the figures that are often used in any reports that may be sent to the ISP or even Openreach engineers.
I've seen this type of weirdness happen first hand on my line on a few occasions. Plusnet have different info that what Im syncing at.
Its even happened once when I had a HR fault whereby if the phone rang it would knock out the line. On those occasions the resyncs were picked up by the DLM, yet they weren't visible to the ISP nor the OR engineer who was here to find the fault.
I think there is some recommendation about time between resyncs for RAP (bRAS) detection - its something like 40 seconds... cant recall off the top of my head.
-
Here we go - from the PN forum
As for the line not appearing to be reset following the resolution of the fault, I can see that your fault was fixed remotely by our suppliers capacity management team as the issue was overutilisation across the VLANs. An engineer wasn't arranged.
The line has had a remote reset, which as Ive been saying for months, remote/automated resets do not appear to remove banding.
No one else (ISPs) seem to be aware of this, yet its something that I first spotted several months ago, and why I started ruminating about the two different types of DLM reset. This goes back to the days of WilliamG's 'line fault'. I started to collect some stats and had a whole thread on the topic, but it was before I got ill and wasnt around for a while... thus forgot and not had chance to do anything further. :/
-
I'm just going around in circles with PN who are adamant that because either way, my sync is above the low estimate, I'll be charged for an engineer. Apparently the fact that the IP profile, sync and modem all being out of whack isn't a fault.
Smh :no: :wall:
-
yeah I get the impression bob is more senior than CS given he is able to directly touch the network config and provide good info in the forums which CS bods would not know about, I guess he is just really enthusiastic and frustrated at the same time so goes beyond his job role to try and help customers.
-
I'm just getting frustrated and feeling a bit defeated tbh, I don't think I'm going to get anywhere with the forum guys.
Linn got back to me and said she'd forward it to someone. Anyone have any other ideas on who to speak to? I was just going to email Andy Baker tbh, I really can't be arsed dealing with this anymore.
-
In all honesty if it were me, then I'd wait for Bob to get back after the xmas hols.
It's like banging head against a brick wall over there. I sent a screen cap of another instance where a GEA test was showing incorrect data as proof of the fact it does happen.
The reason I suggested an hours power down, is because that's what cleared the other one to show correct data.
Although its annoying, its not service affecting and at least you have got a connection. Even if they did decide to act, its unlikely that the engineer would be with you before xmas. I therefore prescribe a glass of liquid refreshment and enjoy the next few days with your friends & family. Seasons greeting and all that.
Then afterwards, hopefully Bob will be able to pick up on the message you sent. :fingers:
-
Thanks to all of you guys and gals for the assistance so far, I really appreciate it ;D I'll try and get it done tonight, and see if that does anything.
Thanks kitz, I'll defo enjoy my holiday! Wishing a happy holiday season to you all :drunk:
-
I have a different suggestion:
Use the adslctl/adslcmd command to reduce the sync speed, say to cap it at 60Mb downstream. Then get another GEA test run and see if it reports a different speed for the sync speed, presumably it will report a value lower than 60Mb.
The idea is to see if the speed reported by the GEA test changes. Then later, use the adslctl command again to remove the speed cap.
I've seen three different cases where the GEA test reported speed is lower, and in each case the IP Profile was about the same lower percentage, and I think in at least NewtronStar's case (http://forum.kitz.co.uk/index.php/topic,17336.0.html), the IP profile did change when their speed changed, so I'm no longer convinced it's simply a case of a wrong value stuck in the system somewhere.
-
I've finally found the other thread in which someone had the GEA FTTC test report a different speed (and hence had a lower than expected BT IP Profile, because it was 96.7% of what the test said the speed was). Probably also banded.
https://community.plus.net/t5/Fibre-Broadband/Line-Rate-and-Profile-Difference/m-p/1383224
It does not give any insight as to why the test reports a different speed to the modem.
I missed seeing that post last night. For the record, that isnt the one I sent details of. It does show that something odd is going on for a few lines.
It would have been interesting if there was ever a follow up to that ejs found and if it ever got resolved :/
Use the adslctl/adslcmd command to reduce the sync speed, say to cap it at 60Mb downstream.
Its worth a try, taking it lower may poke something into action.
-
Was just checking the BTw Performance test for IP profile and can run the first test but not the second test which gives IP profile since the move to Vodafone it reads ->
"The Performance Tester is currently unable to run a speed test for your broadband connection. Please try again shortly, however if this problem persists, raise the issue with your service provider"
So BTw speed test 30700kbps / modem sync rate 32160kbps X 100 = 95.4%
-
Use the adslctl/adslcmd command to reduce the sync speed, say to cap it at 60Mb downstream. Then get another GEA test run and see if it reports a different speed for the sync speed, presumably it will report a value lower than 60Mb.
The idea is to see if the speed reported by the GEA test changes. Then later, use the adslctl command again to remove the speed cap
What would the command be? Is there a way to directly change my sync or do you mean by changing my SNRM?
-
adslcmd or xdslcmd configure --maxdatarate 00000 00000 00000
-
I gotta be honest I'm not at all familiar with configuring the data rate through telnet. What are the zeroes in your command about? One would be downstream, one set is upstream and the other one is..? Sorry for the noob questions!
-
See Speed capping and ES rates on a moderately noisy line (http://forum.kitz.co.uk/index.php/topic,16427.0.html)
The command should be something like:
adsl configure --maxDataRate 60000 20000 80000
adsl configure --maxDataRate <maxdown> <maxup> <maxtotal>
The third one is a maximum for down+up.
-
Let say I have downstream sync rate of 35000 kbps and upstream rate of 6000 kbps and I want to cap my downstream by 5000 kbps it would look like this ->
xdslcmd configure --maxdatarate 30000 6000 36000
-
Done.
====================================================================================
VDSL Training Status: Showtime
Mode: VDSL2 Annex B
VDSL Profile: Profile 17a
G.Vector: Disable
Traffic Type: PTM Mode
Link Uptime: 0 day: 0 hour: 17 minutes
====================================================================================
VDSL Port Details Upstream Downstream
Line Rate: 20.063 Mbps 59.999 Mbps
Actual Net Data Rate: 19.999 Mbps 60.000 Mbps
Guess I just have to wait for a GEA test now. IP profile is 62.04.]
On a slightly different note, for the first time since I've joined, I'm really considering leaving - but it's unfortunate that I only migrated onto FTTC in August this year, I think I might have some difficulty in leave without being saddled with early termination charges. Zen, IDNet and AAISP do look pretty tempting though...
-
IP profile is 62.04
In theory that figure should change immediately in line with your sync speed. The fact that it hasn't updated is strange. :'(
I've just seen Anoush's reply about sync rate. I was about to fire off a long response but realised I would perhaps be wasting my time. That is comparable to the type of reply I'd expect from other large ISPs and indicates he doesn't understand what sync speed is. I'm at a loss for words. Its no wonder that PN's ratings have taken a drastic dive for CS over the past 6 months. :(
Its such a shame because at one point their CS understanding and knowledge was way better than the other large ISPs, now it appears to be akin to TT & BT :/ Jeeze at one point they used to have 'a bat' whereby reps making stupid comments were threatened with it. At that time their CS staff were good and the bat was more of a good humoured joke not anything real.
-
So as a slight diversion and to save me making another thread elsewhere, I was intrigued by Zen, IDNet and AAISP. Any general thoughts from fellow Kitizens?
Also anyone have any experience on early termination with Plusnet?
-
So the GEA test ran and I've found out a few things.
1. Downstream speed on the GEA test is an actual speed test without a doubt. GEA reports 57.4, and my speed test is pretty much bang on 57.4.
2. The parameters section at the bottom is the line rate which should correlate to the router (which is correctly 60, and was correctly 66.997 before)
3. My IP profile hasn't changed.... Still 62.1
4. Router stats as follows:
====================================================================================
VDSL Training Status: Showtime
Mode: VDSL2 Annex B
VDSL Profile: Profile 17a
G.Vector: Disable
Traffic Type: PTM Mode
Link Uptime: 0 day: 17 hours: 50 minutes
====================================================================================
VDSL Port Details Upstream Downstream
Line Rate: 20.063 Mbps 59.999 Mbps
Actual Net Data Rate: 19.999 Mbps 60.000 Mbps
Trellis Coding: ON ON
SNR Margin: 7.4 dB 9.7 dB
Actual Delay: 0 ms 0 ms
Transmit Power: 7.0 dBm 13.0 dBm
Receive Power: -8.6 dBm -3.5 dBm
Actual INP: 0.0 symbols 52.0 symbols
Total Attenuation: 0.0 dB 17.2 dB
Attainable Net Data Rate: 23.235 Mbps 75.192 Mbps
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 5.2 21.6 32.6 N/A N/A 12.1 27.7 42.2
Signal Attenuation(dB): 5.2 20.9 31.9 N/A N/A 13.4 27.5 42.2
SNR Margin(dB): 7.1 7.4 7.3 N/A N/A 9.7 9.7 9.7
TX Power(dBm): -3.5 -21.5 6.6 N/A N/A 9.7 7.8 6.9
====================================================================================
So reflecting on this, the earlier GEA tests weren't correctly reporting my downstream rate (GEA 64.1, but my actual results were 60ish). Additionally the IP profile hasn't changed at all which is strange.
Anyone know the command to unrestrict my sync?
-
Our posts crossed over on the PN forum.. I must have been reading and typing whilst you were making your reply.
>> Anyone know the command to unrestrict my sync?
The command doesnt stick. When Ive capped in the past, Ive simply done a full reboot of my router to take it back to default. (power down)
-
Thanks for that.
I've just posted this over on PN as well. How come the GEA tests before were reporting the downstream speed at 64.1 when my IP profile is 62.04? Does the GEA test bypass the IP profile when it's being run?
-
There is obviously something deliberate going on with the "Downstream Speed 57.4 Mbps" reported by the GEA test that we do not know about. It's possibly something to do with the "Retransmission High" profile and the expected reduction in speed from the retransmission dealing with errors/interference. It does not appear to be an incorrect value stuck in the system somewhere. It will not be a speedtest result.
Not sure why the IP Profile did not change. Did the PPP connection drop when you capped the speed?
-
GEA reports sync speed not a speedtest so it will be above the ip profile.
-
Yep session dropped and reconnected entirety.
The thing about downstream speed is that 57.4 was the exact speed test result from BTw. I've triple checked and the IP profile is still 62.04.
I've dropped my entire network and I'll leave it off for a few hours in the hope that might do something.
I still can't understand why my IP profile was 62.04, and why DLM hasn't done anything for 4 months
-
The 62.04 IP Profile was the expected percentage of the 64.1 speed, I don't know why it didn't change to about 96.7% of 57.4, but you didn't give it very long. Some Asus routers had issues with non-updating IP Profiles, but I think that was for the Asus models with built in VDSL2 modems.
If you want to know why the DLM did or didn't do anything, then you'll need to monitor the stats continuously with a program like DSLstats. The DLM may have done nothing because the Error Seconds rate and other stats are in the "no change" range, giving an Indicative Line Quality (ILQ) of Amber (amber making it sound worse than it really is). Not necessarily because the DLM is stuck or broken or anything like that.
-
Yeah you're right I'm probably being a fool and rushing things. Anyway, so I've reconnected around 1.30 hours after shutting down the network so I'll see over the next few weeks if there are any changes to the IP profile and if DLM wants to do anything.
I've made some improvements - dumped the microfilter and gone to a Mk3 SSFP, and replaced my DSL cable + connections between the modem and router with fresh and tested Cat6. :fingers:
Edit: I'm running the RT-N66U, not the DSL version. Current setup is VGM8324-->RT-N66U-->Stuff
Also, stats because why not :P
====================================================================================
VDSL Training Status: Showtime
Mode: VDSL2 Annex B
VDSL Profile: Profile 17a
G.Vector: Disable
Traffic Type: PTM Mode
Link Uptime: 0 day: 1 hour: 3 minutes
====================================================================================
VDSL Port Details Upstream Downstream
Line Rate: 20.063 Mbps 66.996 Mbps
Actual Net Data Rate: 19.999 Mbps 66.997 Mbps
Trellis Coding: ON ON
SNR Margin: 7.2 dB 7.8 dB
Actual Delay: 0 ms 0 ms
Transmit Power: 7.1 dBm 13.0 dBm
Receive Power: -8.5 dBm -3.4 dBm
Actual INP: 0.0 symbols 51.0 symbols
Total Attenuation: 0.0 dB 17.1 dB
Attainable Net Data Rate: 23.124 Mbps 75.277 Mbps
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 5.0 21.4 32.7 N/A N/A 12.0 27.4 42.5
Signal Attenuation(dB): 5.0 20.6 32.2 N/A N/A 13.2 27.2 42.5
SNR Margin(dB): 7.5 7.3 7.2 N/A N/A 7.8 7.8 7.8
TX Power(dBm): -3.6 -21.8 6.6 N/A N/A 9.6 7.8 6.9
====================================================================================
VDSL Counters
Downstream Upstream
Since Link time = 3 min 43 sec
FEC: 1271 17
CRC: 0 2
ES: 0 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 4 min 12 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: 27 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 = 1 hours 4 min 12 sec
FEC: 1271 17
CRC: 0 2
ES: 0 2
SES: 0 0
UAS: 29 29
LOS: 0 0
LOF: 0 0
LOM: 0 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
Total time = 1 hours 4 min 12 sec
FEC: 1271 17
CRC: 0 2
ES: 0 2
SES: 0 0
UAS: 29 29
LOS: 0 0
LOF: 0 0
LOM: 0 0
====================================================================================
-
With your current sync speed, and GEA test speed, there won't be any changes to the IP profile unless there are any changes to your sync speed and GEA test reported speed. 62.04 is the correct IP profile for the 64.1 speed.
-
So any ideas where this 64.1 speed thing is coming from?
Also - I'll leave DSLStats running, what info would you guys want from it?
-
64.1/67 = 0.9567164179 = 95.67%
57.4/60 = 0.9566666666 = 95.67%
It's probably something to do with the "Retransmission High" profile. There's probably someone at Openreach who knows exactly why it's happened, or it's in some Openreach document not available to the general public.
SHINEratio
The loss of rate in a 1 second interval expressed as a fraction of NDR due
to a SHINE impulse noise environment expected by the operator to occur
at a probability acceptable for the services.
Although we are used to what stats are provided by Broadcom based modems, they don't show everything. I'm guessing that the 64.1 is the ETR as defined in G.998.4.
11.2.1 Expected throughput (ETR)
The test parameter expected throughput (ETR) is defined in Table 9-2 as:
ETR = min(ETRu,ETR_max) kbit/s
where:
ETRu: is the unlimited version of ETR given by
ETRu = ( 1 - RTxOH ) x NDR
The RTxOH (see Table 9-2) is the expected rate loss, expressed as a fraction of net data rate (NDR),
due to the combined effect of:
- impulse noise protection against worst-case REIN impulses as described by the configuration
parameters INPMIN_REIN_RTX and IAT_REIN_RTX in the CO-MIB; - impulse noise protection against worst-case SHINE as described by the configuration
parameters INPMIN_SHINE_RTX and SHINERATIO_RTX in the CO-MIB; - overhead due to correction of stationary noise errors.
Most people with retransmission enabled will be on the "Retransmission Low" profile, not "Retransmission High" which you are on, so we haven't seen many cases like this, so I certainly didn't recognise what was going on with the GEA test showing a different speed value to what the modem was reporting.
-
I'm guessing the retransmission high is persisting from when the exchange was going FUBAR. It's not very clear from the PN thread but I've gone back through my fault ticket and the remote reset was done a week before the problem was sorted at the exchange, not afterwards.
I'm looking at my errors right now, 4 hours uptime and 2ES in the upstream, nothing on the downstream at all.
Another question at the risk of exposing myself as a complete noob - shouldn't my IP profile be 64.1 instead of 62.04?
-
On FTTC, the IP profile is always approximately 96.78% of the speed. 62.04 is 96.78% of 64.1.
You may also need to look at the retransmission (G.998.4 / G.INP) counters to get an idea of how hard the retransmission is or isn't having to work to achieve that very low number of uncorrected errors.
I suppose the usual thing to do these days is to sign up to https://www.mydslwebstats.co.uk/ in case anyone else wants to look at your stats.
Also, anything going on at the exchange really should not have had any impact on the VDSL2 connection between your FTTC cabinet and your modem.
-
Cool, I'm up on the site so my stats should be available under aneesh99. I've just had to stop and restart logging to get it uploading so there isn't much data yet. So far ILQ is green :fingers:
So that's the thing, I remember you mentioning that before. In the fault ticket, I was told in no uncertain terms that the reason was a 'hot VP', clearly given my symptoms of masses of errors and a tanking sync speed doesn't really fit that picture...
-
I was really surprised when I read of the "hot VP" excuse, as I regard that as something from the early days of xDSL circuits (e.g. G.992.1 (a.k.a. G.Dmt)) in the 20th Century and not something that should have "resurrected" (i.e. used) by Plusnet to account for their problems when providing a G.993.2 (VDSL2) based service. :-X
-
The longer this has gone on the more I feel like ¯\_(ツ)_/¯
So based on my stats so far, ILQ green, I can't understand why DLM hasn't done anything for the past four months...
-
The longer this has gone on the more I feel like ¯\_(ツ)_/¯
Is that :shrug2: ?
So based on my stats so far, ILQ green, I can't understand why DLM hasn't done anything for the past four months...
Because the DLM process is unable to remove banding from a G.993.2 based circuit. Interaction by an Openreach technician is required. :(
-
I thought I remember a thread where someone was watching the DLM gradually relax (increase the speed) of a banded FTTC line, after some internal wiring or fault was fixed. I didn't think the FTTC DLM was unable to remove banding.
I wouldn't even be completely sure if the DLM lights in a stats monitoring program are an accurate indicator, given we don't know that much about the retransmission counters and if any of them are collected and used by the DLM.
-
So what's the solution here? Is the only way to find out with OR having to reset?
-
I thought I remember a thread where someone was watching the DLM gradually relax (increase the speed) of a banded FTTC line, after some internal wiring or fault was fixed.
I can't recall that event . . . but I am prepared to accept your statement. :)
So what's the solution here? Is the only way to find out with OR having to reset?
Either wait and see or accept that British Telecommunications plc (trading as Openreach) may invoice British Telecommunications plc (trading as BT Wholesale) who may, in turn, invoice British Telecommunications plc (trading as Plusnet) who then will charge you. :-X
-
I'm not really sure where this leaves me? Back at the start where my it's being held back by banding and high retransmission? :-\
Errors so far today
Down Up
CRC errors/hour 0 6.80
FEC errors/hour 490 25.4
HEC errors/hour 0 0
Errored seconds (ES)/hour 0 4.64
Severely errored seconds/hour 0 0
-
I was rushing earlier - had to go out and had RL things that must be done - but I was still mulling things over in my head whilst away from the PC.
1) The GEA test itself cannot possibly perform a speed test - it would need to download some sort of file to measure throughput.
Therefore it must be some sort of projected throughput after allowing for overheads of something. So I started to think things through wondering what the something could be - The IP profile already makes an allowance for TCP/IP overheads so it wont be that. I doubt it will be any other protocol overheads so I was thinking what other types of overhead. RS overheads (INP) physically reduces the sync speed so its not that either.
However what I couldn't check whilst out, was look at the DLM profile again and it also struck me that I didnt recall seeing any stats showing the framing params to see if the line had G.INP rather than INP.
First thing I did when I got back in was check the profile again.
0.128M-67M Downstream, Retransmission High - 0.128M-20M Upstream, Error Protection Off
So retransmission High, which I don't think Ive seen before. I think, I can only ever recall seeing ReTx Low.
Then whilst I was away I see ejs has done some maths and spotted that the reduction from sync is 95.67% for both figures and he also is on to the Retransmission High.
Let me catch up reading what else has been said this afternoon, but I definitely think ejs is on the right track.
I also need to try read G.998.4 to refresh my memory.
-
I'm going to leave it to you guys then, this is way over my head ???
-
Going through the posts here one at a time
I'm up on the site so my stats should be available under aneesh99.
MDWS doesnt show framing params for the Bearers. They arent something that is graphed because they are static figures.
Presuming you have a VMG8324, you can however get them from adsl info --stats
I was told in no uncertain terms that the reason was a 'hot VP', clearly given my symptoms of masses of errors and a tanking sync speed doesn't really fit that picture...
No - a hot SVLAN does not and will not cause Err Secs to trigger the DLM.
You must have either had an excessive amount of errors over a few days (MTBE) OR an excessive amount of resyncs over the course of a few days (MBTR).
There is also something called ' ILQ Scarlet (http://www.kitz.co.uk/adsl/DLM.htm#DLM_profile_changes)' which can be triggered by a really excessive amount of retrains within a short time frame. Unfortunately unlike MTBR and MTBE I don't think Openreach discloses what causes ILQ scarlet.
One thing springs to mind here - WilliamG's 'line fault' that wasnt a fault (he did a pile of resyncs to test the DLM despite being advised not to). He ended up getting banded and we assumed he had triggered ILQ scarlet. We never saw the results of one of his GEA tests though (BTr dont give them out) so don't know what profile he was on nor what it would have said for the speed.
All we do know is that he got banded and it wasn't removed by an automated/remote DLM reset and after a few months of it not budging, it had to be done by an OR engineer.
So based on my stats so far, ILQ green, I can't understand why DLM hasn't done anything for the past four months
With G.INP I strongly suspect there is another parameter that Openreach measures rather than Err/Secs when deciding to relent.
MTBE and MTMR may well be the triggers for DLM to take action , but what is excruciatingly difficult to find any information about is how it reverses this procedure.
If a line has retransmission then I suspect it may be the LEFTR stats. I did try asking Ian Lawrence if LEFTR was monitored if a line had G.INP applied, but he neither denied nor confirmed this and remained tight lipped. There was a court case about 2yrs ago between BT & ASSIA. Since then they don't disclose a lot about the DLM process.. and we have a gap in knowledge on how DLM reverses any previous action.
Whilst you may currently be ILQ green, it would be interesting to monitor not just Err Secs but also LEFTRS. Unfortunately I dont think MDWS records these. If Tony is reading - it may be an idea if these could be recorded in the same way as Err Secs for lines with G.INP, as I think (ASS-u-me) they could be important when it comes to reversing a previous profile.
-
Going through the Plusnet forum posts
Aww Bless. It looks like Anoush isn't at work and still trying to help you from home in his own time. 10 out of 10 for persistance & dedication :D
TBH its getting late and I still have things I need to do here, so I'm not going to duplicate posts on both forums. :(
I have to admit, a small part of me is wondering what will happen if the line is reset by an engineer to remove the banding.
We've found it is the ONLY way to remove banding.
See my post here (https://community.plus.net/t5/Fibre-Broadband/Could-my-speed-be-better/m-p/1398151/highlight/true#M52926) explaining about the two different types of DLM reset.
On the BTw DLM (ADSL) there is something that can occur which causes immediate banding. We've known about this for a long time (years!). In cases such as these it wasn't always apparent that the line had been banded and the only way it could be removed was by the ISP asking BTw to remove the cap. Even though an ISP can reset the ADSL DLM, it didnt always remove the cap and (at least at one time) it had to be requested separately. Theres a post on here years ago from one of the Plusnet reps (Chris iirc) whereby we couldnt figure out why a line wouldnt reset properly. The PN rep came back and explained it was because the line had been capped. Let me see if I can find the post, but it was such a long time ago.
Im thinking this may be the NGA equivalent.
-
MDWS doesnt show framing params for the Bearers. They arent something that is graphed because they are static figures.
Presuming you have a VMG8324, you can however get them from adsl info --stats
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 23132 Kbps, Downstream rate = 75809 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 66997 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): 7.9 7.3
Attn(dB): 17.1 0.0
Pwr(dBm): 13.0 7.1
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 138 237
M: 1 1
T: 0 42
R: 8 16
S: 0.0000 0.3781
L: 17895 5374
D: 8 1
I: 147 127
N: 147 254
Q: 8 0
V: 5 0
RxQueue: 132 0
TxQueue: 33 0
G.INP Framing: 18 0
G.INP lookback: 31 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 2742457
OHFErr: 0 44
RS: 1676554840 543931
RSCorr: 4368 189
RSUnCorr: 0 0
Bearer 1
OHF: 1721587 0
OHFErr: 0 0
RS: 17215253 0
RSCorr: 23 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 17962520 0
rtx_c: 297 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 67002 0
errFreeBits: 28261313 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 3562802112 0
Data Cells: 146354634 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 31
SES: 0 0
UAS: 29 29
AS: 27661
Bearer 0
INP: 51.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 3.98
OR: 0.01 64.22
AgR: 67421.12 20063.54
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: 114/114 42/42
Total time = 7 hours 41 min 30 sec
FEC: 4368 189
CRC: 0 44
ES: 0 31
SES: 0 0
UAS: 29 29
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 11 min 30 sec
FEC: 64 2
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: 25 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 = 7 hours 41 min 30 sec
FEC: 4368 189
CRC: 0 44
ES: 0 31
SES: 0 0
UAS: 29 29
LOS: 0 0
LOF: 0 0
LOM: 0 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
Since Link time = 7 hours 41 min 1 sec
FEC: 4368 189
CRC: 0 44
ES: 0 31
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
No - a hot SVLAN does not and will not cause Err Secs to trigger the DLM.
I can PM you or upload the entire ticket to read through if that'll be any help?
Whilst you may currently be ILQ green, it would be interesting to monitor not just Err Secs but also LEFTRS. Unfortunately I dont think MDWS records these.
I think the LEFTRS stat in in the adsl info --stats above. Both upstream and downstream counters are zero though.... ???
I've noticed the INPRein stat. What's the significance of it and does it indicate anything relevant?
-
The PN rep came back and explained it was because the line had been capped. Let me see if I can find the post, but it was such a long time ago.
Damn I can't find it. All I can recall is that the line was banded at 2Mbps and we couldnt figure out why. It was a Plusnet customer and one of the PNreps sorted it by contacting BTw direct. Ive tried going through the ISP rep posts but cant see it on there. However it could be one of the reps that is no longer with Plusnet which is why I cant find it by looking at posts for tagged ISP reps :(
-
I've attached the fault ticket just in case there's anything here that helps.
Thanks again all, I appreciate the help so far. Please enjoy your holidays! :)
-
G.INP Counters
LEFTRS: 0 0
minEFTR: 67002 0
errFreeBits: 28261313 0
From G.INP Parameters & Counters (http://www.kitz.co.uk/adsl/linestats_errors.htm#retx_params)
LEFTR = Loss of Error Free Throughput - Count of seconds with a defect. (Could be similar to Err/Secs for G.INP lines?).
minEFTR = Minimum Error Free Throughput
minEFTR is a performance monitor measured at showtime of the minimum of the EFTR observed in the seconds since the last reading of the EFTR_min, excluding the following seconds.
– seconds in which the values of EFTR are less than ETR/2;
– seconds in which EFTR is not defined;
– the single second preceding a second with seftr defect;
– the single second following a second with seftr defect.
[note: appears to bear some resemblance to sync speed]
Both upstream and downstream counters are zero though
Thats fine - It just means there havent been any and G.INP is working fine.... in the same way how a good line without G.INP may not show any Err/Secs.
I can PM you or upload the entire ticket to read through if that'll be any help?
You can do... but I will be honest and say that I'm not sure if I will have chance to read through properly for the next few days :/
I had hoped to get to bed at a reasonable hour tonight, but I still have IRL things I need to do (Not given Ziggy his meds yet and it takes me about 1/2 hr to prep the syringe and wrestle with him) :D :D
Not had time to revisit the G.998.4 documentation either, however ejs seems to be on the ball there, so for now I will have to leave that side of things in his capable hands.
--------------
ETA
I see you've attached them whilst I was typing. I will try look tomorrow. My alarm has been going off since 11pm to give Zigs his meds. He gets poorly if he doesnt get them.
----
PPS
May be a good idea if you get chance to point out to Anoush my post about the 2 types of DLM reset and its only the OR engineer one that does a full reset.
-
No bother, enjoy the holidays! Doubt I'm going to be in much of a state to check in before the new year ;D
-
Cheers. :drink:
btw I added something to my post above -which if you get chance may be worth reminding Anoush about.
-
Perhaps aneesh99 should attempt (again) to accept Anoush's original offer to send an engineer to reset the banding if the banding were limiting the speed, since it is. I think the trouble on the thread on the Plusnet forums started with that questionable statement that they would just send an engineer to reset banding if the banding were limiting the speed. I think they should have initially been advised that because the speed was within the estimate, there's nothing they're going to do about it (but obviously phrased in a nicer way). There would be no purpose to the DLM ever applying any banding in the first place if someone's just going to reset it (and there also wouldn't be any purpose in applying banding that wasn't limiting the speed). However, we were happy enough to go along with that dubious policy of sending an engineer to reset the banding, because that would achieve the desired outcome.
If the engineer visit is chargeable, I think it would be fairer for aneesh99 to pay than have the ISP (or effectively, everyone else) absorb the cost. But then I suppose it's going to be Plusnet paying for their own bad advice.
-
Well, I ended up hearing back from Bob with a canned response that he can't do anything, fair enough I suppose. Not really sure how to proceed, I'd be inclined to leave it alone for a few months and see if things sort themselves out but at 4 going on 5 months, I'm skeptical to say the least...
-
So just to follow up, still no movement on the DLM side of things. Stats are rock solid so I can't understand why DLM won't do its thing? Maybe something to do with re transmission high?
====================================================================================
VDSL Training Status: Showtime
Mode: VDSL2 Annex B
VDSL Profile: Profile 17a
G.Vector: Disable
Traffic Type: PTM Mode
Link Uptime: 49 days: 17 hours: 2 minutes
====================================================================================
VDSL Port Details Upstream Downstream
Line Rate: 20.063 Mbps 66.998 Mbps
Actual Net Data Rate: 19.999 Mbps 66.999 Mbps
Trellis Coding: ON ON
SNR Margin: 15.2 dB 8.6 dB
Actual Delay: 0 ms 0 ms
Transmit Power: 7.0 dBm 13.0 dBm
Receive Power: -7.8 dBm -3.6 dBm
Actual INP: 0.0 symbols 49.0 symbols
Total Attenuation: 0.0 dB 17.1 dB
Attainable Net Data Rate: 23.263 Mbps 77.568 Mbps
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 5.0 21.4 32.7 N/A N/A 12.0 27.4 42.6
Signal Attenuation(dB): 5.0 20.8 32.2 N/A N/A 13.2 27.2 42.6
SNR Margin(dB): 15.1 15.1 15.2 N/A N/A 8.6 8.6 8.5
TX Power(dBm): -2.9 -21.7 6.6 N/A N/A 9.4 7.7 7.1
====================================================================================
VDSL Counters
Downstream Upstream
Since Link time = 2 min 47 sec
FEC: 894880 36598
CRC: 1 5287
ES: 1 4662
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 3 min 44 sec
FEC: 17 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: 22 2
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 = 10 hours 48 min 44 sec
FEC: 3299 218
CRC: 0 35
ES: 0 34
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 17774 556
CRC: 0 81
ES: 0 75
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Total time = 1 days 10 hours 48 min 44 sec
FEC: 894880 36598
CRC: 1 5287
ES: 1 4662
SES: 0 0
UAS: 48 48
LOS: 0 0
LOF: 0 0
LOM: 0 0
====================================================================================