It wasn't an attack on the engineer, just an observation following the visit.
@BS you mentioned about the agreement between ISPs / OR and Ofcom about how LLU circuits should be tested. I seem to recall (and again I'm annoyed at myself for not querying this at the time), when the engineer placed his tester on the line he could do a sync test (which showed no errors) but for some reason he said he couldn't do a "full data test(?)" as it wouldn't let him log in (I think his tester had a red light on it).
If there is a process to test LLU circuits, surely the above is not completing the process, and how could he declare my line error free?
Hmm ?? Terminology can be the difference between success and failure. With that in mind, I'll try and put over what 'we' do on-site (or should do), but with my terminology. Other engineers may use different wording ?
The first test
should always be a PQT, as
if there is an underlying network fault, then by identifying and repairing it the DSL will most likely improve of its own accord. Not all engineers have HHT's, ergo not all engineers can perform a PQT. All BB/FTTC-P engineers should be HHT enabled due to the testing of higher frequencies.
The second test that I do, is that of an Eclipse or Fast Test. They're both the same low-frequency test, and IMO, unwarranted if the engineer has carried out a PQT, as this is the higher-end test. That said, it is the Eclipse/Fast Test that the SP's demand that we do. As an aside, sometimes there will be a CIDT linked to the Eclipse Test (but we engineers don't know this until the results are given back via SMS text), which is slightly more in-depth than the bog standard test. These occur on probably 5% of the tasks I attend.
The third test I will then perform is called a 'DSL Close-out' test. This can be set to the default 5 minutes, or an extended 15 minutes. This will synchronise with the ISP's Exchange Equipment and give the normal stats (Speed, SNR, Atten etc), then it will pass data back and forth for the allotted time looking for CRC,HEC and RS. It will then present a 'Pass' or 'Fail' result at the end. Both the PQT and the DSL Close-out tests are blue-toothed back to our laptops and then transferred via 'Tarvos' to a data-base for all and sundry to see. All the tests mentioned above can be done on
all circuits.
As mooted by BK, 'we' are only interested in the bit from EU to DSLAM/MSAN. We
can input each EU's log-on credentials and passwords into the HHT to check for a PPP Session, but TBH it's that damned awkward to do, nobody I know bothers. It's easier to ring the ISP and ask them if they can see an active PPP Session. But again, if we've proved its connected to the right Exchange Equipment we don't need to concern ourselves with the PPP side of the fence, however most of us will go that extra mile.
The red light you mention on the tester. I have a JDSU (so can't comment on the EXFO) and there are 2 lights we are concerned about, synch .... and data. The synch light will always go green if the obvious has been accomplished, the data light will go green for BT circuits thus dictating an active PPP Session, for LLU's it will remain red. This last piece of information I retrieved from one of the training guys, so can't confirm this to be absolute fact, but have no reason to disbelieve this particular gentleman.
I hope this clarifies things, or if it doesn't, I'm struggling to put it into words any better.
