Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: tommy45 on June 03, 2014, 10:02:59 PM
-
Ok the attachments are stats taken just after the modem established sync, following being powered off for over 1hr,
And i'm now using a plug in ADSL style filter, in the test jack, following on from my other thread http://forum.kitz.co.uk/index.php?topic=13935.0 (http://forum.kitz.co.uk/index.php?topic=13935.0)
Observations
Within a few mins the DS Attainable dropped a little, and so did the DS snr was 83672 Kbps a few mins later it's 83444 Kbps
I think that it did this last week when i started to monitor the stats, but my DS attainable started at, 83604 Kbps and dropped to 83376 Kbps So slightly higher this time,
But prior to the me powering off the modem and accessing the test jack my DS attainable was Downstream rate = 83144 Kbps whilst The US had increased to 30658 Kbps and there was similar differences to both US and DS margins and also equal differences to the US attenuation increase, since an unexplained event at around 8am some 2 or 3 days ago,
Weird downstream decreases and the upstream increase both by similar/equal amounts
As for the suspected Fault despite using a different filter in the test jack, when i make a call or even dial a digit, both attainable rates drop ,
Whilst the modem was powered off and disconnected , with my phone(which is corded) only connected in the test socket, I was able to hear a few pop's probably one or every 30secs or so, also there was a rhythmic clicking similar to the clicking you got with the old 70/80's style phones with the round dial,(like a phone ringing but clicks instead)
The line has had this on and off for maybe 8yrs there is also a faint hum/buzz present sometimes it does sometimes seem to become more audible, but when i decided to report it some 2-3yrs ago the OR guy who was called out to the hum, said he couldn't here it, and BT tried charging me £130 for nothing , Would running CIDT show up the issue , as i'm thinking of asking my isp to do this test, otherwise it's put up with it, and possible DLM interventions because of it until it becomes more pronounced and regular, because if i report it as a PSTN fault, who ever turns up may not find it, then i get hit with a charge and worse still the problem persists
-
I had a similar intermittent fault when the phone was used.
It gradually became bad enough for SNRM to drop to below zero values & cause disconnections when dialling out.
Dialling in would improve SNRM for a few hours & it would then gradually reduce again.
Purely by chance, I noticed a couple of engineers working at the pole mounted DP across the road from my house.
I watched the HG612's GUI & saw the connection resync at lower speeds each time.
Each engineer stated they hadn't touched my line as they were work on nearby neigbours' lines.
I spotted another engineer arrive & as soon as he plonked his ladder against the pole, my connection dropped.
Reporting these issues to my ISP, Plusnet an engineer replaced my drop wire from the DP, also rerouting it to go directly to the master socket at the ground floor rear of the house whereas it originally came in at the upstairs front of the house, then via a shielded high quality cable from what was the the master socket to the new master socket downstairs, the upstairs socket being converted to telephone only by back wiring from the new master socket, using a spare pair in the shielded cable.
The new drop wire didn't really cure the problem.
Another engineer evenyually visited & after explaining what I had witnessed & showing him my stats graphs showing disconnections that coincided with engineers working on the DP, (to humour me), he agreed to take a look at the DP's connections.
Before he got his screwdriver out to check/re-tighten the connections at the DP, just touching the undreground cable connection to the DP caused it to come apart in his hands (due to it being badly corroded).
He re-made that connection & after 11 months of intermittent disconnections LTOK results from visiting engineer line tests, aggressive DLM intervention etc., my connection immediately became stable & I enjoyed some of the best sync speeds & prolonged periods without disconnections that I had seen (until increased crosstalk started having a visible effect some 7 months or so later).
FWIW, the disconnections/instability always increased during warm, dry weather & decreased dramatically during cold, wet weather.
It does sound like you might have a similar issue, perhaps still in its infancy.
With a bit of luck, it will eventually deteriorate to the stage where it can be located via an engineer's TDR or FDR test.
-
I've had a few HR type faults, One which caused the ADSL to keep dropping even if the phone wasn't in use,
It took months, it got really bad at one point, the noise during a call to BT retail to report it, became so bad the person on the other end could hear it & not me, but it suddenly stopped , and i couldn't re produce it , eventually one morning i discovered the line was totally dead, engineer swapped both E & D side pairs,,but that was around 4yrs ago, My line is UG all the way to exchange
I think i may ask my ISP to run a CIDT test, to see if it picks up the fault or not,as the test is reported to be free for sp's
As i doubt i would have much success in getting my voice provider (BT retail/india) to run that test, unless they now only use that , if it is an HR dis ,then it should detect it , well according to the official OR info (now a few years old) if it did detect it, it gives OR something to go on,instead of them going in blind and not finding anything
-
Well this fault is getting more weird , The attainable rate seem to show a drop 2 times a day, as does the SNR and
The first results are from, the 27/5/14 till when i powered down for an hour so a re-sync, 3/6/14 @21:00 today,
-
Well i spent a long time on the phone to Plusnet, asked for them to run a CIDT on the line, to be told by the adviser that he did not access to that test, So after 2-3days of waiting for this to be passed to the faults department, i get an e-mail asking me to run a speed test/IP profile check on the BT PT , before they can proceed further ,Which doesn't instil a lot of confidence
What good or help is that to anyone? The reported fault isn't affecting throughput or causing re syncs, certainly not during the past 2 weeks or so that i have been monitoring the connection,
My attainable rates have dropped quite a bit, Making calls now only seems to impact the upstream attainable rate and SNR were as previously it would impact both up and downstream ,Also when using the phone there seems to be an increase in errors mainly on the downstream and an increase in upstream bit swapping, also the upstream power and attenuation has shown a small increase
-
TBH, I can't see an obvious 'fault'.
However, as the data you have posted is all from different times during the day, it could just be expected fluctuations.
Do you have the ongoing stats montage(s) for the period in question that might show either gradual fluctuations or sudden changes?
The 1st attachment depicts an example of what my intermittent fault looked like over a prolonged period.
The fault was finally fixed in May 2012 & the 2nd example depicts the most recnt 60 days worth.
-
When you say montage, what do you mean, fully Monty ? I have the ongoing stats set to take a snapshot once every 24hrs
And my attainable rates have dipped since i started monitoring nearly every day they have gotten lower, The SNR's have also decreased and the upstream power has increased
But if i make a call the attainable rates and the SNR levels both have dropped for the duration of the call, same thing happens when i receive a call, even if i don't answer the ringing voltage alone is enough to impact the VDSL signal , the only reason IMO I'm not seeing disconnects is due to having spare noise margin on the upstream was 15.1db and is currently 14.5db and the downstream which was 7.3 db is now 6.5db
But the voice should not impact the VDSL that could well be a sign of a HR type fault, i don't see that i should have to wait until it gets so bad that my bb becomes unusable and clobbered by DLM ect
Infact the 3 times that DLM has intervened in the past 6-8mths may well be down to what i'm now able to observe , use of the phone also causes more errors, and we know that dlm works from pre determined error rate thresholds ,
-
When you say montage, what do you mean, fully Monty ? I have the ongoing stats set to take a snapshot once every 24hrs
Yes, that's the one.
The graphing program (graphpd.exe) will generate the latest 24 hours worth of graphs for the montage each day, at the time specified in the GUI.
If you wish to generate the montage for a number of days, hours or minutes (working back from the current time), run graphpd.exe, either manually from the Scripts folder or via the GUI button & specify the period.
e.g 4 d for 4 days, 4 h for 4 hours or 4 m for 4 minutes
And my attainable rates have dipped since i started monitoring nearly every day they have gotten lower, The SNR's have also decreased and the upstream power has increased
But if i make a call the attainable rates and the SNR levels both have dropped for the duration of the call, same thing happens when i receive a call, even if i don't answer the ringing voltage alone is enough to impact the VDSL signal , the only reason IMO I'm not seeing disconnects is due to having spare noise margin on the upstream was 15.1db and is currently 14.5db and the downstream which was 7.3 db is now 6.5db
But the voice should not impact the VDSL that could well be a sign of a HR type fault, i don't see that i should have to wait until it gets so bad that my bb becomes unusable and clobbered by DLM ect
Infact the 3 times that DLM has intervened in the past 6-8mths may well be down to what i'm now able to observe , use of the phone also causes more errors, and we know that dlm works from pre determined error rate thresholds ,
It would be useful to see what differences there have been over a number of days.
To keep the times along the X axis uniform, it's best to use 2, 3 4, 6, 8, 12, 24 for the period (regardless of whether you use d, h or m).
If you do wish to specifically record what happens when the phone rings or you dial out from it, try to make sure the call lasts for more than 1 minute to ensure the stats haven't reverted to 'normal' levels for the next minute's data harvest.
Alternatively, make a call or phone your number from a mobile say 5 seconds before the minute & let it ring or keep the call live until say 10 seconds past the minute.
I found that the ringing tone (unanswered) improved SNRM, attainable rates & sometimes connection stability for a few hours or so before gradually dropping to levels where error CRC & other error counts would increase massively & often the connection would resync as I had no spare SNRM to rely on.
Of course, I was initially told that my connection was performing within acceptable parameters, but perseverance on my part (along with my ISP's help - Plusnet) 'eventually' got the fault permanently repaired.
-
Done a 14 day montage which shows nearly all the info i have since i started collecting stats, Most of the dips in attainable and snr are down to phone usage incoming and outgoing
=~=~=~=~=~=~=~=~=~=~=~= Plink log 2014.06.09 21:00:18 =~=~=~=~=~=~=~=~=~=~=~=
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 29687 Kbps, Downstream rate = 80924 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 79987 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): 6.5 14.5
Attn(dB): 13.8 0.0
Pwr(dBm): 12.4 3.8
VDSL2 framing
Bearer 0
MSGc: 18 26
B: 239 237
M: 1 1
T: 23 42
R: 0 16
S: 0.0955 0.3781
L: 20104 5374
D: 1 1
I: 240 127
N: 240 254
Counters
Bearer 0
OHF: 313360438 3765054
OHFErr: 3347 305
RS: 0 1765855
RSCorr: 0 5369
RSUnCorr: 0 0
Bearer 0
HEC: 10912 0
OCD: 245 0
LCD: 245 0
Total Cells: 2373521654 0
Data Cells: 715355718 0
Drop Cells: 0
Bit Errors: 0 0
ES: 2232 224
SES: 0 0
UAS: 24 24
AS: 518261
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 1.65 3.98
OR: 116.09 64.22
AgR: 80103.09 20063.54
Bitswap: 275390/275390 1441/1441
Total time = 1 days 23 hours 58 min 5 sec
FEC: 0 5369
CRC: 3347 305
ES: 2232 224
SES: 0 0
UAS: 24 24
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 13 min 5 sec
FEC: 0 6
CRC: 5 2
ES: 4 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 11
CRC: 3 0
ES: 2 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 23 hours 58 min 5 sec
FEC: 0 704
CRC: 538 54
ES: 383 39
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 352
CRC: 432 48
ES: 344 44
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 5 days 23 hours 57 min 39 sec
FEC: 0 5369
CRC: 3347 305
ES: 2232 224
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
-
Here are 35 mins of stats, there is 3 incoming calls and one outgoing call made in this time
-
Now that could be useful information.
Which were the incoming & outgoing calls?
I think that sudden reductions of anything more than 1 dB in SNRM when using the phone are signs of a brewing HR fault, especially as you could demonstrate it on demand if necessary.
Many users see SNRM reductions of up to 3 dB every night, but they gradually occur over a few hours & gradually improve as daylight approaches, so it's not the amount of reduction that is the issue, it's the speed at which the reductions occur that is relevant.
The more or less 3dB sudden reduction made quite a difference to your attainable rates.
However, as it's not actually affecting your sync speeds or causing disconnections, I reckon you would have an uphill struggle to arrange an engineer's visit.
Unfortunately, I imagine you'll just have to wait until it gets more severe before reporting it as a 'fault'.
At least you'll be able to keep an eye on & record 'things' over as long a period as necessary.
-
Well it's been reported as a fault to the isp, If they do run a CIDT test with modem in sync, and it detects a HR or other fault, i shouldn't have an issue getting a BTOR SFI engineer on the job, The attainable has reduced over the past 6 days, it did the same during the last period i monitored the stats, but upon re syncing the attainable and SNR where back at the higher levels again, strange why it does that ?
On the Attainable Graph , on the downstream side @ 23:11 to 23:16 was an outgoing call , the others on the upstream are all incoming calls (unanswered), it affects the upstream SNR and signal attenuation and power levels too to some extent when calls are made or received here is a screen grab of the GUI http://i.imgur.com/glT8Qqj.png (http://i.imgur.com/glT8Qqj.png)
As for the line fault if my attainable rates where lower and the SNR 's where at 6db i would be having disconnects and DLM would of seriously borked the connection by now . That's my argument, I also think that the fault or whatever is causing this interaction with the PTSN service is responsible for the previous DLM interventions, due to high error rates, as in the past months DLM seems to have kicked in shortly after i have uploaded a lot of data, As i have observed that uploading seems to generate more errors, so the two could be in some way connected , if they are then this fault has already had an impact on the connection, of course I'm unable to prove this theory, but i personally can't see any other reason for DLM to have intervened, apart from higher error rates though not high enough to cause packet loss or poor throughput
-
Well things seem to be progressing, the upstream attainable rate and SNR have dropped again today,here is what it looks like now when the phone is used http://i.imgur.com/XTqNZVv.png (http://i.imgur.com/XTqNZVv.png)
-
I decided to reboot my modem last night and the attainable rates have dropped, upstream SNR reverted back to 15.2 whilst the downstream remained at 1db lower than it was when i started monitoring the stats, the interaction with the PSTN is still evident and now the DS attainable will plummet below the sync rate, whilst the phone is in use
=~=~=~=~=~=~=~=~=~=~=~= Plink log 2014.06.17 09:00:17 =~=~=~=~=~=~=~=~=~=~=~=
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 29974 Kbps, Downstream rate = 80324 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 79987 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): 6.3 15.2
Attn(dB): 13.9 0.0
Pwr(dBm): 12.4 4.2
VDSL2 framing
Bearer 0
MSGc: 18 26
B: 239 237
M: 1 1
T: 23 42
R: 0 16
S: 0.0955 0.3781
L: 20104 5374
D: 1 1
I: 240 127
N: 240 254
Counters
Bearer 0
OHF: 29622062 3889539
OHFErr: 298 47
RS: 0 2831145
RSCorr: 0 256
RSUnCorr: 0 0
Bearer 0
HEC: 1130 0
OCD: 30 0
LCD: 30 0
Total Cells: 3237450556 0
Data Cells: 122913884 0
Drop Cells: 0
Bit Errors: 0 0
ES: 179 41
SES: 0 0
UAS: 23 23
AS: 48992
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 1.65 3.98
OR: 116.09 64.22
AgR: 80103.09 20063.54
Bitswap: 20837/20837 153/153
Total time = 13 hours 36 min 55 sec
FEC: 0 256
CRC: 298 47
ES: 179 41
SES: 0 0
UAS: 23 23
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 6 min 55 sec
FEC: 0 1
CRC: 1 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: 0 15
CRC: 8 2
ES: 7 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 13 hours 36 min 55 sec
FEC: 0 256
CRC: 298 47
ES: 179 41
SES: 0 0
UAS: 23 23
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 13 hours 36 min 31 sec
FEC: 0 256
CRC: 298 47
ES: 179 41
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
HELLO HG612
xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 29974 Kbps, Downstream rate = 80324 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 79987 Kbps
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 29974 kbps 80324 kbps
Actual Aggregate Tx Power: 4.2 dBm 12.4 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 3.2 15.7 22.9 N/A N/A 9.0 20.1 30.4
Signal Attenuation(dB): 3.2 14.7 21.9 N/A N/A 12.0 19.9 30.4
SNR Margin(dB): 15.2 15.2 15.1 N/A N/A 6.3 6.3 6.3
TX Power(dBm): -10.9 -27.5 3.9 N/A N/A 8.1 7.8 7.0
-
Your connection had been up for 16 Hrs 36 Mins at 12:00 when the graphs were generated.
i.e it resynced at possibly one of the busiest/noisiest times.
Possibly a resync between Noon & 2 pm would deliver a 'slightly' higher sync speed & attainable rates (until evening noise kicks in and/or the phone is used.
Attainable rates do adjust in line with changes in SNRM (as caused when the phone is in use).
It's fairly common to see attainable rates below sync speed at certain times of day/night on connections that resync at speeds fairly close to attainable rates.
Just how much do SNRM & Attainable rates plummet when the phone is used?
I suppose it could be due to inadequate faceplate filtering or a brewing HR line issue.
-
The re sync was me, to see if i would get somewhere near the 83mb/30.5mb attainable rates i had when i started monitoring the connection on the 27/5/14 , and to see if there was any changes with the interaction of the PTSN side,
Which now that i have lost some of the spare DS margin, which was 7.3db as well as 3mb off the attainable rate, the ds isn't as badly affected, but it will dip below the sync rate when the phone is in use (outgoing/answering incoming calls)
The BT engineer turned up as arranged in the afternoon, he had an exfo tester, did a VDSL test, which didn't show any problems, then he did a PQT and found an imbalance (was 36db on one leg iirc??) then following a TDR he located an issue at 5m from the NTE (crimped joint where outside cable enters and connects to the newer inside cable) so he re made the connection there and at the outside gray wall box were the 6 pr cable comes from the ground, after testing from there as well, This unfortunately doesn't seem to of made a lot of difference,to the attainable rates ect, and there is still an interaction going on when i make & receive calls , but now when the phone rings, the DS attainable increases a little, and then drops down again,
=~=~=~=~=~=~=~=~=~=~=~= Plink log 2014.06.17 21:00:22 =~=~=~=~=~=~=~=~=~=~=~=
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 29958 Kbps, Downstream rate = 80644 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 79987 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): 6.4 15.1
Attn(dB): 13.9 0.0
Pwr(dBm): 12.4 4.1
VDSL2 framing
Bearer 0
MSGc: 18 26
B: 239 237
M: 1 1
T: 23 42
R: 0 16
S: 0.0955 0.3781
L: 20104 5374
D: 1 1
I: 240 127
N: 240 254
Counters
Bearer 0
OHF: 9107131 3794963
OHFErr: 99 96
RS: 0 404218
RSCorr: 0 414
RSUnCorr: 0 0
Bearer 0
HEC: 248 0
OCD: 7 0
LCD: 7 0
Total Cells: 2315771640 0
Data Cells: 81441820 0
Drop Cells: 0
Bit Errors: 0 0
ES: 430 170
SES: 35 9
UAS: 1715 1680
AS: 15063
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 1.65 3.98
OR: 116.09 64.22
AgR: 80103.09 20063.54
Bitswap: 5589/5589 77/77
Total time = 1 days 1 hours 37 min 0 sec
FEC: 0 1973
CRC: 19748 249
ES: 430 170
SES: 35 9
UAS: 1715 1680
LOS: 5 0
LOF: 31 0
LOM: 8 0
Latest 15 minutes time = 7 min 0 sec
FEC: 0 24
CRC: 0 6
ES: 0 5
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 22
CRC: 4 10
ES: 4 8
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 1 hours 37 min 0 sec
FEC: 0 219
CRC: 39 50
ES: 31 42
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 1754
CRC: 19709 199
ES: 399 128
SES: 35 9
UAS: 1715 1680
LOS: 5 0
LOF: 31 0
LOM: 8 0
Since Link time = 4 hours 11 min 1 sec
FEC: 0 414
CRC: 99 96
ES: 78 84
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
HELLO HG612
xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 29958 Kbps, Downstream rate = 80644 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 79987 Kbps
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 29958 kbps 80644 kbps
Actual Aggregate Tx Power: 4.1 dBm 12.4 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 3.2 15.7 23.0 N/A N/A 9.0 20.2 30.6
Signal Attenuation(dB): 3.2 14.6 22.1 N/A N/A 12.0 20.0 30.6
SNR Margin(dB): 15.1 15.1 15.1 N/A N/A 6.4 6.4 6.4
TX Power(dBm): -11.0 -27.6 4.0 N/A N/A 8.1 7.7 7.0
Further to my last input, i just tried to use my land-line, and there is no dial tone,lol, and i can ring my number from my mobile ,and it gives the ringing tone on the mobile, but nothing is happening at my bt phone, looking like i'll have to be reporting a voice (PTSN fault) or seeing if the isp will get them BT to return and sort it , I bet it's at the PCP again, it's one of those old cast iron ones with a front plate that is secured 4 locking tabs which acts as it's door, and according to one or two engineers it's very limited for space,a pain to work on
-
Hello Tommy45 will you receive an OR engineer visit charge on your next bill from your ISP on whats looks to me like a bloody good fttc line. ???
-
Hello Tommy45 will you receive an OR engineer visit charge on your next bill from your ISP on whats looks to me like a bloody good fttc line. ???
Why , he found a fault his equipment detected it, just because i am fortunate to have a little spare SNR , and it had not progressed enough to become service affecting , shouldn't mean that they ignore it, why should we customers have to wait until it causes serious problems with the services we pay for, ? not only that we do pay for the upkeep of the decaying copper/ali pair in the horrendous line rental fees
From what i have read and from what previous engineers have said to me, there should be no interaction between pstn and xDSL services , had my upstream snr been only @6db, it be service affecting drop-outs everytime the phone is used, i've been there before and what a pain that is
Plus, there's the fact that the ptsn service is now completely dead
-
Why , he found a fault his equipment detected it.
I am only asking as I've had a 7 month old HR fault on my line with PSTN issues on XDSL service, just would like to know if you got charged by OpenReach ;)
-
Why , he found a fault his equipment detected it.
I am only asking as I've had a 7 month old HR fault on my line with PSTN issues on XDSL service, just would like to know if you got charged by OpenReach ;)
Oh, sorry i read it as you thought that i would /should be charged, Well this is getting even stranger now, the PSTN is back working again, for now at least, weird , HR faults can be a nightmare,But if they OR find an issue from their tests then as far as I'm aware should be no charge, it's when they don't find anything you get fleeced, I don't think i will be in a hurry for another OR visit though unless it deteriorates enough to become service affecting , as i think i got lucky this time , had he not had the exfo equipment it may of been a different outcome,
Because even though i was able to demonstrate the interaction to the engineer, he was at first a little sceptical about it, saying that they accept that some times there will be this sort of interaction between the two services (first I've heard of that) but i did stress ,not that i really needed to, that the only reason it wasn't dropping out was due to the spare SNR on the upstream , IMO in this type of situation DLM should be disabled or prevented from applying interleave , should they find it acceptable for the ptsn to cause issues with the xDSL service
-
Of course, you're quite right that DSL and PSTN should not 'Cross' in any way.
As an aside, I use what we call a 'Trout Phone' (Please ..... we've heard every pun there is regarding said name ;) ), to listen on whilst my JDSU synchronises. If I can hear a 'Hissing' noise then there is a very slight HR somewhere that most tests will miss.
The problem is, the official 'Tapper' we are supposed to use wont pick this up, I believe it's down to the high level of capacitance within the 'Tapper' ?? Whatever it is, it won't highlight the 'Hissing' noise as mooted.
-
Not sure if he did that (listen whilst he got a sync, but he did at one point do a quite test whilst testing using his mobile i think) Too early to tell for sure but my error rates may be a little lower certainly the FEC on the upstream and Hec errors on the DS which OR don't count or aren't worried about, But there's still that interaction between the PTSN and VDSL going on question is what is next? wait it out, or call them back again, ? My bets would be it's at the PCP but why it didn't show up i can't say
RE: the hiss as the modem establishes a sync being audible on your "Trout" Phone what exactly is one of those, do they differ greatly in comparison to a corded phone with a small degree of amplification ? would it be likely that this hiss would be audible using a normal phone ? If the tapper is blue in colour then he didn't break that out , just used his mobile and the hand held exfo tester, with a earth in to a wall socket inside the house, and a screwdriver into the ground for an earth outside
-
Yes, the 'Trout' is a very, very, very cheap corded phone. They were given to us back in the days of yore, to give to the EU if their rented telephone had gone kaput as an interim measure. So yes, you're own corded phone should be able to emulate the hissing noise if there is a HR fault brewing ?
He wouldn't possibly be able to carry out a 'Quiet Line Test' on your circuit, using his mobile phone. I would humbly suggest he was using his mobile to either instigate a 'Pair Quality Test', which is what triggers the 'Remote Unit Emulatuion' at the Exchange to test towards the engineers hand-held tester.
Or, he may have been performing a 'Fast Test' with his mobile, which triggers another remote exchange test, but is a low-end test compared to the PQT ?.
HTH. :)
-
Thinking about it now, he probably run the QLT from the my phone, as i recall him muttering something about it being set to number with withheld by default,
Here's the stats for the past 24hrs xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 29827 Kbps, Downstream rate = 79956 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 79987 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): 6.2 15.0
Attn(dB): 13.9 0.0
Pwr(dBm): 12.4 4.1
VDSL2 framing
Bearer 0
MSGc: 18 26
B: 239 237
M: 1 1
T: 23 42
R: 0 16
S: 0.0955 0.3781
L: 20104 5374
D: 1 1
I: 240 127
N: 240 254
Counters
Bearer 0
OHF: 57201640 2700888
OHFErr: 604 268
RS: 0 6742
RSCorr: 0 1952
RSUnCorr: 0 0
Bearer 0
HEC: 1664 0
OCD: 48 0
LCD: 48 0
Total Cells: 1660599512 0
Data Cells: 146326737 0
Drop Cells: 0
Bit Errors: 0 0
ES: 783 237
SES: 35 10
UAS: 1715 1680
AS: 94606
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 1.65 3.98
OR: 116.09 64.22
AgR: 80103.09 20063.54
Bitswap: 38085/38085 412/412
Total time = 1 days 23 hours 42 min 43 sec
FEC: 0 3511
CRC: 20253 421
ES: 783 237
SES: 35 10
UAS: 1715 1680
LOS: 5 0
LOF: 31 0
LOM: 8 0
Latest 15 minutes time = 12 min 43 sec
FEC: 0 0
CRC: 4 0
ES: 4 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: 0 35
CRC: 5 2
ES: 5 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 23 hours 42 min 43 sec
FEC: 0 1757
CRC: 544 222
ES: 384 109
SES: 0 1
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 1754
CRC: 19709 199
ES: 399 128
SES: 35 9
UAS: 1715 1680
LOS: 5 0
LOF: 31 0
LOM: 8 0
Since Link time = 1 days 2 hours 16 min 45 sec
FEC: 0 1952
CRC: 604 268
ES: 431 151
SES: 0 1
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
HELLO HG612
xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 29827 Kbps, Downstream rate = 79956 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 79987 Kbps
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 29827 kbps 79956 kbps
Actual Aggregate Tx Power: 4.1 dBm 12.4 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 3.2 15.7 23.0 N/A N/A 9.0 20.2 30.6
Signal Attenuation(dB): 3.2 14.7 22.3 N/A N/A 12.0 20.0 30.6
SNR Margin(dB): 14.3 14.3 15.3 N/A N/A 6.2 6.2 6.2
TX Power(dBm): -11.0 -27.6 4.0 N/A N/A 8.1 7.7 7.0
Good Bye HG612
xdslcmd --version
xdslcmd version 1.0
DSL PHY: AnnexA version - A2pv6C038m.d24j
-
Just an update on the fault, this is from the engineers report to my ISP ,
****** Checklist questions *******
Is EU setup and modem OK ? - Yes
Is VDSL modem connected via microfilters (Offer to fit SSFP) ? - No
Is VDSL modem in sync ? - Yes
Are SSFP and connections OK ? - Yes
What was the result of the PQT at SSFP ? - Fail - Red
Has any star wiring been isolated on the network side of the SSFP ? (N/A if star wiring not present) ? - No
After the star wiring is isolated, is sync speed at NTE OK ? - N/A
Is EU physical set up OK (PC/Router wiring connected correct ly) ? - Yes
Does on site contact confirm that this is the normal set up of their equipment ? - Yes
Have you been provided with CP's test page account details ? - No
Are you able to conn ect to CP's homepage from customer router using end user PC ? - Yes
Have you confirmed results with on site contact ? - Yes
Did a joint meet with CP's engineer take place ? - No
Is VDSL modem powered up on arrival at EU premises ? - Yes
Have all network side issues identified by pair quality testing been resolved ? - Yes
Can you connect to an external site from EU equipment ? - Yes
*** End of checklist questions ***
Repair com. Vdsl test pass on arrival, 78 down 20 up. Pq fail however, earth on one leg. Remade in bt66, pq pass. Eclipse test ok, test and demo with EU"
So a fault found ,no charges raised by BT OR ,
After the connection being disconnected for a week or so , here's my latest stats
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 30745 Kbps, Downstream rate = 83400 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 79987 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 7.2 15.9
Attn(dB): 13.9 0.0
Pwr(dBm): 12.5 4.0
VDSL2 framing
Bearer 0
MSGc: 18 26
B: 239 237
M: 1 1
T: 23 42
R: 0 16
S: 0.0955 0.3781
L: 20104 5374
D: 1 1
I: 240 127
N: 240 254
Counters
Bearer 0
OHF: 145958387 1641839
OHFErr: 2187 272
RS: 0 2287685
RSCorr: 0 16204
RSUnCorr: 0 0
Bearer 0
HEC: 1699 0
OCD: 38 0
LCD: 38 0
Total Cells: 2755307570 0
Data Cells: 296142618 0
Drop Cells: 0
Bit Errors: 0 0
ES: 986 254
SES: 0 0
UAS: 23 23
AS: 241399
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 1.65 3.98
OR: 116.09 64.22
AgR: 80103.09 20063.54
Bitswap: 126267/126268 976/976
Total time = 1 days 19 hours 3 min 42 sec
FEC: 0 16204
CRC: 2187 272
ES: 986 254
SES: 0 0
UAS: 23 23
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 3 min 42 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 8
CRC: 5 1
ES: 4 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 19 hours 3 min 42 sec
FEC: 0 310
CRC: 357 63
ES: 234 63
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 670
CRC: 668 95
ES: 313 85
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 2 days 19 hours 3 min 17 sec
FEC: 0 16204
CRC: 2187 272
ES: 986 254
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
HELLO HG612
xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 30745 Kbps, Downstream rate = 83400 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 79987 Kbps
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 30745 kbps 83400 kbps
Actual Aggregate Tx Power: 4.0 dBm 12.5 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 3.2 15.7 22.9 N/A N/A 9.0 20.1 30.4
Signal Attenuation(dB): 3.2 14.3 22.3 N/A N/A 12.0 19.9 30.4
SNR Margin(dB): 16.1 16.0 15.9 N/A N/A 7.2 7.2 7.2
TX Power(dBm): -11.1 -27.7 4.0 N/A N/A 8.3 7.9 6.9
The DS attainable was a little higher, @ 83628kbps yesterday for several hours , but the US has increased from 30670kbps
So more or less back to how it was when i started monitoring the connection , still a small degree of PSTN /xDSL cross over interaction going on though
-
Repair com. Vdsl test pass on arrival, 78 down 20 up. Pq fail however, earth on one leg. Remade in bt66, pq pass. Eclipse test ok, test and demo with EU"
Thats fantastic news, I am interested in what the BT66 is also the result of the PQT at SSFP ? - Fail - Red, very interesting.
-
A BT66 is just a weather-proof enclosure, gel-crimped wire joints within. :)
Images . . .
-
A BT66 is just a weather-proof enclosure, gel-crimped wire joints within. :)
Images . . .
Ah I see B*CAT so the BT66 is doing the same job as my old BT16 ;) I guess tommy45 HR fault was closer to home then.
-
I guess tommy45 HR fault was closer to home then.
Indeed, yes. But still in Beattie's network.
-
Indeed, yes. But still in Beattie's network.
Oh yes I know that ;D
pitty you dont have an image of the sausage closure :D
-
pitty you dont have an image of the sausage closure :D
One of these? ;)
-
Do you work for us on the quiet, Mr Cat ?? ;) ;D
-
Meow! The in-built climbing-spikes come in useful . . . :angel:
-
looks to me either HR or bad NTE5.
Given 2 of this forum had bad confirmed nte5's I am surprised noone else has suggested it yet.
Swapping my NTE5 with one I got off ebay my US snrm fluctuations during calls stopped and my US also has no SES.
-
Gentlefolk,
I too have seen two NTE5s fail after thunder storms.
One was so bad that the modem couldn't "see" any VDSL signal yet the dial tone was still present.
Kind regards,
Walter
-
looks to me either HR or bad NTE5.
Given 2 of this forum had bad confirmed nte5's I am surprised noone else has suggested it yet.
Swapping my NTE5 with one I got off ebay my US snrm fluctuations during calls stopped and my US also has no SES.
But wouldn't that of shown up when he ran a PQT?
As it happens i do have a spare unused NTE5 But i need a Krone tool to fit it, the current NTE 5 is one of the older ones that have screws for the A & B pair to connect
ISP aren't wanting to get BTOR out again to finish the job that the 1st engineer started working on , They saying that they can't justify up to £1000 in BTOR engineers visit charges (Based on 5 further visits) as an example , on a fault that isn't or is assumed not to be service affecting, I always thought that the CP didn't get charged if a fault was found on BT's side of things ?
I say it's assumed that this fault isn't service affecting, only because using the phone doesn't cause the Modem to loose sync with the dslam in the cab, But DLM has intervened 3 times in the past 12mths , Could the underlying reason be down to the increase in CRC's And Error seconds when the phone is in use ? if this is down to an accumulation of errors over a set period of time that has triggered DLM then i would argue that this interaction crossover between the PTSN & xDSL is already service affecting
-
I always thought that the CP didn't get charged if a fault was found on BT's side of things ?
If a fault is found on the BT Openreach side then a bill will go out to your Service Provider from BT Openreach, you see your CP has a contract with Openreach for using there infrustucture.
It's one of the reason why your ISP will be reluctant to have and Openreach engineer visit for there customer ::)
-
I always thought that the CP didn't get charged if a fault was found on BT's side of things ?
If a fault is found on the BT Openreach side then a bill will go out to your Service Provider from BT Openreach, you see your CP has a contract with Openreach for using there infrustucture.
It's one of the reason why your ISP will be reluctant to have and Openreach engineer visit for there customer ::)
Are you sure about that . AAISP would disagree with you http://www.revk.uk/2014/04/sfi2-is-optional-extra-service.html (http://www.revk.uk/2014/04/sfi2-is-optional-extra-service.html)
-
I always thought that the CP didn't get charged if a fault was found on BT's side of things ?
If a fault is found on the BT Openreach side then a bill will go out to your Service Provider from BT Openreach, you see your CP has a contract with Openreach for using there infrustucture.
It's one of the reason why your ISP will be reluctant to have and Openreach engineer visit for there customer ::)
Are you sure about that . AAISP would disagree with you http://www.revk.uk/2014/04/sfi2-is-optional-extra-service.html (http://www.revk.uk/2014/04/sfi2-is-optional-extra-service.html)
Well you are the expert here you've had five engineer visits while I have never had an OR visit bar one to install Infinity 1, and before that had a BT (OR) visit my premises in 1986 it was something to do with phone it's self (hardware) :D
-
I always thought that the CP didn't get charged if a fault was found on BT's side of things ?
If a fault is found on the BT Openreach side then a bill will go out to your Service Provider from BT Openreach, you see your CP has a contract with Openreach for using there infrustucture.
It's one of the reason why your ISP will be reluctant to have and Openreach engineer visit for there customer ::)
Are you sure about that . AAISP would disagree with you http://www.revk.uk/2014/04/sfi2-is-optional-extra-service.html (http://www.revk.uk/2014/04/sfi2-is-optional-extra-service.html)
Well you are the expert here you've had five engineer visits while I have never had an OR visit bar one to install Infinity 1, and before that had a BT (OR) visit my premises in 1986 it was something to do with phone it's self (hardware) :D
5 visits,? no only 1 visit so far for this line fault, and a fault was found, so no charges to ISP, The 5 visits was given as an example by the ISP and nothing more, basically they understandably don't want such a worst case scenario happening, and i want the fault with the line fixing regardless if it's service affecting or not
Talking of engineer visits, I had 2 OR visits when i was with UKOnline one SFI and the other was a fault with PTSN , dead line,
Over the years i have had several voice faults due to engineers activity at the PCP due to the accidental disconnecting one leg of the d'side pair, and a humming/buzzing sound that although i was able to hear the engineer said he could not, maybe he suffered with selective deafness,? but they BT retail tried charging me £130 for the pleasure of him reporting RWT non fault, which i disputed and won
-
Thats' what I don't understand Tommy45 why is your ISP telling you this ->
ISP aren't wanting to get BTOR out again to finish the job that the 1st engineer started working on , They saying that they can't justify up to £1000 in BTOR engineers visit charges (Based on 5 further visits)
so whay ever your issue is, it's going to take 5 more Openreach Engineers to cure the fault that sounds like cowshit from your ISP ;)
-
Thats' what I don't understand Tommy45 why is your ISP telling you this ->
ISP aren't wanting to get BTOR out again to finish the job that the 1st engineer started working on , They saying that they can't justify up to £1000 in BTOR engineers visit charges (Based on 5 further visits)
so whay ever your issue is, it's going to take 5 more Openreach Engineers to cure the fault that sounds like cowshit from your ISP ;)
Well i don't think that they meant it would take 5 further engineer visits, more of if it where for some obsecure reason to take 5 more engineer visits, that they couldn't justify it, for a non service affecting fault, where as if it was service affecting then that maybe different, the 5 i think was just a random number used as an example as i did say earlier they talking Hypothetically looking at a worst case scenario, me thinks
I would think all is required is a visit from a conscientious competent senior engineer complete with the required tools and enough time ,to properly find/repair this fault So 1 more visit, But in reality unfortunately it can be a bit hit and miss as to whether or not the engineer who gets sent to your home has all or any of those above or can be bothered to delve deeper in a bid to find the cause /s
-
Ok Tommy45 I'll be direct with you, The OR engineer fix'ed the problem it was and HR issue in the BT66 and from your own post after the fix ->
So more or less back to how it was when i started monitoring the connection , still a small degree of PSTN /xDSL cross over interaction going on though
Yes I have this small amount of degree of PSTN/xDSL cross over interaction for over seven months but isn't service affecting as the phone works the broadband works close to estimated BT speed though I still get US CRC errors when the phones rings.
What is it you feel is missing ?
-
tommy just swap the nte5, if it doesnt fix the problem get back on to plusnet.
I confessed to the openreach CEO I had swapped the nte5 (breaching my t&c's), I recieved no punishment :) as they knew their engineers messed up by not swapping it out.
-
I shall get me a cheap but decent krone tool from amazon , and give it a whirl nothing to loose.
-
I shall get me a cheap but decent krone tool from amazon , and give it a whirl nothing to loose.
Just make sure you orientate the krone tool the right way round when punching down as it has a wire cutter on one side ;)
-
tommy just swap the nte5, if it doesnt fix the problem get back on to plusnet.
I confessed to the openreach CEO I had swapped the nte5 (breaching my t&c's), I recieved no punishment :) as they knew their engineers messed up by not swapping it out.
Well i did as you suggested and it appears to of stopped the crossover effect when the phone is in use, the attainable rates will reduce as well as increase instead of what it did before i swapped it, a slow reduction over time
not to sure if there is any improvement regarding error rates as yet,