Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: CrazyTeeka on May 08, 2017, 12:34:02 AM
-
What is the best way to health check your broadband line?
What tools can you use?
How can you tell a fault from a non-fault?
Can Broadband Boost or SFI2 improve things even if there is no clear fault?
-
Four questions, all very difficult to answer! ::)
Some suggestions, in the same numerical order --
- Assume nothing and consider it as something completely new to yourself.
- A DMM, a TDR, a Spectrum Analyser.
- By experience.
- Yes. And no. And maybe. Or possibly.
-
Thanks for the reply. If I share the information I have maybe it can help.
Test dc00f664-eaf2-4788-93e6-f72489ca854d DiagnosticCode = GTC_FTTC_SERVICE_1625, TestDescription = Impairment in copper joint detected most likely in local network. Please continue to submit a trouble report, ServiceTestID = 3147415, OpenreachReferenceID = or_nga_rdl10432app02:352886053, TestCompleted = true, DateTestRequested = 2017-05-07T12:56:24.09, DateTestCompleted = 2017-05-07T12:57:28.757, TestOutcome = Fail, MainFaultLocation = LN, AppointmentRequired = N, FaultReportAdvised = Y, ServiceLevel = 2, EthernetTraffic = N, DownstreamSpeedMBPS = 0, UpstreamSpeedMBPS = 0, DateTestStarted = 2017-05-07T12:56:31.157, DateTestStopped = 2017-05-07T12:57:21.1, RadioFrequencyIngress = Not Detected, BridgeTap = Not Detected, RepetitiveElectricalImpulseNoise = Not Detected, VoiceLineTestResult = Pass, CrossTalk = Not Detected, Client = TTR Service Centre
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 4
Last initialization procedure status: 0
Max: Upstream rate = 16295 Kbps, Downstream rate = 60264 Kbps
Bearer: 0, Upstream rate = 16233 Kbps, Downstream rate = 53488 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): 4.8 6.1
Attn(dB): 21.3 0.0
Pwr(dBm): 6.9 6.9
VDSL2 framing
Bearer 0
MSGc: 18 14
B: 51 238
M: 1 1
T: 64 59
R: 12 16
S: 0.0309 0.4686
L: 16552 4353
D: 1047 1
I: 64 255
N: 64 255
Counters
Bearer 0
OHF: 88621323 1214033
OHFErr: 512 31
RS: 1212094690 298321
RSCorr: 2548591 239
RSUnCorr: 24491 0
Bearer 0
HEC: 5751 0
OCD: 3 0
LCD: 3 0
Total Cells: 937050035 0
Data Cells: 375905939 0
Drop Cells: 0
Bit Errors: 0 0
ES: 266 37
SES: 19 0
UAS: 383 364
AS: 176161
Bearer 0
INP: 3.00 0.00
INPRein: 0.00 0.00
delay: 8 0
PER: 1.98 6.93
OR: 96.60 23.05
AgR: 53584.68 16255.98
Bitswap: 54048/54077 202/207
Total time = 3 days 9 hours 52 min 56 sec
FEC: 4684133 363
CRC: 10035 46
ES: 266 37
SES: 19 0
UAS: 383 364
LOS: 0 0
LOF: 10 0
LOM: 12 0
Latest 15 minutes time = 7 min 56 sec
FEC: 9947 2
CRC: 19 0
ES: 1 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: 26224 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 = 9 hours 52 min 56 sec
FEC: 840570 39
CRC: 117 1
ES: 36 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 1204458 91
CRC: 269 9
ES: 61 9
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 2 days 56 min 1 sec
FEC: 2548591 239
CRC: 512 31
ES: 135 22
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
-
TestDescription = Impairment in copper joint detected most likely in local network.
That defect would be easily found using the TDR functionality of a JDSU HST-3000c or an Exfo AXS-200/635 -- the standard issue HHTs provided to Openreach technicians.
-
What does this reveal...
(https://crazyteeka.uk/images/TDR-05080038.bmp)
-
It reveals a potential high-resistance fault (HR).
The dotted line running north to south is the 'measuring cursor', where it is positioned in this screen-cap it shows as being 43.1mtrs.
However, the potential HR is slightly to the right of this (shown as a slight 'peak'), and the cursor would need to be positioned at the start of the 'peak' climbing edge ....... or if you prefer, at the bottom of the 'U'. The screen when on 'XShort' runs from 0-108mtrs, so the HR will in fact probably be around 50mtrs away, from the point at which it is being measured ??.
The only other thing this could be is a potential 'Cable poundage change'. Again, if we look at the gain setting in the screen-cap, it shows as being at '8'. That means the operator of the hand-held tester has manually increased the gain themselves, as when at 'XShort' ...... it will be auto-set to a gain of just '2'.
Increasing the gain also increases the chances of seeing something that 'Isn't there' .... if you see what I mean ?? ;) :)
-
Can the HST3000's VDSL modem in VTU-C mode be used to safely test the DSL circuits in any modem router?
If you get any errors while performing this test and you know the cable is good, does that mean modem router is faulty?
Likewise if you get zero errors, does that mean the modem router is good?
-
Can the HST3000's VDSL modem in VTU-C mode be used to safely test the DSL circuits in any modem router?
If you get any errors while performing this test and you know the cable is good, does that mean modem router is faulty?
Likewise if you get zero errors, does that mean the modem router is good?
Not 100% certain what you mean ...... but the HST3000 has two functions that we tend to use when faulting BB circuits.
1) An xDSL test ..... this basically logs-on to the DSLAM (ADSL or VDSL) and passes data between the two points.
2) A DSL Close-out test ...... this basically logs onto the ISP's server (may be the wrong terminology, but that's how I word it). So it passes data between a greater distance and also ensures the ISP can see we as OR have 'logged on' to their circuit and performed a 5-minute test. A mandatory action on BB faulting.
If errors are witnessed, we obviously use test 1) to determine where in the big scheme of things the fault lies.
Zero errors does not automatically ensure you have a fault-free circuit, (there are other scenarios that can occur that will introduce errors), it just indicates the circuit is performing OK at that particular point-in-time.
The only way we can 'test' the EU's router is to ring the ISP and have them perform comparison test between our kit and theirs.
-
Thanks for sharing. :)
There is a VDSL Modem on the HST3000, that can act as a Modem (VTU-R) or a DSLAM (VTU-C).
What I'm pondering is if this has any usefulness testing end user modems/routers/equipment.
-
I can't comment for certain, but think only two hand-held testers of the same type can be used in VTU-C mode ..... ie: 2 HST3000's ??? I'm sure others may be able to comment further to clarify. :)
It's not something I've ever done, or been asked to do.
-
Out of interest mainly, would a PQ test to Sin349 spec pickup any issues with D-Side/E-Side Copper and LiC/Other systems in exchange?
Or does it just focus on the Copper cable?
-
Out of interest mainly, would a PQ test to Sin349 spec pickup any issues with D-Side/E-Side Copper and LiC/Other systems in exchange?
Or does it just focus on the Copper cable?
A PQT won't pick up faulty Exchange Equipment, as the test-heads the come into play after this ......... but it will pick up most E/D side copper impairments.
-
How would an engineer know things are OK in the exchange?
Or do they just assume it is? ;)
-
How would an engineer know things are OK in the exchange?
Or do they just assume it is? ;)
Faulty Exchange Equipment is usually picked up by our other test systems (Eclipse, Fast Test, CIDT).
-
Thanks for all this advice. :)
Just for my notes, how much does Broadband Boost cost, all I found when looking was TOA?
-
Just for my notes, how much does Broadband Boost cost, all I found when looking was TOA?
Sorry, I don't have any idea. But thinking about the information you provided, following on from my reply to your initial post, makes me wonder if your ISP/CP is Andrews & Arnold (https://aa.net.uk)? :-\
-
Yes it is. ;)
-
Yes it is. ;)
Thank you for confirming the fact. :D
-
Well the only obvious fault appears to be the "Impairment in copper joint".
So I assume line does not meet Sin349.
An appointment is not required so I don't get to heckle an engineer this time.
Whats the best way to find out if the E-Side pair between cabinet and exchange is in good condition?
Kind of heard from an engineer last year that its not in the best condition, and could pickup some noise, could there be any truth to his claims.
-
What exactly are the error symptoms you are experiencing? :-\
At the moment, this thread is tending to read like a series of questions on the subject of: "How to perform a fault-fishing trip, so as to have something to complain about". :-X
I would doubt the claim that the E-side is --
not in the best condition, and could pickup some noise
Once an E-side cable has been installed, the joints are virtually never re-opened. (The will always be a "corner case", in some obscure location, that will be an exception to the rule.) Pair swaps do take place, as that just requires a manipulation at the cabinet and the exchange MDF.
-
Sorry that it sounds like a fault fishing trip, to have something to complain about, but it's not.
I have a habit of questioning things that probably don't really matter at all, over analyzing things as it were.
-
I would just let A&A get on with having that D-side joint fixed and then see how the circuit behaves. :)
-
I ask awkward questions too. My boss always said that. :lol:
-
Gee what a surprise, fault vanishes after BTOR visit. Even though he says he cannot find anything wrong. :'(
DiagnosticCode = GTC_FTTC_SERVICE_0000, TestDescription = GEA service test completed and no fault found ., ServiceTestID = 3164439, OpenreachReferenceID = or_nga_rdl10432app02:1277413498, TestCompleted = true, DateTestRequested = 2017-05-10T19:19:07.473, DateTestCompleted = 2017-05-10T19:20:08.91, TestOutcome = Pass, MainFaultLocation = OK, AppointmentRequired = N, FaultReportAdvised = N, ServiceLevel = 2, EthernetTraffic = Y, SyncStatus = In Sync, DownstreamSpeedMBPS = 0, UpstreamSpeedMBPS = 0, DateTestStarted = 2017-05-10T19:19:14.473, DateTestStopped = 2017-05-10T19:20:05.877, RadioFrequencyIngress = Not Detected, BridgeTap = Not Detected, RepetitiveElectricalImpulseNoise = Not Detected, VoiceLineTestResult = Pass, NTEPowerStatus = PowerOn, CrossTalk = Not Detected, Client = TTR Service Centre
He was happy to do a DLM reset which raised sync to 55M.
-
Intermittent faults are quite common but it definitely was "picked up" by the tester on the day that you checked. :)
Now just to satisfy my curiosity, are you experiencing any circuit defects?
-
I'm not sure what you mean by circuit defects?
-
I'm not sure what you mean by circuit defects?
Massive errored seconds or large fluctuations on your DS & US SNRM or line drops occurring 8 to 16 times per day that sort of thing.
-
Not seeing any of those things.
-
Not seeing any of those things.
That's good. So just make use of the service . . . until such time as it goes wrong.
-
Well, because fault has gone you can lock this thread. :)
-
. . . you can lock this thread. :)
True, I could . . . but there's nothing in this thread that warrants such drastic action! :D
-
I was kidding. :lol:
I have lots more questions. :)
-
I was kidding. :lol:
As was I (as I suspect you realise). ;)
I have lots more questions. :)
Now my head hurts! :-X
-
Now that my line is going through a DLM re-train for the next 14 days, how do I stop any storms from ruining it?
-
Now that my line is going through a DLM re-train for the next 14 days,
There is no such thing. :no:
The DLM process constantly monitors the circuit and takes action, if it deems action is appropriate.
-
I see.
Then what did the engineer mean when he said, DLM needs 14 days after a reset?
What is special about those 14 days?
-
The special part with a DLM reset all depends on what state you circuit/line was in before the reset
So lets take this as an example you moved to another ISP provider and you had G.INP active on your line before the move it then can take upto 11-14 days for G.INP to come back on that line
So yes there is 14 day wait in that scenario
and also if the DLM is reset by engineer then again there is a training/waiting time envolved
-
What is special about those 14 days?
Absolutely nothing. Please consult "Section 2.2.1, Dynamic Line Management" on page 16 of SIN 498 (http://www.btplc.com/sinet/SINs/pdf/498v7p3.pdf), titled "Generic Ethernet Access Fibre to the Cabinet (GEA-FTTC) Service and Interface Description".
-
Thanks for the advice, I will read the Sin498 document.
-
Purely for informational purposes (not looking for faults promise), what does this tell you about things...
---------------------- ATU-R Info (hw: annex A, f/w: annex A/B/C) -----------
Running Mode : 17A State : SHOWTIME
DS Actual Rate : 55670000 bps US Actual Rate : 15403000 bps
DS Attainable Rate : 55450488 bps US Attainable Rate : 15351895 bps
DS Path Mode : Fast US Path Mode : Fast
DS Interleave Depth : 1 US Interleave Depth : 1
NE Current Attenuation : 21 dB Cur SNR Margin : 5 dB
DS actual PSD : 6. 8 dB US actual PSD : 6. 9 dB
NE CRC Count : 3066 FE CRC Count : 5440
NE ES Count : 2454 FE ES Count : 5112
Xdsl Reset Times : 0 Xdsl Link Times : 3
ITU Version[0] : b5004946 ITU Version[1] : 544e0000
VDSL Firmware Version : 05-07-06-0D-01-07 [with Vectoring support]
Power Management Mode : DSL_G997_PMS_L0
Test Mode : DISABLE
-------------------------------- ATU-C Info ---------------------------------
Far Current Attenuation : 27 dB Far SNR Margin : 6 dB
CO ITU Version[0] : b5004946 CO ITU Version[1] : 544eb206
DSLAM CHIPSET VENDOR : < IFTN >
-
It tells me that your circuit is still operating in fast-path mode with a very respectable 55/15 Mbs (DS/US) but with a significant number of ES, both DS and US.
I fully expect that the DLM process will take action in the forthcoming 24 hours. As to what that action will be, I am not prepared to guess.
-
It tells me just that the line is working.
The error statistics are rather paltry (in breadth), and there is no indication of how long the counters have taken to accumulate those numbers, so I don't think I can judge about the quality of the line.
Unless I'm missing something...
-
Unless I'm missing something...
I think it was me that missed something . . . The something that hinted the statistics were from a DrayTek device? Or am I even more confused than normal? :-\
-
Or possibly a Zyxel.
I don't especially trust either.
-
Yes it is a DrayTek Vigor 130. It just works. No evidence of anything wrong with it. :P
-
Or possibly a Zyxel.
I don't see that sort of format with my VMG1312-B10D.
From the GUI it has a very broken display. See the screen-scrape, attached below. But if I make ssh access, I have the full set of reliable Broadcom xdslctl commands available via the Busybox shell.
-
Yes it is a DrayTek Vigor 130. It just works. No evidence of anything wrong with it. :P
That might be partly related to the limitations in what data it provides you.
This thread started out with:
What is the best way to health check your broadband line?
What tools can you use?
How can you tell a fault from a non-fault?
Can Broadband Boost or SFI2 improve things even if there is no clear fault?
The answers to the first three, without specialist test hardware, are generally:
- Use a modem that will give you complete statistical and synchronisation information, which describes the line state, and watch it for changes.
- Use a PC or Linux-based tool that interrogates the modem for that status data, and presents it in graphical form over a long, long period. Starting, preferably, when the line is healthy.
- By analysing the graphs of long-term behaviour, mixed with some skill from previous analysis ... distinct "on the job training" here. Key, though, is watching for changes over time.
When faced with a Draytek modem, I am reminded of the punchline to the old Irish joke: 'Well sir, if I were you, I wouldn't start from here'.
I assume that, when you presented the set of detailed stats earlier, you replaced the Vigor with something useful? They look more Broadcom-oriented.
-
I don't see that sort of format with my VMG1312-B10D.
From the GUI it has a very broken display. See the screen-scrape, attached below. But if I make ssh access, I have the full set of reliable Broadcom xdslctl commands available via the Busybox shell.
My mistake, then.
I wonder what device I am thinking of, then?
I know I distrust Asus modems too, but they don't give that structured-text layout, so it isn't that one.
-
From the GUI it has a very broken display. See the screen-scrape, attached below.
That, by the way, is horrible.
How long does it take to train your mind to skip around to the useful bits?
-
That, by the way, is horrible.
How long does it take to train your mind to skip around to the useful bits?
I never use the GUI to check important statistics; only the Broadcom xdslctl commands.
-
So I should bin this Vigor 130 and switch to a different router?
-
As you said, it works. No need to bin it unless you get line problems that need investigating, and you feel the need to be the investigator. It just isn't going to be very good at giving you that comprehensive health-check information.
Isn't the 130 just a modem?
-
Isn't the 130 just a modem?
Yes, indeed. Just like its predecessor, the Vigor 120.
DrayTek Vigor 120 ADSL Ethernet Modem (http://www.draytek.co.uk/products/business/vigor-120)
DrayTek Vigor 130 ADSL/VDSL Ethernet Modem (http://www.draytek.co.uk/products/business/vigor-130)
-
My reasons for picking this Modem are...
BT SIN 498 MCT Approved
Support for MTU1508 (Jumbo Frames)
VDSL Vectoring
and its still possible to capture the stats at 15 minute intervals then calculate the difference.
This is my 1st time using DrayTek, it doesn't seem that bad to me.
-
I thought some DrayTek devices do provide quite a lot of stats via their telnet commands, and can even adjust the SNRM, but I'm not sure if that extends to the 130.