Post by: 8062282 on September 21, 2019, 07:07:13 AM
Average error rates for 20 Sep 2019
CRC erors per hour: 376 Down, 1.38 Up
FEC erors per hour: 125 Down, 7.55 Up
HEC erors per hour: 884 Down, 0 Up
ES per hour: 32.6 Down, 100 Up
SES per hour: 1.50 Down, 0.33 Up
Total ES in the day: 780 Down, 2397 Up.
The 2nd 1200 ES spike was me unplugging the DSL cable from the back of the modem for about 20 secs to try & stop the errors. The odd thing is, FECs have always been an issue despite low errors in other area's. Now the FECs on the DS have stopped altogether. All the other errors are increasing. Error count from midnight today:
Average error rates for 21 Sep 2019
CRC erors per hour: 430 Down, 1.38 Up
FEC erors per hour: 0 Down, 2.30 Up
HEC erors per hour: 194 Down, 0 Up
ES per hour: 31.2 Down, 1.38 Up
SES per hour: 1.38 Down, 0 Up
Total ES in the day: 204 Down, 9 Up
I've attached a screen shot showing the ES, bit loading graph & the QLN. I also have some different stats being reported in the modem to what DSLstats is reporting. The stats are telling me:
Max: Upstream rate = 8204 Kbps, Downstream rate = 38029 Kbps
Bearer: 0, Upstream rate = 8024 Kbps, Downstream rate = 39973 Kbps
My modem is telling me:
VDSL Port Details Upstream Downstream
Line Rate: 8.044 Mbps 40.035 Mbps
Actual Net Data Rate: 8.024 Mbps 39.973 Mbps
BT aren't going to do anything as I'm getting the above the guaranteed speed. Surely this isn't normal or is it? No idea how BT DLM works & whether it'll think these errors are acceptable day in day out. I did consider a re-boot last night due to the different stats in the modem & DSLstats, but I thought I'd wait to see if DLM kicked in this morning. It hasn't.
Stats recorded 21 Sep 2019 07:06:26
DSLAM type / SW version: IFTN:0xd086 (208.134) / v0xd086
Modem/router firmware: AnnexA version - A2pv6F039v.d26a
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 17 hours 51 min 18 sec
Resyncs: 2 (since 19 Sep 2019 06:08:54)
Downstream Upstream
Line attenuation (dB): 19.8 0.0
Signal attenuation (dB): Not available on VDSL2
Connection speed (kbps): 39973 8024
SNR margin (dB): 4.8 6.1
Power (dBm): 12.2 6.0
Interleave depth: 1 1
INP: 0 0
G.INP: Not enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
RSCorr/RS (%): N/A 0.0066
RSUnCorr/RS (%): N/A 0.0000
ES/hour: 30.1 1.27
Let me know if you need anything else from DSLstats. Any advice?
EDIT (21.09.18 07.53) - The modem has just re-synched which has resulted in the SNR going from 4.8dB to 7.1dB & the speed has dropped. Interleave is still at 1 / 1. G.INP isn't on. Still no FEC errors but all the other errors are still there & increasing. Seems very odd to that's it's started doing this..
Max: Upstream rate = 8184 Kbps, Downstream rate = 37824 Kbps
Bearer: 0, Upstream rate = 7968 Kbps, Downstream rate = 34974 Kbps
Post by: ejs on September 21, 2019, 09:04:13 AM
Post by: 8062282 on September 21, 2019, 09:28:53 AM
I don't see any particular problem here. The error rate looks perfectly acceptable. There'll be no FEC count on the downstream because there isn't any FEC applied to the downstream. Are you experiencing any problems with your usage of the Internet? It sounds like that at some point, interleaving and FEC were switched off, and subsequently your error rate became higher, which is entirely to be expected.
It just seems odd that I've had a low error count for days (apart from FECs) & then all of a sudden the speed drops & the error count starts going up & up. I've always had 1000's FEC errors. Does a 1200 upstream ES spike sound normal when the modem re-syncs? I'm not sure what you mean by 'there isn't any FEC applied to the downstream'.
The issues that I had with TalkTalk seem to be ongoing with BT in that my line doesn't seem very stable & seems to doing odd things sporadically. I should have gone onto VDSL on the 6th Aug but OR migrated me to copper in error. The OR engineer (10th Aug) did the L & S when I was on BT ADSL. I thought that was a bit pointless as I didn't migrate to BT VDSL until the 22nd. I'm just wondering if I could persuade them to get an engineer out now I'm actually on the right service..
Thanks for the info on the errors. I'm not sure what the BT DLM considers acceptable..
Post by: ejs on September 21, 2019, 09:50:03 AM
When you had interleaving, you had forward error correction on the downstream. Now you have no error correction on the downstream.
I think the DLM limit is 2880 ES per day for the Openreach Speed profile (which equates to the MTBE red threshold of 30).
Post by: 8062282 on September 21, 2019, 10:56:51 AM
I'm not sure what you mean by a 1200 upstream ES spike. That's 20 minutes of constant ES. I can't really see how you can actually have 1200 ES in any shorter space of time. If your stats have 1200 ES in an instant spike, that'll be some sort of reporting oddity during the re-sync.
When you had interleaving, you had forward error correction on the downstream. Now you have no error correction on the downstream.
I think the DLM limit is 2880 ES per day for the Openreach Speed profile (which equates to the MTBE red threshold of 30).
I'm on my 3rd modem. I had a billion 7800DXL on ADSL & continued to use that when I was on BT ADSL. I them got a VMG3925-10B & now I'm using a VMG8924-B10A. All 3 have at some point indicated a weird US error second spike. If it shows in my modem stats, is this being reported back to the DLM? After always seeing 1000's of FEC errors on the downstream, it's a surprise not to see any at all. I never really had any CRC's but now I'm getting lots of CRC's. I would prefer FECs to CRCs.
After being on BT since the 22nd, my speed & errors are the worst they've been since the re-sync at midnight on the 20th Sept. I suppose I'm stuck with what I have as I'm above the guaranteed speed. I did say that the line they gave me after the L & S was worse (in terms of speed) than I had before but they aren't bothered. I also find it a bit frustrating that somebody who's on the same cabinet as me can get 55/10 & I'm banded at 40/10 because of a poor line. Especially when you pay the same. I used to have good internet & then it suddenly went very poor & that's when all the issues started. I suspect over time, my line has been swapped. Rob Peter to pay Paul. As I haven't been on VDSL before, I have nothing to compare it too.
Post by: kitz on September 21, 2019, 07:36:54 PM
Quote
I also have some different stats being reported in the modem to what DSLstats is reporting.
DSLstats gets the figures via telnet from the Broadcom CLI (modem chipset)
The sync rates are actually the same - Just the labelling is different.
DSLstats --- > Bearer: 0, Upstream rate = 8024 Kbps, Downstream rate = 39973 Kbps
Web GUI ----> Actual Net Data Rate: 8.024 Mbps 39.973 Mbps
The other 2 figures are the max attainable rate and can vary by the second depending upon your SNR Margin. It is an estimated figure based on various factors and should not be relied upon especially if interleaving is involved
--------------
The presence of FECs [usually] mean that you have Interleaving and RS error correction switched on. The fact that you no longer are getting any FECs means that the DLM has judged your line stable enough to attempt running the line without error correction.
The fact DLM has switched off Interleaving & error correction is usually a good sign that all is OK with the line and it is performing within acceptable parameters.
It is perfectly normal for a line without error correction to see an increase in CRCs. Have a read of the Error Correction (https://kitz.co.uk/adsl/error_correction.htm) page - in particular the bit about FEC and Reed Solomon Coding. But in a nutshell FECs are what could become CRCs if the line wasn't interleaved.
As long as your line is performing within its profile then up to 2880 E/Secs per day for speed profile is considered acceptable by DLM. Most lines will record a few additional errors during the sync process.
You won't get G.INP as you are on an ECI cab. Most lines see a better sync speed when 'Interleave' is switched off because you don't have RS overheads.
----
Quote
I'm banded at 40/10 because of a poor line.
You are not banded in the true sense. Whilst I appreciate that BT are restricting you to the 40Mbps product, from what I can see there just is not any more speed availability in that line.
More of interest would be looking at your SNR Margin graphs to determine if there is a pattern to the SNRM fluctuations.
[Moderator edited to replace a space character that "got away".]
Post by: j0hn on September 21, 2019, 11:34:27 PM
DLM allows twice as many ES in such a case and what DLM policy an ISP uses would be high on my priorities list, especially if I were still on an ECI DSLAM.
Post by: 8062282 on September 22, 2019, 11:45:58 AM
Anyway, the DLM kicked in last night & I'm back to interleaving on at 793 on the DS. SNR is a 6.3dB. Speed has dropped to 34,995 with an attainable of 41,727. My errors prior to DSLstats having a dicky fit were.
Average error rates for 21 Sep 2019
CRC erors per hour: 477 Down, 1.45 Up
FEC erors per hour: 0 Down, 2.17 Up
HEC erors per hour: 180 Down, 0 Up
ES per hour: 32.7 Down, 148 Up
SES per hour: 2.53 Down, 0.48 Up
Total ES in the day: 2169 Down, 2473 Up
Looking at the log, it stopping recording at 23.06 so I guess those figures aren't too far out. I've been on VDSL since the 22nd of Aug & even now, my line isn't stable in that, it's unpredictable. They've banded me on a 40/10 despite my speeds being 52.1 & 50.3 on the DSL checker. Prior to the L & S there were 54.8 & 52.9. I have this issue which came with me from TalkTalk in that the noise drops at night sometimes so much that the SNR goes up giving me an attainable speed of 45/46Mb. When I first went onto VDSL, they put me on ADSL in error (6th Aug) & I didn't go over to VDSL until the 22nd. They addressed the drops & noise whilst I was on ADSL, hence the L & S & I lost a couple of MB on the DSL Checker. No big deal, it's just the unpredictable line means the DLM is up & down like a yo yo. I just wish the OR engineer had said there was no point in sorting this line out until I was on VDSL.
Even though I'm above the guaranteed speed (a paltry 25mb), is it worth reporting this fluctuating SNR & will they do anything about it? How do they arrive at the guaranteed speed? I'm about 300m from the cabinet. No idea if my speed will go back to the 39Mb I had previously or will this constant up & down SNR end up with me being banded at my current speed of 35Mb. Why also, is somebody expected to pay the same if they're banded at 40/10 & somebody on the same cabinet roughly the same distance can get 55/10. I know I sound like a spoiled brat over a few MB's but this unpredictable line is a tad frustrating. OR, instead of improving my line, have made it worse, in that, I have the same issues & I've lost speed at the top end. BT should at least take ownership of that..
Post by: Weaver on September 22, 2019, 01:45:17 PM
You are. ;) But you’re not alone! :) It’s the same as me moaning all the tied over my wretched upstream combined speed bonding efficiency and some lines’ varying upstream.
This might help soothe you.
Live sync rates:
#1: down 2913 kbps, up 532 kbps
#2: down 2762 kbps, up 512 kbps
#3: down 2748 kbps, up 352 kbps
#4: down 2850 kbps, up 496 kbps
Post by: 8062282 on September 22, 2019, 02:52:30 PM
I had a good internet connection when I was with Virgin. 8mb line with a 6.5mb download over wi-fi. I then got 'dumped' on TalkTalk when Virgin didn't want to support their ADSL customers anymore. I was still getting a 6.5mb download so all was good. Round about the beginning of the year my internet started getting slower & slower. Being naive & not knowing what to do for the best, I'd re-boot the router in the hope I'd get a better speed. I did, albeit it was short lived. Come March, I'd had a enough & that's when I posted on the TalkTalk forum & that's when I started learning about the do's & don'ts. I also learned how unhelpful TalkTalk were & their rubbish aggressive DLM. When the SNR went up at night, the attainable was 9.5mb but due to their rubbish DLM, I never got anyway close to that. In the end, I was capped at 4mb.
When I got put on ADSL in error & they did a lift & shift, I pointed out that my line was worse than it was before. All everybody kept saying was, wait until you're on VDSL & everything will be alright. Now I'm on VDSL & everything isn't alright, I'm expected to live with it because I'm getting above the guaranteed speed. OR had the opportunity to put me on a better line & for whatever reason, they gave me a worse one. I say worse in that I've lost top end speed. One thing that has stopped is some night time error seconds that TalkTalks DLM took great delight in using to reduce my speed. I don't get those on VDSL so the L & S did cure one issue. I'm still getting the fluctuating SNR, although it doesn't go as high as it did when I was on TalkTalk. 7.8db is the highest on BT, on TT it was going into double figures..
Just for giggles I've attached a picture of my cabinet. I'm 300m away. The garage behind it including the Spar to the right & the used car garage & the house to the left have all been demolished. It's just a cordoned off area of stones. They could have upset anything demolishing everything (maybe). There's a street lamp that sits about 2' from the cabinet + two redundant lights for the garage + 2 sets of traffic lights. Any one of many things that could be causing an issue..
Post by: gt94sss2 on September 22, 2019, 05:53:35 PM
FEC errors are not really errors but errors that the modem has prevented.
Modems which are interleaved generally show overly optimistic/unachievable maximum attainable data rates.
Whatever, you do - don't reboot or disconnect the modem.. - that will just make DLM think your line is unstable
Post by: 8062282 on September 22, 2019, 06:52:34 PM
I would ignore the errors if I was you for the timebeing - and post a screenshot of the SNR graph over 24 hours. That is likely to be more informative about the quality of your line - and if you do it over a period of several days, their may be a clue as to what is causing your SNR to vary.
FEC errors are not really errors but errors that the modem has prevented.
Modems which are interleaved generally show overly optimistic/unachievable maximum attainable data rates.
Whatever, you do - don't reboot or disconnect the modem.. - that will just make DLM think your line is unstable
Hi - I've been monitoring my connection since sometime in June. The SNR is always quite stable. It deviates maybe 0.2 at most, up or down. Suddenly it will go up late at night or very early hours of the morning. It can stay like that until morning or as late as lunch-time & then it goes down to 6. something. I can be sat here on my own using nothing in the house other than the PC & all of a sudden it will go back down. There's usually a spike of something that presumably creates enough noise to bring it back down. It's not anything we switch on or off in the house as I've seen it happen often enough when I'm on my own. Whilst I'm at work, if I see any unusual spikes of interference that have happened during the day, when I get home, my partner get the the 3rd degree about what they've used & at what times :)
I did get excited about going onto VDSL as there's a green cabinet 20' away. I then got very un-excited when OR told me it was a Virgin cabinet. I did see another cabinet at the bottom of the avenue, maybe 150m away. My cabinet is up on the other side of the road on the main road through where I live about 300m away. Can't tell whether the one at the bottom of the avenue is a BT cabinet though. I've posted a pic. If it's a BT cabinet, I would imagine I'd have to donate a kidney to get my line swapped to that :)
I never randomly re-boot the router. If I've switched it off as I did when I made a bespoke Cat 6 RJ11 - RJ45 cable up, I've always left it off for at least 30 mins..
Post by: j0hn on September 22, 2019, 07:02:09 PM
In the stats you showed above it was below 40Mb and the attainable showed it wasn't capable of going that high.
It might have 1 day but crosstalk eats away at the speeds of most lines over time.
Post by: 8062282 on September 22, 2019, 07:29:26 PM
You're line didn't look banded at 40/10 in the first post.
In the stats you showed above it was below 40Mb and the attainable showed it wasn't capable of going that high.
It might have 1 day but crosstalk eats away at the speeds of most lines over time.
It was sat quite happily at 39.5mb until this morning when it all went pear shaped. When interleaving came off on the 20th that's when the errors started getting really high. When it re-synced to 34.995 this morning the errors have been negligible all day. Looking at the wi-fi connections there's a lot of FTTP so maybe one day things will improve. Not sure how I'll find out though if I'm banded at 40/10.
Post by: burakkucat on September 22, 2019, 07:53:56 PM
Can't tell whether the one at the bottom of the avenue is a BT cabinet though. I've posted a pic.
I can confirm that it is not part of BT's or Openreach's infrastructure.
Post by: 8062282 on September 22, 2019, 08:00:51 PM
Post by: kitz on September 23, 2019, 12:13:30 PM
Quote
>> I'm still getting the fluctuating SNR, although it doesn't go as high as it did when I was on TalkTalk. 7.8db is the highest on BT, on TT it was going into double figures..Vdsl uses higher frequencies which can be more susceptible to noise. Although looking at your QLN and bit loading, most of the noise appears to be affecting the range also used by adsl. I haven't seen your hlog and can't confirm until I do... but I suspect your issues are more down to noise rather than the condition of the physical line itself.
Quote
>>
No idea if my speed will go back to the 39Mb I had previously or will this constant up & down SNR end up with me being banded at my current speed of 35Mb.
As mentioned in my previous post, you are not banded. The line is being limited based on the available SNRM.
As I also mentioned the line rate would be less if DLM applied Interleaving - which it now has and why you have lost some further sync speed. :(
I hinted in my post that seeing the SNRM graphs would be useful to see if we could determine any patterns. It is noise that is causing the underlying changes in sync rate and also causing Err Secs, which obviously DLM doesnt like.
A zoomed in capture of your bitloading over tones 50 to 500 may also be useful as this appears to be where you are losing a good chunk of your speed.
B*cat is usually very good at spotting noise due to RFI and radio stations... although I suspect from the wider view this is not broadcast RFI as the gap appears too wide.
Quote
>> Why also, is somebody expected to pay the same if they're banded at 40/10 & somebody on the same cabinet roughly the same distance can get 55/10.
Because it costs the same to provision the port in the cab and the backhaul fibre where most of the ££££ goes, but if anything it is the longer lines (those further from the cab and the exchange) that are the most expensive for Openreach because they have longer copper lines and require more maintenance of cabling and joints etc.
The longer lines also tend to be more troublesome requiring more Openreach man hours and support for the ISPs.
A line right next to the exchange and cab seldom has any problems and requires short lengths of both fibre and copper, so as far as Openreach are concerned a line capable of 80Mbps is actually cheaper than one which struggles to get 20Mbps.
Since 21CN and FTTC the use of WDM on fibre makes bandwidth a heck of a lot cheaper than it used to be. In the old days of 'just adsl', backhaul was an expensive element because it was in limited supply and why traditionally 2Mb was dearer than 512kbps. WDM (https://kitz.co.uk/adsl/21cn_network.htm#WDM)changed all that but it cost Openreach/BTw multi-millions to install the 21CN equipment as the WDM kit is not cheap This is the base backhaul on which FTTC/FTTP runs.... so these days there is negligible difference between a 10Mbps line and a 80Mbps connection when it comes to running costs and provisioning.
Unfortunately it's a fact of life that DSL technology does what it can and goes as fast as it can over copper wires. The longer the copper length, then less the speed :(
Post by: 8062282 on September 23, 2019, 05:50:49 PM
Average error rates (so far) for 23 Sep 2019
CRC erors per hour: 1.52 Down, 0.90 Up
FEC erors per hour: 8089 Down, 2.41 Up
HEC erors per hour: 51.0 Down, 0 Up
ES per hour: 0.45 Down, 0.84 Up
SES per hour: 0 Down, 0 Up
Total ES in the day: 8 Down, 15 Up
Post by: 8062282 on September 23, 2019, 05:51:42 PM
When the SNR sometimes goes up at night some of the missing chunks are filled in between 139 & 305. They don't go that high but there's something there. I've added a pic..
Post by: burakkucat on September 23, 2019, 06:40:49 PM
The expanded Bit Loading plot clearly shows where the downstream power back-off (DSPBO) would be applied . . . what I suspect we are seeing is a combination of a deep DSPBO notch and a band of RFI. Referring back to the QLN plot, it is extremely "messy" in that frequency region . . . nothing stands out as being the result of licensed broadcast transmissions. The only comment I can make is that the frequency range is afflicted by a fairly wide band of RFI / EMI. (Could there be someone using an elderly arc-welding set in the vicinity?)
Post by: 8062282 on September 23, 2019, 07:27:11 PM
I just wish the OR engineer had done the lift & shift when I went over to VDSL instead of doing it when I was on ADSL. I don't think I have any leverage now I'm getting above the guaranteed speed. I do have the telephone number of an OR manager but I don't think he would take too kindly to a random out of the blue phone call pleading with him to give me a better line. All there is on the main road from my house to the cabinet is a bargain booze, a sandwich shop, Chinese takeaway, carpet shop & a hardware shop. Nothing that stands out as being a transmitter of interference. Any errors I get are generally late afternoon onwards yet the noise quite often goes down at night & the SNR increases.
Post by: burakkucat on September 23, 2019, 08:25:18 PM
If you know your cabinets, I'm on Bamber Bridge, cabinet 2 (Preston, Lancashire).
After a wave of the magic wand, coupled with an uttering of the required incantation, I can say that your circuit does terminate on ECI electronics. :-X
Fibre Cabinet Fibre Status Phase Properties Vendor Approx Post
Passed Code
P2 Available from 10th June 2016 15b 478 ECI PR5 5AS
Quote
If it was an arc welder or similar, would the tones not fill in when it wasn't being used. Apart from when the SNR goes up, they never do..
Yes, your logic is impeccable. I should have really typed "something like an arc welder that is operational 24 hour a day".
Post by: 8062282 on September 23, 2019, 08:37:01 PM
After a wave of the magic wand, coupled with an uttering of the required incantation, I can say that your circuit does terminate on ECI electronics. :-X
Fibre Cabinet Fibre Status Phase Properties Vendor Approx Post
Passed Code
P2 Available from 10th June 2016 15b 478 ECI PR5 5AS
Yes, your logic is impeccable. I should have really typed "something like an arc welder that is operational 24 hour a day".
No worries
I've been through all the bit loading graphs that I have and they're all the same until the SNR goes up at night.
Post by: burakkucat on September 23, 2019, 09:07:15 PM
Having had a virtual wander around the area (thanks to Google Maps Street View) I located "Bargain Booze (https://www.google.com/maps/@53.7274458,-2.6849409,3a,37.5y,336.44h,84.72t/data=!3m6!1e1!3m4!1sQFrveJeh4hRRJVc_O_Tqbw!2e0!7i16384!8i8192?hl=en)" on the north-west corner of the junction of Brownedge Road and Cedar Avenue.
After a few more minutes, I located P2 (https://www.google.com/maps/@53.7274025,-2.6819535,3a,75y,212.04h,83.17t/data=!3m6!1e1!3m4!1sjeHW8cS0T85xxdK8UrssCw!2e0!7i16384!8i8192?hl=en) on the south-west corner of the junction if Brownedge Road and Todd Lane South. Its "fibre twin (https://www.google.com/maps/@53.7272323,-2.6819128,3a,37.5y,66.39h,78.98t/data=!3m6!1e1!3m4!1saka7DiOoqGgz7xPCtLciNA!2e0!7i16384!8i8192?hl=en)" is located by the hedge on the opposite side of Todd Lane South.
Considering the environment (https://www.google.com/maps/@53.7272416,-2.681361,450m/data=!3m1!1e3?hl=en), I can see no obvious potential source for the RFI "splat". :-\
Post by: kitz on September 23, 2019, 11:53:18 PM
Having now seen the Hlog plot, I am confident that there is no defect in the metallic pathway.
Have we actually determined which type of electronics resides in the cabinet?
I agree, that hlog looks good, nice clean slope. I suspected it may be, gut instinct was already telling some sort of REIN/EMI type interference. I didn't like the look of the bitload and QLN graphs :(
Yes it's definitely an ECI (IFTN:0xd086 on the stats) and its why I'd said in an earlier post he wouldn't get G.INP. :/
Quote
The expanded Bit Loading plot clearly shows where the downstream power back-off (DSPBO) would be applied . . . what I suspect we are seeing is a combination of a deep DSPBO notch and a band of RFI.
Thanks 8062282 for providing that I wanted to see a clearer picture of which tones are affected. Tones in that region usually have PSD masks applied. There are several different PSD masks in use but what we see here is not a result of PSD masking either.
I'm not too certain about the slide on the tail end of the mask area. The RH side usually steps up faster than the beginning and they most certainly do not have a crest smack bang in the middle of them. Nor do they usually go from 12 bits to zero bits and back up to 12 bits. Finally PSD masks do not cause the mess displayed at the corresponding tones on your QLN.
Hard to tell from the QLN but the floor at tone 250 is circa -138 dB and lower than the upstream power back off. Upstream PBO is usually much harsher than PSD masking.
All the indications are that you have some sort of REIN like issue affecting a fairly wide band of tones. :(
Unfortunately REIN is a pig to solve unless you know where the interference is coming from.
Quote
I just wish the OR engineer had done the lift & shift when I went over to VDSL instead of doing it when I was on ADSL.
REIN type faults cannot be cured by a lift and shift, nor them putting you on a new d-side.
The physical line itself looks perfectly good, so no matter what Openreach do to the copper side of things the RFI/EMI doesnt go away and just follows over to the new line :'(
Best I can suggest for now is have a read of this page :- REIN faults (https://kitz.co.uk/adsl/rein.htm)
Post by: 8062282 on September 24, 2019, 07:00:14 AM
P.S - I'm a 'she' in her late 50's. Geeky but not geeky enough. Networking isn't something I've really needed to get involved in, so it's all new to me. Apologies if I sound a bit dumb most of the time :)
Post by: 8062282 on September 24, 2019, 07:35:41 PM
I didn't realise that there was 2 cabinets. How does that work? My house is down the road towards the bargain booze. Is there two sets of lines from the exchange, one fibre going to the fibre cabinet & 1 copper to cabinet 2. How do they get the copper lines connected to the fibre cabinet?
Post by: burakkucat on September 24, 2019, 09:32:09 PM
I didn't realise that there was 2 cabinets. How does that work? My house is down the road towards the bargain booze. Is there two sets of lines from the exchange, one fibre going to the fibre cabinet & 1 copper to cabinet 2. How do they get the copper lines connected to the fibre cabinet?
The existing telephony PCP (primary cross-connection point), P2, is a junction point between the cable(s) from the serving (telephony) exchange, the E-side cable(s), and those cables, the D-side, that then radiate out to distribution points (DPs) which will be close to the end-users' (EUs') premises. From the DP, there will either be an underground feed or an aerial drop to the actual premises, at which point there may be a "lead in" cable.
When P2's "fibre twin" was installed, it needed to be near a source of mains electricity (for the DSLAM, the active electronics) and near to the existing telephony PCP. The optical fibre cable that connects to the DSLAM will come from a fibre "head-end" exchange and not your serving telephony exchange. In your case, I'm guessing that Preston is the fibre head-end exchange. (I suspect that kitz will be able to say, for sure . . .)
Between the PCP and its "fibre twin" cabinet, there exist a pair of "tie cables". Each cable contains a pair for every VDSL2 service. When your service was deployed, an engineer attended the PCP and removed the link between the E- and D-side cables for your line. Your E-side pair was then extended across to the "fibre twin" cabinet via the E-side tie-cable. It then passes through a low-pass filter and onto a line card port of the DSLAM. That same point is also connected to a pair in the D-side tie-cable, which takes it back to the PCP. That pair was then connected to your D-side pair, which then feeds both the telephony and broadband signal to your home.
Hopefully that makes some sense. :)
Post by: burakkucat on September 24, 2019, 09:38:53 PM
Yes it's definitely an ECI (IFTN:0xd086 on the stats) and its why I'd said in an earlier post he wouldn't get G.INP. :/
As you will have no doubt guessed, the grumpy old black cat failed to note what was right under his nose! ;)
Post by: 8062282 on September 24, 2019, 09:49:56 PM
The existing telephony PCP (primary cross-connection point), P2, is a junction point between the cable(s) from the serving (telephony) exchange, the E-side cable(s), and those cables, the D-side, that then radiate out to distribution points (DPs) which will be close to the end-users' (EUs') premises. From the DP, there will either be an underground feed or an aerial drop to the actual premises, at which point there may be a "lead in" cable.Hi - I wasn't expecting that. I somehow thought there was a bunch of cables underneath the road from the fibre cabinet to the copper cabinet & they just disconnected the copper & connected the fibre. After thinking about it, I realised if they did that, it'd be so much easier to put the fibre cabinet next to the other one..
When P2's "fibre twin" was installed, it needed to be near a source of mains electricity (for the DSLAM, the active electronics) and near to the existing telephony PCP. The optical fibre cable that connects to the DSLAM will come from a fibre "head-end" exchange and not your serving telephony exchange. In your case, I'm guessing that Preston is the fibre head-end exchange. (I suspect that kitz will be able to say, for sure . . .)
Between the PCP and its "fibre twin" cabinet, there exist a pair of "tie cables". Each cable contains a pair for every VDSL2 service. When your service was deployed, an engineer attended the PCP and removed the link between the E- and D-side cables for your line. Your E-side pair was then extended across to the "fibre twin" cabinet via the E-side tie-cable. It then passes through a low-pass filter and onto a line card port of the DSLAM. That same point is also connected to a pair in the D-side tie-cable, which takes it back to the PCP. That pair was then connected to your D-side pair, which then feeds both the telephony and broadband signal to your home.
Hopefully that makes some sense. :)
Sent from my iPad using Tapatalk
Post by: 8062282 on September 29, 2019, 05:10:13 PM
I have another dilemma in that something happened at 11.08am which is creating millions of errors. The two downward spikes are me trying to break the connection by changing from 5ghz to 2.4ghz & changing channels without having to re-boot the modem. It didn't work. Due to my DSL disconnect this morning, I'm loathe to re-boot the modem & upset the DLM. Odd thing is, there's no real impact anywhere else. The 1400 US ES was caused by un-plugging the DSL cable. No idea why it does this..
Average error rates for 29 Sep 2019
CRC erors per hour: 2.12 Down, 1.18 Up
FEC erors per hour: 4275911 Down, 3.13 Up
HEC erors per hour: 40.8 Down, 0 Up
ES per hour: 1.47 Down, 83.9 Up
SES per hour: 0.83 Down, 0.24 Up
Total ES in the day: 25 Down, 1422 Up
My question is. Do I leave it in the hope it sorts itself out or do I re-boot the modem?
Post by: burakkucat on September 29, 2019, 07:09:08 PM
The ones to consider are the CRCs, they are "hard" errors.
Post by: 8062282 on September 29, 2019, 07:13:32 PM
Post by: Weaver on September 30, 2019, 12:17:40 AM
The terms are being completely inappropriately used; forward error correction is just mathematical error correction by recalculation and a cyclic reduncancy code/check is the mathematical method used or an appended result code produced by a calculation applied to the data. There is no success or failure inherent in the definitions of these terms and such a mention is essential here. Broadcom eg al have been using these inappropriate shorthand labels for so long that we have got used to them.
Post by: burakkucat on September 30, 2019, 01:50:38 AM
‘FEC errors’ are errors detected and successfully corrected by the mathematics; ‘CRC errors’ are errors that could not be corrected ? Is that right ?
Yes but no but yes . . . I'll point you to a good page (https://kitz.co.uk/adsl/error_correction.htm), on a web-site that I know, which will explain it far better than I am able to do.
Post by: Weaver on September 30, 2019, 02:58:01 AM
Post by: 8062282 on October 01, 2019, 08:27:05 PM
Thanks for the responses. The DLM has banded me at 34,999. Everything was fine at 39mb. Low error count & then bam, DLM kicked in & took the interleaving off completely. Errors galore. Re-synced the following morning & the speed hasn't budged from 34,999. BT tell me I'm now banded at 34,999. Why would the DLM go from one extreme to the other? It also pains me that they can cap your service at 40/10 & you're expected to pay the same as somebody on 55/10. Why don't they just start everybody off at 55/10? If you're line ever gets better, you'll never get a speed increase because you're capped.
Post by: kitz on October 02, 2019, 12:17:05 AM
It does seem a bit odd though that it went straight to banding from non interleave :(
I wish I could give you some further advice re the REIN or SHINE issue, but because by nature it is so hard to track down I don't think there really is that much more I can say about it other than what is on the REIN page. The best thing you can do is what you are proposing and make sure its not something in your own premises.
Post by: kitz on October 02, 2019, 12:41:35 AM
I'd looked at and commented that the same bitload shape was there when on adsl which is a slightly surprising as vdsl and adsl use different PSD masks.
I'd waffled on a bit that Openreach uses something called dynamic spectral masks/management (DSM) for FTTC which are a sophisticated and more advanced way of controlling crosstalk between adsl & vdsl than the bog standard power cut back.... meaning even less likely that the shape would be from masks because they change depending upon.
1) How far your cab is from the exchange
2) How far you are from the cab
Sorry I mustn't have hit send properly. :( :( I know I was struggling to type as my hands are badly swollen and I cut the end bit short after saying about how DSM adjusts on the fly also depending on local cross talk so you can even get different masks and power output the next time you sync and I was trying to decide just how much _real_ bandwidth that dip was costing you and never got around to looking up your headend exchange.
I think I may have said something like
That same bitload shape is there despite vdsl masks being over extended tones. In some respects the loss is less (percentage wise) with vdsl than adsl because vdsl has far more bit loading bins.. plus because PCB is harsher on FTTC on what are considered some of the adsl tones, then usually you lose less because those bins would never fully load anyhow even if the line was perfect. and I was guestimating a couple of Mb at most and said it would likely to be less than what the interleaving was.
Post by: kitz on October 02, 2019, 01:01:06 AM
Quote
Parent
LCBAB Bamber Bridge Mounsey Road
Bamber Bridge
Preston
LANCASHIRE
PR5 6LT
Child
LCBAB Bamber Bridge
LCHOG Hoghton
Post by: 8062282 on October 02, 2019, 07:07:30 AM
2) How far you are from the cab
Sorry you're not well. I appreciate all the help that you & others are giving me. I just wish I knew more about all this network malarky. I think I'm about 2km from the exchange & according to the OR engineer I'm about 300m from the cabinet. I've had a whinge to BT as I think the DLM was wrong in that it's just taken interleaving off in one foul swoop instead of at least halving it & then going from there. Will the banding ever come off or is that on for good now?
The DLM went to a interleave of 1 from 743. It re-synched again at 34,995. I unplugged the DSL cable for about 20 secs before I went to bed due to those millions of FECs (that was a week later though). I was worried it was going to create other errors during the night. The speed went up to 34,999 & that's where it's banded me at.
Post by: kitz on October 02, 2019, 01:36:27 PM
vdsl DSM tries to give some protection for adsl, therefore if your cab is some distance from the exchange, it assumes (correctly) that any neighbouring lines on adsl will have a long length of copper, so it tries to protect and cut back tones most likely to be in use by the adsl users slightly more harshly than it would for any fttc users who are on a cab closer to the exchange. Also if you live nearer the cab (irrespective of cab distance from exchange) then it will cut back power a little bit more than it does for those that live further away from the cab. There's many different masks it can choose from PLUS it also tries to take into account any obvious signs of crosstalk that it would be impossible to say which DSM mask you had applied.
What was apparent when comparing your adsl bit load to your vdsl bit load is that it had the same shape with very little (or no bits) loaded in exactly the same tones... thus I concluded that it wasn't just PSD masking but also some external noise which was lowering bit load over those tones.
I can't recall the tone numbers now, but on vdsl there were some with zero which you perhaps would not expect for a line 300m from the cab irrespective of how far the cab is from the exchange. I'm also ~300m from my cab and I have circa 10 bit load in tones in the same region.
Everything appears to be pointing to the fact that noise is causing the issues for you and its followed you from adsl > vdsl. Your physical line health (condition of the copper) appears to be good because the hlog is good, so Openreach doing a L&S is unlikely to make any difference.
Whilst noise at those tones will impact your bandwidth availability less on vdsl than on adsl.. unfortunately the fttc DLM can be harsher than the one used by BTw for adsl.. therefore when your line is interleaved it can make quite a difference to what speed you sync at. :(
Post by: 8062282 on October 03, 2019, 07:49:51 PM
Post by: kitz on October 05, 2019, 12:02:30 AM
Quote
I still can't understand why the DLM would take interleaving off altogether
New connections are put on Interleaving by default.
If your line MTBE drops to ILQ green, then DLM removes interleaving (can't recall exactly how many err secs that converts to but its on the main site).
Quote
at the same time increase my speed to 39mb+
As mentioned in previous posts - interleaving and error correction carries overheads, these cost you some line speed. When interleaving is removed most lines will see a decent increase in their sync speed.
Quote
& drop the SNR 4.8
That is nothing to do with DLM. The ECI cabs have a target SNRM of 6.3 dB and nothing less than that - only the Huawei cabs have 'x'dB. Therefore the 4.8dB must be attributable to noise on the line or one of your crosstalkers coming on line.
I suspect your line sync'd during a good period, but as the interference kicked in, this will be what caused your SNRM to decrease.
Quote
The L & S was done when I was on copper
It's my understanding that the term lift can be used to cover various scenarios... but usually it is assigning you a new port at the exchange using the same copper run. Line pair change is the term for changing the copper. I've had a couple of what I'd deem line pair changes when I've had a fault in the past, yet I've seen on the report when it was swapped to a new pair at the UG JB right outside my house being reported back to the ISP as a L&S... so who knows what they really changed on yours unless you saw what they did.:/
Quote
Can anything be done?
They could try a pair swap and hope you get an understanding engineer. Your ammunition will be your DSLstats graphs showing the decreases and increases in SNRM. You need to have a few days worth of SNRM graphs to show him so he can see the varience. The varios Errors graphs will also be useful to show.
Quote
They flatly refuse to un-band me unless I agree to an engineer & accept the charges.
They 'should' be able to request a remote DLM reset at no cost to them. It's not an automated process so not all ISPs like doing them. As far as the engineer and charges, then that is a risk only you can decide on.
I took the risk, the engineer came out and did a pair change swap and wasn't charged..... BUT I was told I'd been put on the last available pair which was only in slightly better physical condition than the one they changed it from despite the fact it sync'd at about 2Mb lower.
I was told that as it was the final spare pair, then he wanted me to see how it ran for a couple of weeks and if the problem was still there, then Openreach would need to pull a whole new length of cable through which was something he couldn't do. Sounded reasonable so I said OK. Two weeks later I re-reported it and was told nothing more could be done and that I was above the min threshold. I feel I was a bit fobbed off by the attending engineer and have ended up with a line that syncs less than the old one... however this one does have slightly less errors when my daily error burst starts... so I guess as far as Openreach is concerned then it is the better line.
BlackSheep kindly checked the Openreach reports for me and couldn't see any mention of the pulling a new line to my premises, so perhaps I was fobbed off just to close the job, but he said he didn't think I'd get any further. :/
Post by: Black Sheep on October 05, 2019, 11:06:27 AM
It's a juggling act for sure. ;) ;D
Post by: 8062282 on October 06, 2019, 08:30:14 AM
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 8539 Kbps, Downstream rate = 47701 Kbps
Bearer: 0, Upstream rate = 8028 Kbps, Downstream rate = 34999 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): 8.1 6.1
Attn(dB): 19.9 0.0
Pwr(dBm): 12.7 5.8
VDSL2 framing
Bearer 0
MSGc: 18 25
B: 57 238
M: 1 1
T: 62 52
R: 16 16
S: 0.0527 0.9466
L: 11232 2155
D: 613 1
I: 74 255
N: 74 255
Counters
Bearer 0
OHF: 228149293 636580
OHFErr: 1190 277
RS: 3780988062 1435497
RSCorr: 2751357 11195
RSUnCorr: 26647 0
Bearer 0
HEC: 8195 0
OCD: 2 0
LCD: 2 0
Total Cells: 3421769341 0
Data Cells: 290272971 0
Drop Cells: 0
Bit Errors: 0 0
ES: 86 1645
SES: 2 4
UAS: 30 280091
AS: 561482
Bearer 0
INP: 3.00 0.00
INPRein: 0.00 0.00
delay: 8 0
PER: 2.46 12.35
OR: 78.03 20.07
AgR: 35076.81 8047.70
Bitswap: 130642/131759 8200/8340
Total time = 6 days 11 hours 58 min 32 sec
FEC: 2751357 11195
CRC: 1190 277
ES: 86 1645
SES: 2 4
UAS: 30 280091
LOS: 0 4
LOF: 0 4
LOM: 0 0
Latest 15 minutes time = 13 min 32 sec
FEC: 916 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: 2200 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 = 11 hours 58 min 32 sec
FEC: 246437 682
CRC: 8 15
ES: 2 14
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 431341 4984
CRC: 37 41
ES: 9 34
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 6 days 11 hours 58 min 1 sec
FEC: 2751357 11195
CRC: 1190 277
ES: 86 1645
SES: 2 4
UAS: 0 280061
LOS: 0 4
LOF: 0 4
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
I haven't spoken to the BT MOD since last weekend as I wanted to collate a weeks worth of stats to indicate why I don't think my line should have been banded. When the SNR dropped to 4.8dB that coincided with the interleave coming off & the speed increasing. Probably the increase of X-Talk/Interference pushed it down, as you said Kitz. The missing tones have almost filled in at the beginning but I'm still missing tones from 250 - 290
Since midnight, apart from FECs, there hasn't been any errors on the DS at all. What causes US errors? Are they something the DLM takes into account?
Average error rates for 06 Oct 2019
CRC erors per hour: 0 Down, 1.19 Up
FEC erors per hour: 6047 Down, 1.43 Up
HEC erors per hour: 0 Down, 0 Up
ES per hour: 0 Down, 1.07 Up
SES per hour: 0 Down, 0 Up
Total ES in the day: 0 Down, 9 Up
Thanks for all your help. I don't understand a lot of it but it's helping me learn :)
Post by: j0hn on October 06, 2019, 03:00:00 PM
Was DSLStats running as the banding was applied and was there a number of resyncs at or around that time?
edit:
I see it happened here
Hi - Thanks for replies, Kitz & jOhn. The internet dropped connection last night & DSLstats threw a wobbler sometime in the night, When I checked it this morning, it came up with a floating decimal point error & stopped recording. I had to close it & re-start it.
Anyway, the DLM kicked in last night & I'm back to interleaving on at 793 on the DS. SNR is a 6.3dB. Speed has dropped to 34,995 with an attainable of 41,727. My errors prior to DSLstats having a dicky fit were.
Line likely resynced multiple times during that period.
Post by: 8062282 on October 06, 2019, 04:20:42 PM