Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: DeadMan on July 18, 2013, 01:47:27 PM
-
Considering I have only been re-synced for less than a day I guess this might be a bit premature. I am asking someone on TB about this US SNR fluctuation issue but having to wait for the DLM to decide when it wants to up my sync rate and turn off interleave is a joke! Based on this short period, is my line showing too much noise at present for DLM to remove the choke?
P.S. can someone teach me how to interpret the errors so I know what is good and what is bad (How high or low should FEC, HEC, RSCorr be for instance over a period of time?)? That way I would not have to keep asking for help so often.
-
FTTC DLM decides how to stabilise your circuit every day in the wee small hours. If you have had a lot of 'noise' or high error count, then it will take the appropriate action.
DLM is a topic all of it's own, I'm just answering the subject header. Others will be along I'm sure, to give their thoughts on error counts ? :)
PS ..... welcome to the forum, bud.
-
I can't imagine you will be on FastPath or soon looking at those.
It appears you have some form of Interference, it looks like Electrical Interference to me but could be REIN.
You can see it on SNR graph at various points when the Interference starts, the interference could also be the reason why FEC count is high. Though it isn't the worst but also isn't the best, I've seen a lot worse!
Interleaving itself will reduce your bandwidth, I want to say it can be anything up to 20% as now needs to deal with the errors. If you fix Interference the rest should fall in to place, that is if you can track the source down.
A low amount of FEC errors are 50 - 1000 per minute. 1000 - 5000 I would consider to be above normal but in reality it's really nothing to worry about. High is anything above that per minute, you can see anything up to 1.2 Million errors per minute. This record is mine, I suffer from serve Electrical Interference and on top of that some REIN as well!
If you look at FEC and CRC error graphs, you have Interleaving and FEC enabled. If you're getting CRC errors whilst FEC is enabled, it is due to the MSAN not being able to handle the burst (possible SHINE, but your line looks clear of SHINE) and instead of FEC errors it had to force a CRC error instead.
-
Thanks. My ISP are going to book an engineer. Not sure if it will help much (the US SNRM going up and down like that is odd. I hope he can find something causing it as I have tried all the usual things my end like turning off all electrical appliances and connecting to the master test sock with a RJ11 to BT cable).
Big problem is if the engineer does his testing whilst the US SNRM is in one of the 'good' periods he may find nothing. Ideally he should be here when it's in the low spells but I bet he won't be (he may still find nothing wrong though. I read that it sometimes requires a broadband specialist to visit to diagnose other issues like REIN).
-
That is correct, your normal Broadband engineer will simply run a line test. Couple of minutes later he will have the data back and see if it failed any tests, they will not investigate REIN issues. You would need to convince your ISP to send a REIN engineer though the wait is a bit longer your Broadband engineer due to lack of people trained to diagnose REIN. He will check in your house for REIN, if he doesn't find anything there he will then drive between you and the MSAN trying to detect REIN with his kit.
Can you post your Telnet stats as well please!
-
Based on the above graphs with the weird US SNRM and errors reported do you think it's worth trying to get them to investigate? Or am I likely to get brickwalled as my connection is 'good enough' in their eyes.
Which xdslcmd ?
-
It really depends, if you are happy with your connection and you can do everything you wanted, then no I wouldn't bother.
If it was me though I believe they should provide their estimates, or at least within a couple of Mbps as they state on their website. I would get it investigated if it was me but if your happy with your connection and you don't really care then no.
-
Is this the telnet info you wanted?
# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 19705 Kbps, Downstream rate = 7290
Path: 0, Upstream rate = 16398 Kbps, Downstream rate = 6
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.2 5.8
Attn(dB): 0.0 0.0
Pwr(dBm): 13.4 6.8
VDSL2 framing
Path 0
B: 41 47
M: 1 1
T: 64 64
R: 10 16
S: 0.0216 0.0931
L: 19299 5500
D: 1497 345
I: 52 64
N: 52 64
Counters
Path 0
OHF: 52076102 1050409
OHFErr: 281 1
RS: 3779267622 3516077
RSCorr: 1023720 79261
RSUnCorr: 24129 0
Path 0
HEC: 4647 0
OCD: 116 0
LCD: 116 0
Total Cells: 2157017261 0
Data Cells: 25990586 0
Drop Cells: 0
Bit Errors: 0 0
ES: 553 7
SES: 19 0
UAS: 117 117
AS: 90144
Path 0
INP: 3.00 4.00
PER: 1.72 5.95
delay: 8.00 8.00
OR: 115.97 37.59
Bitswap: 12592 3492
Total time = 1 days 4 hours 9 min 53 sec
FEC: 32311346 1694976
CRC: 11890 61
ES: 553 7
SES: 19 0
UAS: 117 117
LOS: 3 0
LOF: 15 0
Latest 15 minutes time = 9 min 53 sec
FEC: 4132 18
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 8244 1467
CRC: 7 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 4 hours 9 min 53 sec
FEC: 217304 17912
CRC: 129 0
ES: 24 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 1198783 162240
CRC: 10795 56
ES: 72 4
SES: 19 0
UAS: 97 97
LOS: 3 0
LOF: 15 0
Since Link time = 1 days 1 hours 2 min 23 sec
FEC: 1023720 79261
CRC: 281 1
ES: 57 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
-
Indeed it is!
INP: 3.00 4.00
DS US
INP is protection, higher the value the more protection against noise/errors. 4 is concerning, especially since it's active on your Upload. It's the first time I've actually seen this, you have a serious form a of REIN or EI I would imagine. Talk to your ISP, provide the Information, though they should have access and request a REIN engineer. You also have a 8 delay on your upload, this will be due to the implementation of INP being active on your line. Interleave is also applied on the US as well though this is probably due to INP being active again but just confirms you have problem with US snr.
Has there been any works between you and the MSAN recently?
Also can you post the pbParams as well please if you have them!
Also, I'm assuming this was a fail copy and paste part?
Path: 0, Upstream rate = 16398 Kbps, Downstream rate = 6
-
Whoa. Lets just slow this down a mo. :)
The INP could have been applied because of a MPF fault, or non-filtering of devices, or excessive star-wiring blah de blah. Lets see what the engineers PQT test show first before we start requesting a REIN engineer.
PS ........ for info, an ISP can't request a REIN engineer, they can only request that the broadband engineer test for REIN. Seeing as most are not REIN trained, this is highly unlikely. However, if the engineer is adamant that it is REIN, by way of looking for 'trends' and other historical data, plus co-op'ing with the ISP's tier 2 tech guys, then only he/she can request a REIN task be built. :)
-
If it was star wiring the SNR wouldn't change all of a sudden. You can easily tell it's REIN or EI. I was wondering about the REIN engineer.
-
If an unfiltered phone was plugged in to a star-wired extention, the SNR would likely move when the phone was used. My point was that it could be anything causing the problem, and anybody perusing this thread may instantly jump to the wrong conclusion that it has to be a REIN issue !
A full circuit 'Health check' must be undertaken, before conclusions can be drawn. :)
-
As requested. Also yes the previous copy and paste missed a few digits off upstream.
# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 19649 Kbps, Downstream rate = 72908 Kbps
Path: 0, Upstream rate = 16398 Kbps, Downstream rate = 61992 Kbps
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 19649 kbps 72908 kbps
Actual Aggregate Tx Power: 6.8 dBm 13.4 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 4.4 23.9 36.6 N/A 11.9 29.6 45.6
Signal Attenuation(dB): 4.4 22.9 35.5 N/A 11.9 29.6 45.6
SNR Margin(dB): 5.6 5.8 5.8 N/A 6.2 6.2 6.2
TX Power(dBm): -3.8 -19.3 6.4 N/A 10.4 7.8 7.0
#
-
# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 19649 Kbps, Downstream rate = 73136 Kbps
Path: 0, Upstream rate = 16398 Kbps, Downstream rate = 61992 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.3 5.8
Attn(dB): 0.0 0.0
Pwr(dBm): 13.4 6.8
VDSL2 framing
Path 0
B: 41 47
M: 1 1
T: 64 64
R: 10 16
S: 0.0216 0.0931
L: 19299 5500
D: 1497 345
I: 52 64
N: 52 64
Counters
Path 0
OHF: 56523363 2343045
OHFErr: 305 1
RS: 907423942 3669011
RSCorr: 1124826 85777
RSUnCorr: 25553 0
Path 0
HEC: 4877 0
OCD: 121 0
LCD: 121 0
Total Cells: 3074801918 0
Data Cells: 29299079 0
Drop Cells: 0
Bit Errors: 0 0
ES: 560 7
SES: 19 0
UAS: 117 117
AS: 97843
Path 0
INP: 3.00 4.00
PER: 1.72 5.95
delay: 8.00 8.00
OR: 115.97 37.59
Bitswap: 14383 3789
Total time = 1 days 6 hours 18 min 12 sec
FEC: 32412452 1701492
CRC: 11914 61
ES: 560 7
SES: 19 0
UAS: 117 117
LOS: 3 0
LOF: 15 0
Latest 15 minutes time = 3 min 12 sec
FEC: 1703 6
CRC: 4 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 8931 1101
CRC: 8 0
ES: 2 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 6 hours 18 min 12 sec
FEC: 318410 24428
CRC: 153 0
ES: 31 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 1198783 162240
CRC: 10795 56
ES: 72 4
SES: 19 0
UAS: 97 97
LOS: 3 0
LOF: 15 0
Since Link time = 1 days 3 hours 10 min 43 sec
FEC: 1124826 85777
CRC: 305 1
ES: 64 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
#
-
If an unfiltered phone was plugged in to a star-wired extention, the SNR would likely move when the phone was used. My point was that it could be anything causing the problem, and anybody perusing this thread may instantly jump to the wrong conclusion that it has to be a REIN issue !
A full circuit 'Health check' must be undertaken, before conclusions can be drawn. :)
I'd agree with Black Sheep, but I have also noticed a couple of things from data posted in this thread and the one in the TBB forum.
Looking at your snapshot graphs, your Hlog graph doesn't immediately jump out as reporting any bridged taps that tend to negatively affect sync speeds.
It is a little 'wavy' in the D3 band, but I don't think it's sufficient to be concerned about.
Although being connected to a Huawei DSLAM, we unfortunately can't see any upstream data in the Hlog, QLN & SNR graphs.
Upstream data is 'sometimes' reported when using a HG612 connected to an ECI DSLAM.
There is a small dip in the bitloading graph for the upstream U2 band that could indicate a slight issue though.
Your DS_OHF & US_OHF graphs look a little unusual.
Those spikes tend to be due to the harvesting program (HG612_stats.exe) taking longer than usual to harvest the data & calculate any differences from one minute to the next.
I have attached an example from my connection showing really steady DS_OHF data, apart from when my daily virus scan & virus definitions update kick in, more or less hogging all the PC's resources for a while.
When that happens, it can take much, much longer than the usual couple of seconds to harvest/calculate data before writing it to modem_stats.log.
So what spec is your PC & do you have a resource hungry program or programs running 24/7?
Take a look at maybe one hour's worth of data in the ERROR.LOG file (stored in the Ongoing_Stats folder)
Each minute's harvesting/logging event shouldn't take more than 3 seconds as an absolute maximum.
If the PC's spec is reasonable, no resource hungry programs are running & yet it still takes a long time for the harvesting etc, that may be some sort of a clue as to the cause (I don't know what it would point to though (yet)).
It does seem very strange that SNRM is affected to more or less the same extent in each of the 3 completely separated US frequency bands, yet the issue isn't there at all in the DS frequency bands that lie between the US bands (see the separate DS & US SNRM graphs near the bottom of your FULL_MONTY montage).
@ BS,
Have you seen any similar issues where only US SNRM is affected on a VDSL2 connection & if so, was it diagnosed as line fault?
How close is the modem to the PC?
The PC itself, its monitor, router/modem power adapters etc. etc. could actually be the cause of the interference that results in lowered US SNRM.
How close is the modem to any other electrical equipment and/or mains power cables/sockets & how close is it to the master socket.
Does any of the timings coincide with switching lights on/off?
I believe LED or flourescent lights can occasionally cause problems.
I see that you are currently running the connection via a dangly ADSL filter plugged into the master test socket, yet the issue is still present.
I suppose that means that unless something else is wired from the wrong part of the master socket, we can rule out any other internal telephone wiring issues.
You did completely remove the whole faceplate to get to the main test socket didn't you?
EDIT:
One other thought........
Is your modem's power adapter plugged directly into a mains socket or an extension lead, possibly including some sort of surge protection?
-
Task takes no more than 1-2 seconds according to error log.
Modem is away from PC and monitor about 5 feet from HP LP2475w IPS LCD and 6-7 feet from PC. Can test on a laptop from another room with PC etc completely off if required. Interstitial plate is off and plugged directly into master test socket. Specs of PC Intel E7600 core2duo, 8GB DDR2, Asus PQ5 Deluxe mobo, Enermax 530w PSU, various hard disks and peripherals including a USB DJ controller and two Logitech webcams., BT Converse 1300 phone, 3COM US Robotics 56K Professional Modem (for software answerphone), D-Link DIR655 Router with wireless on. I will try a complete stripdown to wireless laptop but wil be near impossible to turn off wireless to test. Will need to be during a period when US SNRM is in the low noisy phase.
Modem PSU is plugged into extension yes. Not surge protected. Was on a surge strip but moved it. Can try both but this would mean disconnecting modem which risks more DLM.
Lights are ruled out. So is fridge. Microwave. Boiler is off but fan is always running. Would be a pain to switch it fully off though as it's a bugger to get started again.
Oh and I have been around the house with a AM radio at 80 x10Khz (I think this is 800?). HP LCD makes a lot of noise if held close but when I powered it off it did not seem to have any effect on stats. Panasonic Plasma puts out MASSES of noise when on. But has no effect on line because it's off most of the day otherwise I would see a big spike when it is on.
EDIT: I hardwired the laptop to the modem port 2 and monitored the US SNRM (at it's low ebb) then turned everything off in the house I could think of excepting the modem itself. All lights were off. Turned my mobile phone off. Short of turning the mains switch off in the cupboard (no idea which one is connected to the loop the modem is attached to). I could not turn anything else off (well the boiler of course but as I said I don't think that is an issue as I have been with the AM radio all around that and no noise coming from it that I can tell)!
US SNRM did not budge. It has to be external.
Attached is graphs during the period I had nearly everything in the house turned off including the PC, router and all peripherals.
-
There is something weird going on with the data-harvesting. Every fifth minute a record is missing . . . :-\
-
There is something weird going on with the data-harvesting. Every fifth minute a record is missing . . . :-\
That's just the way the tics, grid and labels along the x axis are split up for shorter periods.
Plotting only 30 minutes worth of data from my own connection looks similar along the axis, but the data itself is still plotted.
I may get round to tweaking the graphing program at some stage, but it's not actually a priority at this time.
-
Anyone want to explain some of what I should be looking at to tell if there is a problem? I can see the US SNRM margin going up and down but everything else I am in the dark. The basics would be nice. Thanks!
-
There is an explanation of what the stats mean here:-
http://www.kitz.co.uk/adsl/linestats_explanation.htm
That page does contain links to further explanations.
The details are for ADSL connections but many of them are still relevant for VDSL2 (FTTC) connections.
ADSL connections use Super Frames (SF) The VDSL2 equivalent is OverHead Frames (OHF).
WWWombat over on the TBB forum has provided quite a detailed explanation for some of the other stats, particularly related to Interleaving.
Regarding SNRM, the target at sync time is 6 dB for VDSL2 connections, to allow for sufficient downward fluctuation during 'noisy' periods, usually in the evenings & lasting until daylight hours.
Some connections fluctuate quite a lot & some only fluctuate by very small amounts.
Resyncing whenever SNRM is at its peak usually delivers higher sync speeds, at the expense of seeing more errors that can actually slow down throughput etc.
Some connections have very high SNRM levels.
This is either because DLM has taken action following a burst or bursts of errors & has capped/banded sync speeds at a lower level.
When this is the case, attainable rates are usually much higher than sync speed.
Another scenario for high SNRM levels could be a connection with a short D-side but the user has opted for a 40 Mb service.
Attainable rates could be much higher (say up to 125 Mb, but as the connection is capped at 40Mb, SNRM could be as high as 30 dB or so, showing plenty of margin for speed increase if the user chose to move to an 80 Mb service.
Basically, an ideal connection would have spare SNRM, be on fastpath (D: value as shown in the raw data stats of 1) & with very few error counts.
FEC/RSCorr errors kick in when Interleaving is applied, improving stability & INP (Impulse Noise Protection) at the expense of some sync speed.
DLM fully controls this aspect, based upon continual connection monitoring & making adjustments whenever it deems it to be necessary.
Unlike ADSL connections, at the moment, ISPs have no control whatsover over Interleaving levels & cannot adjust SNRM levels.
As my connection could happily run with SNRM as low as say 3 dB (it hardly fluctuates at all - even overnight), I could achieve higher sync speeds if the target was lowered.
Bursts of massively increased errors (whether random or with a timed pattern) tend to suggest a REIN issue, but could just as well be caused by an intermittent line fault such as a corroded cable joint etc.
My connection experienced that issue from a poor underground cable to pole monted DP (Distribution Point) joint.
As the weather became hotter & dryer, the error counts would shoot through the roof & the connection would randomly & frequently resync.
DLM didn't like that & would regularly cap/band my connection at very low sync speeds in order to attempt to provide some stability (as low as 8 Mb for a while).
Permanent 'noise' increase (as portrayed via the QLN graph (Quiet Line Noise), tends to suggest increased croosstalk from other users' connections, possibly due to naturally induced interference from other cables within a D-side bundle or more rarely, due to cable damage/water ingress.
I hope that helps somewhat, but please feel free to ask specific questions - we may be able to answer them between us.
-
most isps use the standard DLM profile (the middle one). I dont know what the exact thresholds are but my gut guess is you have too much FEC for the DLM to consdier it worthy of reinstating fast path.
My line under normal conditions is considered stable by DLM. I had a few occasions where I was getting weird bursts of noise during the night between 1 and 3am. This would trigger a DLM profike change as it generated 10s of thousands of errors in very quick time.
Since these were one off events not 24/7 I had quite fast DLM recovery. The first time this happened the line recovered to fast path within a few days, I was getting maybe a few hundred FEC or so a day if I remember right and no crc errors at all, I think I got 1 crc error the 3rd day or something.
The most recent time I was on interleaving before my fault got fixed, DLM was slower at recovering, I plugged in a fritzbox 3370, and the error count went to extreme low levels to the point I was also getting almost 0 FEC. Needless to say that triggered a very fast recovery to fast path. Your FEC counts are way higher than what I had by all means not extreme but not in the same league as what I had, and you still getting 10k crc errors a day whilst interleaved, so sorry to say my gut guess is you on interleaved for the forseeable future. Unless you can resolve the cause of those errors. To give you an idea, me on fast path now I am averaging under 1/20th of the CRC errors you are getting whilst interleaved.
My error rate has risen tho which is some concern for if my line will be fast path forever, hopefully vectoring comes before that happens. I was only 2 months or so ago averaging under 300 a day. Especially my US error stats which now seem about 1/3 of my DS.
Previous 1 day time = 24 hours 0 sec
FEC: 0 0
CRC: 665 0
ES: 276 182
SES: 1 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Since Link time = 49 days 17 hours 2 min 46 sec
FEC: 0 0
CRC: 64902 21904
ES: 26942 19501
SES: 38 141
UAS: 0 0
LOS: 0 0
LOF: 0 0
Also if errors come in bursts thats a bad thing for DLM, if they slow an steady stream throughout the day thats better. So eg. my 15 min stats.
Latest 15 minutes time = 5 min 0 sec
FEC: 0 0
CRC: 1 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 2 0
ES: 1 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
I currently have a margin on both directions.
Max: Upstream rate = 27437 Kbps, Downstream rate = 72536 Kbps
Path: 0, Upstream rate = 20000 Kbps, Downstream rate = 66387 Kbps
I didnt resync when the downstream attainable increased instead deciding to keep the extra snrm as a buffer, plus knowing my luck if @i did take advantage of it then it would revert although when I start tests next month using new CPE issued to me my sync will be reset then anyway.
-
Well the last time the DLM reduced my profile in June it took exactly 2 weeks to get back to normal I think the Noise was a one of occurrence, but if the noise is consistent then I can't see the DLM increasing the profile until the engineers find out what is causing the noise/errors.
The first thing I do is start looking at ongoing stats and then fire up the Multi Band Receiver and tune it to 586KHZ, My old Sony FreeView Box (2006) is causing a hell of a mess of interference up to 4 meters from receiver and Modem & Router sit inch's away from freeview box, so I turn off the freeview box now at the plug (time for a new FreeView set top box) ;)
-
I've been investigating a bit. The faceplate makes no difference so I put that back on and also my phone. They are not the cause that I can see. Secondly I put a high quality ADSL Nation 1 meter RJ11 cable between the modem and the faceplate. A marginal improvement in overall SNRM but not enough to brag about. The SNRM still dips. It's Sunday and the 1.5dB SNRM dips still occur.
I went around with a cheapo old AM handset to see what I could hear. Unfortunately it's not digital so it was mainly guesswork on the frequency. Also a local Asian radio station broadcasts around that frequency.
Following the line out the window from the master socket going to a bunch of cable tied cables. Some are coax (probably satellite etc). The phoneline is on a balcony that goes onto the accountants/car repair side (the car place is under the accountants) into a big black box between the accountants and the next premises. We are all terraced. I have been that side before so know about the black box but did not go over there today with the radio because the accountants windows were not blinded so I did not want to risk being accused of trespassing on their property.
What I did find out though is by going outside with the radio everything became crystal clear as soon as I stepped away from my premises. If I went back the Asian radio station when slightly detuned closer to the frequency mentioned would get completely blotted out by noise.
I don't think the SNRM issue is being caused by the garage as they were closed (unless they have something that goes on and off at various times of the day). It could be the hairdressers to the other side of me but seems unlikely as the line goes the opposite direction to them. My biggest suspect is the premises next to the accountants. Reason being the times of the SNRM drops are usually in the afternoon to very late at night. The premises to the accountants/car place? A Chinese take away.
Of course it could be much further down the line. I don't know where my line goes. I think it might got to a small green cab down the road but from where that goes to the FTCC cab I have no idea. I will have to walk that stretch and have a look around.
One other thing of note is I do have an alarm system and an intercom system for the communal door (I live in rented accomodation). They put out noise but it is constant and I can't see any reason why they would affect SNRM in the pattern I am seeing. Constant noise perhaps. But not the SNRM dips.
Basically my premises and those around me put out loads of noise so it could be anything.
-
I don't think the SNRM issue is being caused by the garage as they were closed (unless they have something that goes on and off at various times of the day). It could be the hairdressers to the other side of me but seems unlikely as the line goes the opposite direction to them. My biggest suspect is the premises next to the accountants. Reason being the times of the SNRM drops are usually in the afternoon to very late at night. The premises to the accountants/car place? A Chinese restaurant.
Ah. It seems like you have found the source.
It'll be the industrial sized cat/dog microwave oven. :lol: :lol:
The longer periods of interference will be due to the cats - remember they have 9 lives, so it takes a bit longer before they become edible.
-
I called PN to see if they would remove me from banding and to update me on when BT is due to visit. No good on either at present. They won't remove me from banding until the engineer visit and they don't know when that will be yet. One thing I remember from a previous visit was the engineer mentioning I was on the small green cab down the road which goes onto where I don't know. I went for a walk that way and could not see any large fibre cabs. I have a fibre cab literally around the corner on the other side. But I reckon I am not attached to that one. I wonder if they can get me a new pair that goes to that cab. I will ask the engineer about it when they visit.
-
From what I have gleaned from similar queries from myself & others, ISPs have no direct control over banding, whether it is banding to a service profile such as 40 Mb / 80 Mb or other banding at lower levels.
ISPs have to request a service profile band via an order to BT & any banding below the service speeds is automatically initiated by DLM.
On an engineer's request (during or following a home visit) DLM can be reset /re-calculated by BT to a wide open profile within a given service, but this cannot be done directly by an ISP.
It is then again left for DLM to monitor connections & make adjustments accordingly to suit conditions.
When conditions worsen, DLM appears to take action quickly, but it does appear to take a very long timer for DLM to acknowledge when coditions have improved.
If you enter your phone No. here, it should confirm the number of the cabinet that you are currently connected to:-
https://www.dslchecker.bt.com/
Most cabinets have their number stenciled on, so you may be able to see which is which.
I have also been told that it is very, very unlikely that users can have their connections rerouted to an alternative cabinet, but it wouldn't do any harm to ask the engineer.
-
It's a dead certainty that the EU will NOT be re-routed to another PCP. We have been specifically told, not to engage in the process. Just for info guys. :)
-
It's a dead certainty that the EU will NOT be re-routed to another PCP. We have been specifically told, not to engage in the process. Just for info guys. :)
That make absolute sense. (b*cat thinks about the utter pandemonium and chaos that could occur if such a process was allowed . . . )
-
Not just the pandemonium of 'Routing & Records', but the very real issue of 'Where do we draw the line ??'. As some of us are aware, Mr BE resides on the very outskirts of his serving Exchange, and his immediate neighbours are fed via another closer Exchange. You can imagine the flood of requests that would follow, should we 'move' BE to the other Exchange ??
-
Indeed. That is exactly the sort of situation I was thinking about. :angel:
-
Not just the pandemonium of 'Routing & Records', but the very real issue of 'Where do we draw the line ??'. As some of us are aware, Mr BE resides on the very outskirts of his serving Exchange, and his immediate neighbours are fed via another closer Exchange. You can imagine the flood of requests that would follow, should we 'move' BE to the other Exchange ??
The cabinets are available in a variety of sizes, and installation requires the cabinet to be supplied with mains power, as well as ducting to link it to the old cabinet and of course ducting to carry the fibre back to the telephone exchange. In some areas the fibre from a cabinet does not go back to the existing exchange, but a neighbouring exchange. This does not affect the speeds possible, since fibre can run for many kilometres without the signal being affected.
-
The issue is not with the 'Fibre side', it is with the D-side cabling. :)
-
The issue is not with the 'Fibre side', it is with the D-side cabling. :)
the D-side you meen the smaller green Cab (copper wire to home) next to the larger FTTC cab ?
-
Yes. The route from the original Cabinet to the home, is pre-determined and routed over decades old (I know, I know) cables.
So, you could have a situation where Customer A is fed via a telegraph pole (DP) that is over 1.5Km from the original Cabinet. However, Customer B (who lives next door to A), is 'fed' from a completely different DP, that is in turn 'fed' from a completely different Cabinet, that is only 100mtrs away !!
Outcome: Cust A struggles to get a decent VDSL speed, Cust B gets the full 40/80Meg speeds.
HTH. :)
-
Yes. The route from the original Cabinet to the home, is pre-determined and routed over decades old (I know, I know) cables.
So, you could have a situation where Customer A is fed via a telegraph pole (DP) that is over 1.5Km from the original Cabinet. However, Customer B (who lives next door to A), is 'fed' from a completely different DP, that is in turn 'fed' from a completely different Cabinet, that is only 100mtrs away !!
Outcome: Cust A struggles to get a decent VDSL speed, Cust B gets the full 40/80Meg speeds.
HTH. :)
BlackSheep your post makes the D-side issue very understandable (layman's Terms)
Thankyou ;)
-
You are too kind, sir. Thanks. :blush: ;D
-
Not just the pandemonium of 'Routing & Records', but the very real issue of 'Where do we draw the line ??'. As some of us are aware, Mr BE resides on the very outskirts of his serving Exchange, and his immediate neighbours are fed via another closer Exchange. You can imagine the flood of requests that would follow, should we 'move' BE to the other Exchange ??
Nay, nay & thrice nay.
The other exchange may be closer but the closest fibre cab in that direction is more than 2 km from my home!!
-
Not just the pandemonium of 'Routing & Records', but the very real issue of 'Where do we draw the line ??'. As some of us are aware, Mr BE resides on the very outskirts of his serving Exchange, and his immediate neighbours are fed via another closer Exchange. You can imagine the flood of requests that would follow, should we 'move' BE to the other Exchange ??
Nay, nay & thrice nay.
The other exchange may be closer but the closest fibre cab in that direction is more than 2 km from my home!!
eek BE 2 KM that would give you a Max of 11Mbps from the D-side ;)
-
Not just the pandemonium of 'Routing & Records', but the very real issue of 'Where do we draw the line ??'. As some of us are aware, Mr BE resides on the very outskirts of his serving Exchange, and his immediate neighbours are fed via another closer Exchange. You can imagine the flood of requests that would follow, should we 'move' BE to the other Exchange ??
I see both sides of the argument.
BT are basically adopting a hard policy of we wont touch whats in place unless there is a clear fault that falls below our tight failure policies. This policy will likely be in place for cost control, whilst it may have trivial cost to fix some issues it may be somethign that quickly explodes when including more diffilcult cases and especially if applied to large amounts of people.
However we then have the fit for purpose, consumer rights etc. As well as common sense. If BT eg. have half a street served by a close cabinet/exchange with great service and the other half on the outskirts of something 10 miles away, then its basic common sense to reorute the bad half side of the street even without the customers requesting it, just get it done and write off the cost. In my business not all my customers are treated exactly equally but it I had one customer very significantly worse off than another and he queried it, I would rectify the situation, even if at my own cost, it isnt right otherwise. Its pretty crazy eg. I have a close cabinet across the road from me which shares the same ducts as my pole yet BT didnt optimise the D side when rolling out FTTC. Even more baffling is BT spent the time and expense giving me a dedicated drop cable, which gave me a ton of extra attainable sync speed, only to then undo the work on the order of the area manager (apparently engineer did it without permission), reason? BT policy, nothing else. BT basically spent money to apply policy (as it cost them money to undo the work).
Of course even with this policy in place people get inconsistent experiences, occasionally engineers go out of the way to fix things, if its someone important then they get better treatment, eg. a managing director of an isp who had press coverage managed to get a line reroute on top of a pair swap to get rid of his crosstalk. His engineer also swapped out his junction box on top of that. When people read/hear of these reports the will clearly want the same for themselves.
Then I read black sheep searched out a good pair for himself ;) on his own line and think thats nice, do the same for everyone else :) but I know thats not his fault he doesnt decide company policy, and after seeing an engineer who tried to help me get a bollocking from the area manager I know they dont have a free reign.
-
Not just the pandemonium of 'Routing & Records', but the very real issue of 'Where do we draw the line ??'. As some of us are aware, Mr BE resides on the very outskirts of his serving Exchange, and his immediate neighbours are fed via another closer Exchange. You can imagine the flood of requests that would follow, should we 'move' BE to the other Exchange ??
Nay, nay & thrice nay.
The other exchange may be closer but the closest fibre cab in that direction is more than 2 km from my home!!
;) Yes, I'm aware of this BE. I was just trying to present an analogy. ;D ;D
-
Ha ha, Chrysallis. The 'Good Pair' was actually a spare already going to my BT66 (the previous occupier worked from home as an insurance assessor, and had 3 lines), and as such, there has been no line plant rearrangement, only a very simple robotic routing update to perform.
The 'Half a street' analogy wouldn't be an issue, if you weren't having to apply a further 'multiplier' of hundreds of thousands of premises. We have to look at the bigger picture when imposing rules and regs, and you're quite right, we don't have free reign for this very reason. :)
-
You can imagine ... should we 'move' BE to the other Exchange ??
:hmm: I wonder what the effect might be if he could ask for an out-of-area number on that other exchange? :o :D
Strike that it's even further away. Oh no, missus! :lol:
-
Interesting stuff guys. Engineer booked for tomorrow morning. We shall see. Right I am off to search for cabinet 14 ;)
EDIT: Found it! It's 300 meters down the road to the left not the closer cab unfortunately. It's a half sized cab with a full sized FTTC cab on the other side of the road (Not sure how that works). I plan on going along that stretch with my radio and see if there is any obvious noise but I doubt I will find anything useful.
Oh and I was wrong about the Chinese that is the next building along. There is a store that is uninhabited between (not sure what it was because I have been here over 20 years and it was always shuttered). Also premises above it. Knowing my area (Catford) perhaps it's full of spectrum polluting gear used to grow marijuana. ;)
What speed should I be expecting at 300 meters btw?
EDIT2: from Googling that it seems it could be anything between 30-76mbsp hmm.
-
What speed should I be expecting at 300 meters btw?
EDIT2: from Googling that it seems it could be anything between 30-76mbsp hmm.
at least 45Mbps @ 300 meters from Cab, and Just one other thing Rein comes in two flavours External and Internal, find and cure Internal first (Home) only Openreach can cure External Rein ;) you can look very suspect to authorities with a handheld scanner while traceing your D-side ;D
and it may help to use the DSL checker https://www.dslchecker.bt.com/ and compare
-
Well I was syncing around 70/20 before DLM threw a hissy fit. It's knocked me down to 64/16 (real speeds are 57/15) at the moment and that may be what I have to live with on interleave. But it's worth a try to get faster if I can ;)
EDIT: Engineer just visited. Said he can't do anything but change the modem (lol). Did not understand any of the info I threw at him about FEC errors etc. All he said he can do is reset the DLM (after I asked him to) and he had never done that either. In fact he wasn't very knowledgeable at all (the terms monkey and organ grinder come to mind).
Now what?
-
There is a thread elsewhere here on Kitz that discusses, or at least speculates upon, some aspects of the DLM algorithm. If DLM has seen resyncs to be the issue (rather than error rates), then it will view the problem as a primarily one of stability. In those circumstances, 'how long it takes' depends upon whether, having 'temporarily' capped your sync rates at a lower profile, it encounters any further 'instability'. There is some evidence to suggest that 14 days is a basic unit of the time which the algorithm uses. Unfortunately it also uses a 'doubler' effect each time further instability is encountered while already in a capped profile.
So, for example only, a one off lowering of the profile might be lifted in 14 days, but (as happened in my case), if this happened 3 times in a row (as it did), it took closer to 2^(3-1)*14=~56 days to return to 'normal', albeit that it did progressively step up the profiles during that time.
I only mention this to give you some idea of the timescales that could be involved - they can test the EU's patience considerably. HTH
-
As suspected not DLM reset. I bet he did not even try. On the phone right now. Apparently I am on/was a 35 meg banded profile (bit of confusion about that actually as he then said later on it is 60). They are waiting for the engineer notes to come through but he is going to try to get me off the banded profile if he can and look further into what can be done. I explained that the engineer was a bit clueless (probably fresh out of training he seemed young) and would not entertain any of my suggestions like a pair swap etc (I think OR are coming down tough on engineers to do as little as possible. Either that or it was because he was clueless or worse, lazy) The device they use will only give a snapshot of line conditions for those few minutes it is on so I don't really think they are worth a carrot for time based issues.
According to the support guy they can take you off banding profile and put you on fastpath permanently? I thought only the DLM had control of that or does it not? I asked to be set on an unmanaged profile if possible.
Anyhow I now have to wait for the engineers notes to come through to see what the next step is.
-
Still waiting for something to be done. They said they changed my banding which increased speed tests but not sync rate. My interleave is now 600 on upload. I foolishly did a resync earlier today and since then my speed tests are bouncing up and down from 44mbps-57mbps and my attainable rate is fluctuating very slightly where as before it was always mostly a smooth line.
Plusnet asked to do another BTW speed test but it does not tell the entire story. I do not want them coming back to me again with the 'within estimates' excuse. If they say they cannot fix the line then so be it. But at least get someone to reset it all to defaults from my first install so I can start from a fresh baseline to measure from.
-
One thing I forgot to mention is that the master socket is NOT the NTE5 socket. The master socket is a very old smaller faceplate/box that runs a worn looking cable going out a hole drilled into the window pane. The NTE5 box is directly above it so I presume the cabling inside the master socket is then connected via another bit of wiring to the NTE5 faceplate. I know this because in the past I have had the master socket off and know the cable coming into the house is too short to extend to the NTE5 faceplate without an extension.
-
There is a thread elsewhere here on Kitz that discusses, or at least speculates upon, some aspects of the DLM algorithm. If DLM has seen resyncs to be the issue (rather than error rates), then it will view the problem as a primarily one of stability. In those circumstances, 'how long it takes' depends upon whether, having 'temporarily' capped your sync rates at a lower profile, it encounters any further 'instability'. There is some evidence to suggest that 14 days is a basic unit of the time which the algorithm uses. Unfortunately it also uses a 'doubler' effect each time further instability is encountered while already in a capped profile.
So, for example only, a one off lowering of the profile might be lifted in 14 days, but (as happened in my case), if this happened 3 times in a row (as it did), it took closer to 2^(3-1)*14=~56 days to return to 'normal', albeit that it did progressively step up the profiles during that time.
I only mention this to give you some idea of the timescales that could be involved - they can test the EU's patience considerably. HTH
It's worth mentioning that having been banded from 80/20 to 60/20, since resolving the issue that caused me to be banded in the first place, I was back on 73/20 within 2 days and back on 80/20 within 4.
-
It's worth mentioning that having been banded from 80/20 to 60/20, since resolving the issue that caused me to be banded in the first place, I was back on 73/20 within 2 days and back on 80/20 within 4.
Sure. That can (and obviously does) happen as long as there are no further instances of whatever (instability) caused it to be capped in the first place. Otherwise e.g. if further resyncs are caused while you are already on a capped profile, then the delay doubling mechanism may kick in. In my case my own line stepped back up two profiles in exactly the same time frame as happened to you, but then took a further 2^(3-1)*14days to return to the full 80/20.
So it all depends upon each individual set of circumstances, including: the nature of the fault, its duration, whether it recurs on subseqent days, the DSLAM type you're on, how many profile bands you have been stepped down, etc.
But certainly, with a fair wind, DLM can also recover quite quickly. The problems really occur when it doesn't. :)
-
One thing I forgot to mention is that the master socket is NOT the NTE5 socket. The master socket is a very old smaller faceplate/box that runs a worn looking cable going out a hole drilled into the window pane. The NTE5 box is directly above it so I presume the cabling inside the master socket is then connected via another bit of wiring to the NTE5 faceplate. I know this because in the past I have had the master socket off and know the cable coming into the house is too short to extend to the NTE5 faceplate without an extension.
:hmm: Hmm . . . I find that a little difficult to follow. Could you possibly take a series of photographs and make them available for viewing, please?
-
Todays stats. Something happened at 8am after a resync (I was in bed so not me!)
# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 18534 Kbps, Downstream rate = 75604 Kbps
Path: 0, Upstream rate = 20000 Kbps, Downstream rate = 65416 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.1 4.9
Attn(dB): 0.0 0.0
Pwr(dBm): 13.3 6.8
VDSL2 framing
Path 0
B: 51 237
M: 1 1
T: 64 45
R: 12 16
S: 0.0253 0.3782
L: 20243 5373
D: 1281 1
I: 64 127
N: 64 254
Counters
Path 0
OHF: 15507772 1980373
OHFErr: 143 101
RS: 3969833459 243514
RSCorr: 407619 557
RSUnCorr: 9285 0
Path 0
HEC: 2070 0
OCD: 58 0
LCD: 58 0
Total Cells: 3169782522 0
Data Cells: 8575543 0
Drop Cells: 0
Bit Errors: 0 0
ES: 115 79
SES: 11 0
UAS: 77 77
AS: 25202
Path 0
INP: 3.00 0.00
PER: 1.61 4.25
delay: 8.00 0.00
OR: 118.61 60.17
Bitswap: 3584 618
Total time = 1 days 12 hours 25 min 37 sec
FEC: 1902224 169402
CRC: 6712 106
ES: 115 79
SES: 11 0
UAS: 77 77
LOS: 5 0
LOF: 10 0
Latest 15 minutes time = 10 min 37 sec
FEC: 5267 12
CRC: 0 2
ES: 0 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 23075 9
CRC: 5 2
ES: 1 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 12 hours 25 min 37 sec
FEC: 658936 26884
CRC: 3185 101
ES: 47 75
SES: 5 0
UAS: 20 20
LOS: 5 0
LOF: 5 0
Previous 1 day time = 24 hours 0 sec
FEC: 1243288 142518
CRC: 3527 5
ES: 68 4
SES: 6 0
UAS: 57 57
LOS: 0 0
LOF: 5 0
Since Link time = 7 hours 1 sec
FEC: 407619 557
CRC: 143 101
ES: 26 75
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
#
# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 18485 Kbps, Downstream rate = 75604 Kbps
Path: 0, Upstream rate = 20000 Kbps, Downstream rate = 65416 Kbps
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 18485 kbps 75604 kbps
Actual Aggregate Tx Power: 6.8 dBm 13.3 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 4.3 23.6 36.0 N/A 11.8 29.1 45.0
Signal Attenuation(dB): 4.3 23.2 34.9 N/A 11.8 29.1 45.0
SNR Margin(dB): 5.0 5.0 4.9 N/A 6.1 6.1 6.1
TX Power(dBm): -4.1 -19.5 6.4 N/A 10.1 7.9 7.0
#
-
Thank you for those pictures. I now understand.
Hopefully the original LJU master socket is not actually connected into the circuit and is just being used as means to hold gel-crimps which extend the service cable into the NTE5/A + SSFP assembly. :-\
-
Thank you for those pictures. I now understand.
Hopefully the original LJU master socket is not actually connected into the circuit and is just being used as means to hold gel-crimps which extend the service cable into the NTE5/A + SSFP assembly. :-\
I think so. I will take the master plate off to verify but pretty sure it is.
-
Had another BT SFI. Same old same old. BTO must really be drumming it into BT engineers heads to do as little as possible and NOT to touch the DLM unless absolutely necessary. Blood from a stone comes to mind.
I asked him if it was possible to removed the NTE5 box from the window frame and make it the master socket instead of the little socket underneath. I stressed to him that I did not wish to be charged otherwise leave it where it is and I will rewire from where it meets the back plate of the master socket to the NTE5 box myself. After asking him several times that I would not be charged for putting the NTE5 box under the internal window ledge with a small extension he put a small junction box with the master socket was. Removed the NTE5 box and put it under the ledge stuck to the wall with some double sided (it's loose and not screwed to the wall but I am not bothered too much as it does not have anywhere to fall other than dangle off the bit off cable. I will get some of that 'no more nails' stuff if it does.
Re-synced at lower speeds because it's the period of the day when SNRM is 1.5dB lower. Posted this info along with a little bit of a moan to Plusnet support and a BTW speedtest. If BT try to charge me they can jump off a cliff! It's something I could have done myself for free otherwise and I told the engineer this is what I had intended to do if he could not do it for free (you can see I am a bit worried about getting charged for this heh).
Anyhow I am back to square one and it looks like nobody will do anything as I am above speed estimates.
-
"Had another BT SFI. Same old same old. BTO must really be drumming it into BT engineers heads to do as little as possible and NOT to touch the DLM unless absolutely necessary. Blood from a stone comes to mind".
For info -- Performing a DLM 'Re-calc' for an engineer is quite easy. We have 3 ways in which we can achieve this ..... 1) Via the WHOOSH GEA platform, accessed personally from the engineers laptop. 2) Via their mobile phone using our 'Call platform services'. 3) Via a remote operator, who has to ask the question, 'was any fault was found' ?.
We are not monitored on performing DLM 're-calcs', nor does it form any part of the 'Performance Management' statistics, or subsequent disciplinary procedures. So, in a nutshell, carrying out the deed is relatively simple.
However, you have hit the nail on the head in terms of not doing a 're-calc', unless necessary. By that, I would expect the engineer to have either located and fixed a fault, or, can prove from historic data that DLM has been overly-aggressive for whatever reason. Continued and constant 're-calc' of a circuit does not achieve anything in the long term.
-
OK it fell off so I put no more nails stickies on the back plate. Thanks for that titbit of info. Seems like he was just too lazy himself to do it. It would not have taken much it would seem for him to do it. Granted it would probably over time just go back to similar speeds. I was more curious as to what the initial sync speeds were when it was first installed without DLM doing anything to be honest (I do not know what it was with the ECI which was originally provided and can only guess at it).
I still say DLM sucks. But I am greedy lol.