Kitz Forum
Broadband Related => Telephony Wiring + Equipment => Topic started by: mikeh on April 07, 2017, 08:50:14 PM
-
I've been on fttc for a year now and it has been very stable. Prior to fttc I had an unreliable 2mb connection.
I have a quite noisy line, a background buzzing/hum type noise which I've always attributed to having fibre broadband and cordless phones so I've put up with it. This week the buzzing became louder along with loud crackling making phone calls unpleasant so I did Plusnets online test and it came back with this.
Fault location: CE
Diagnosis code: T020
Description: FAULT - Earth Contact
After a day the crackling ceased and I thought the fault was fixed but this morning I had a txt to say an engineer was calling. He plugged into the test socket and despite no crackling he said the line was too noisy, a noise I'd always thought of as normal as previously mentioned. He plugged his test equipment and there was one red cross which I think was something like D cap?.
He had to wait for a hoist as the poles are tall. One pole at the start of our lane half a mile away has some damaged outer shielding, been like that for some years and been tested before still showed no problems. The pole near our property seemed to indicate a fault and he said could be underground and would need to be dug to find the connections. He couldn't do anymore, this was a job for a digging engineer.
An hour later I got more txts to say the engineer was working on the job. I couldn't see him at the pole which the first OR man told me wanted checking but I did see him at the other pole. I went to see him and he knew about the pole but was checking the damaged cable. He came to the pole near us and I left him, but he didn't do any digging and went back to first pole. About an hour later he had gone, he had put a large joint on the pole where the damaged cable had been.
The buzzing noise is still there. I will see if Plusnet close the fault as fixed. Am I being too premature? Will I see someone return to check the underground connections on the pole near us?
Incidentally I have G INP enabled at 52 is this because of the line noise?
-
You should plug an ordinary phone into the test socket and listen for the buzzing noise. If you can hear anything at all then report that as a fault because the line is definitely broken in that case and it will be affecting your speed.
See
http://www.kitz.co.uk/adsl/socket.htm
-
Specifically you should report it as a telephony fault, one that is audibly noisy, to whoever is your telephony service provider.
Do not mention the broadband service. It is liable to cause confusion and, in the worst case, fail to get the underlying fault fixed.
The fault is with the metallic pathway of the (underlying) PSTN, over which the xDSL (G.993.2, in your case) service operates.
-
Do a QLT dial 17070 / 2 and listen, what I did with my noisy line was to record on my mobile phone the noise and play it back when reporting it as a phone fault.
-
Burakkucat makes a very important point. Don't mention the internet or 'broadband'. They will have to fix it if they are told there is something with the POTS side of things. Always a good strategy.
-
I'm happy with the fibre service which for 1.8km from the cab I achieve 18mb with a Billion 8800nl although the upload is only 0.9mb. My prime concern is the phone not the broadband.
I have a corded phone and the noise is lower but still there. I'm going to check a friends house as they have the same phone and will take the corded one with me also to try. Their line quality is excellent so I should be able compare the two.
I was impressed with the speed of the action by OR but I am dissapointed that the second engineer didn't investigate the pole where the first engineer said he found a fault.
-
I've checked a couple of friends phones today and couldn't believe how quiet they were. I've had this continuous buzzing noise for a long time and always believed it to be normal, how wrong I was. I'm definitely going to pursue a fix on this. I await Plusnets reply tomorrow on the fault ticket.
-
I've had this continuous buzzing noise for a long time and always believed it to be normal, . . .
It reads as if there is still an "earth contact fault" on your circuit. Does the buzzing sound like AC mains hum?
-
Yes Burakkucat it could be described as a hum. I used the term buzzing meaning an annoying sounding hum. On one of the engineers tools the short warning light was flashing but not all the time. When the crackling was happening the humming noise was very bad. I've added some more comments to the Plusnet fault page to let them know the problem is not fixed.
-
It will all be a lot better when it isn't broken any more.
-
I had an update from Plusnet today and was informed that work was in progress to organize a dig. This could take 5 days to process and further updates are expected after next weekend. So I believe the second engineer was tasked with fixing the damaged cable on the end of lane pole, not the digging work.
So there is positive progress and I look forward to this problem being hopefully resolved. Phone faults do seem to be a priority fix.
I will let you know how things go. Thanks for your help.
-
I have had a response from Plusnet and OR are saying that the line is now fixed. Plusnet said they have rechecked and can find no fault now and await my reply.
We have had confirmation from our suppliers that your phone fault should now be fixed. We have checked the line and everything appears to be in order but we are not able to account for every eventuality.
If your service is still not working please get back in touch and we will be happy to investigate further for you.
*INTERNAL*
Main Fault Location: LN (Fault located in local network)
Fault Code: NSY (Noisy)
Clear Code: 51.3
Clear Message: Remote Clear
The noise is not as loud, maybe because it has been very dry lately? but there is still a continuous humming I know no digging has been done at the drop pole where the first engineer found some problem. I've replied that the fault is not fixed as there is still a continuous noise on the line.
The service is working but with a background noise. Any advice please.
-
The noise is not as loud, maybe because it has been very dry lately? but there is still a continuous humming I know no digging has been done at the drop pole where the first engineer found some problem. I've replied that the fault is not fixed as there is still a continuous noise on the line.
The service is working but with a background noise. Any advice please.
Keep precise records and re-apply pressure onto Plusnet. Stress that it is audible noise as a result of a fault in the PSTN.
-
I agree, pressure on the ISP and hope you get a decent OR engineer out. I've had two noisy line issues that were difficult to resolve because the line tests all passed, in that case you're really reliant on the OR engineer agreeing that the noise in itself indicates a problem.
-
I have reported to Plusnet that the humming noise is still present on the line and the usual test socket checks made no difference. Plusnets checks are showing no fault which maybe because the noise is not as loud as it was two weeks ago. Friends have also said the noise at their end has gone.
The humming does vary in noise levels at the moment but it is continuous. This is a half a mile single rural line down my lane with the drop pole near the house. The line goes underground to the pole at the start of the lane.
It would help if OR came back to the property to actually check what they say is fixed!
aesmith I have read your posts and knew this could be a struggle. Over the past 10 years I've had two line swaps from the exchange to cabinet but there are no other lines to my property.
-
An engineer visit is booked for Thursday pm.
-
An engineer visit is booked for Thursday pm.
Have you been given any indication of the type of technician that will be tasked to attend? Just an average network (PSTN) technician? Or one that is multi-skilled, i.e. versed in all aspects, like our Black Sheep?
-
Hi, there has been no indication of the type of engineer coming on Thursday. I've had a reply as such:-
No fault was found after automated testing.
A trouble report can still be raised if the End User is certain a fault exists.
I opted for this and received a reply saying I need to check my internal setup doing the usual tests and if a fault is found on my side I will be liable for a £65 charge.
I keep checking the quiet line test and the background hum is always there with either corded or cordless phones. I have anytime call plan and don't use the mobile at home. Can you confirm there should be no audible background noise on a landline phone, just in case the engineer may say the noise is acceptable?
-
There should certainly not be a background hum on the line and if it is present at the test socket it must be an external fault. My experience with line noise problems is that the openreach engineer can't hear it or it isn't present when tested then they always report back the ISP that the fault has been cleared when nothing has been done!
-
If you decide to go ahead with a visit, it becomes a 'Conscious Decision To Appoint' (CDTA) fault. If our tests pass whilst on-site, and no audible noise can be heard ... then it becomes chargeable.
A 'hum' is usually associated with 'Earth faults' ..... a low resistance reading from one, or both, wire/s, to ground. If there is an internal cable linking the outside wire to your master socket, it could indeed be on that section as well as the chance of it being an external issue ?? You would be covered under 'Fair wear & tear' on your rental agreement though. In my experience, 'Earth faults' are usually internal faults or E-side cable faults ....... the only other instance is a dropwire through trees if the premises is fed overhead ?.
However, tThe remote tests would generally pick these kind of faults up ?? So, in a nutshell, it's a bit of a gamble whether to proceed ?? Our 'Pair Quality Test' (PQT) does have wider quality gates than the remote test, so it may well find something ??? Good luck.
-
It's very odd that all the tests and QLT done on my line by BT OR chaps, none showed up the HR fault :o
But after emailing the CEO of BT OR my line was put on a new cable out of four that go from the exchange to PCP and also a different 'pair' to my DP on our lane (all UG feeds) Problem solved ;D
http://forum.kitz.co.uk/index.php/topic,19162.0.html
-
I wouldn't say it's odd, I'd say it's unusual.
Our tests have a 'Cone of acceptance level' in-built on all parameters. Obviously, if a fault is in its infancy, or is intermittent .... then it may well fall within the CoA, and show as a pass on all tests.
If the fault gets re-repeated a few times, then a triage team (via a robotic tool) should intercept this, and indeed speculative changes to the network can then be made by the engineer, that we are otherwise told are off-limits.
We have to remember that the testing (both remote and on-site) will usually pick up a fault if one is present. The advice/suggestions I give here are, and have to be , in general terms ............ there are way to many variables to go into each scenario, every time a situation is presented to us on the forum. :)
-
I am going ahead with the visit as I have double checked everything and there is always a continuous hum. I have just switched off the modem and phone and connected to the test socket with both phones and the hum is still the same. There is no internal wiring connected to the master socket.
The master socket is on the wall and the cable goes through to wall, then along the wall to the supporting bracket on the bungalow to the pole, then crosses a rail line to the drop pole on the other side of the line. The rail line has no overhead power cables. Both these poles were replaced about 6 years ago, the work was done late at night when the train traffic had stopped.
The line goes underground from the drop pole (Junction box on top of the pole). It appears at the start of our lane, goes up a pole there and connects to another pole which feeds a line to a farm. The cable connecting these 2 poles is in contact with some tree branches at 3 points. I assume the engineer would have picked up any faults at these poles.
The first engineer wanted a check on the connections below the drop pole but no work has been done there. That is as much info as I know. See what happens tomorrow.
-
@mikeh
Forgive me if this irrelevant. Even though there are no OH wires, there is still a lot of electrical infrastructure along railway tracks. I will leave it to the cognoscienti to say if my comment has value.
-
What railway line is it ? where are you ?.
-
My property is located next to a railway level crossing on the Hull to Selby line in East Yorks. The building for the power supply etc for the crossing barriers is located nearby.
Just done another QLT and the noise is very audible. On the phone yesterday there was also some faint crackling.
-
Update after engineer visit
The OR engineer confirmed a continuous buzzing noise, as he called it, a definite line fault. By the way there is also occasional crackling. He couldn't check at the poles without a hoist which was later cancelled. From the test socket a HR fault was showing about 1900 mtrs which is about the distance to the cab. He went to the cab next and concluded that there was a possible underground fault between the pole at the start of our lane and the drop pole near our property, so he cancelled the hoist.
I gave him all the information I knew about the work carried out on the last visit which he found very helpful. He did say there was digging work scheduled at the pole with the damaged cable some time in the past but nothing had happened. He couldn't do any more and said the job would be passed on to the triage team ?
He said that was all he could do and it should get sorted but if it doesn't I should report it again and he hopes he doesn't get the job! I think he said he was a cal engineer? something to do with fibre?
One positive is confirmation of the fault which fortunately is continuous and not intermittent. He was a nice chap!
-
One positive is confirmation of the fault which fortunately is continuous and not intermittent. He was a nice chap!
That is good to know. (Both facts!) :)
-
'The Triage Team' ??? They only get involved when a high repeat report fault has been identified ...... how many visits have you had ???
Are you saying there is a damaged cable that needs to be dug up and repaired ?? If so, the 'triage Team' can't do jack about it ... they are in simple-terms, office bods who are the go-between for ISP's and engineers.
Did he not mention an 'A1024' at all, did he mention a label on the pole commenting on the damaged cable ?? It's all a bit vague, especially as he saw a 'Dis' at the Cab, but then the fault was back near your premises. Very odd. :-X
-
'The Triage Team' ??? They only get involved when a high repeat report fault has been identified ...... how many visits have you had ???
Are you saying there is a damaged cable that needs to be dug up and repaired ?? If so, the 'triage Team' can't do jack about it ... they are in simple-terms, office bods who are the go-between for ISP's and engineers.
Black sheep triage team is used as a generic name for many different helpdesks, in my patch we currently have an a55 triage who we have to call to vet any a55s we submit, in the past we have had a broadband triage who we had to call before closing an sfi/boost, a TRC triage who we had to call before closing any fault, and an 'on the day sucess' triage who we had to call before any furthers.
From the test socket a HR fault was showing about 1900 mtrs which is about the distance to the cab. He went to the cab next and concluded that there was a possible underground fault between the pole at the start of our lane and the drop pole near our property, so he cancelled the hoist.
If you are on fttc then the dslam would show as an HR on the jdsu tdr, possibly if the engineer was fairly new he wouldnt have known this.
He said that was all he could do and it should get sorted but if it doesn't I should report it again and he hopes he doesn't get the job! I think he said he was a cal engineer? something to do with fibre?
'Cal' stands for customer apparatus and line, basically an engineer who is not underground trained. So the engineer has visited the cab, found all to be ok there, and has passed the job for an underground trained engineer to visit.
-
Hell, it sounds like you work in an untrustworthy patch, mate ....... do you have a 'Can I go to the toilet triage team' ??. ;) ;D ;D
Where I work, if a CAL engineer has a UG issue, he will either just pass the task back for a UG engineer, or (through the managers say-so), have a UG engineer assist him on the task at hand, there and then.
Of course, we in the game know that different GM patches have different ways of working, but it seems you're 'triaged' to death !! :)
-
Whoops ..... hit post too quickly.
It does indeed sound like he's a noobie, and mistaken the DSLAM beacon as a HR on his HHT.
-
. . . and mistaken the DSLAM beacon as a HR on his HHT.
That's interesting. Back in 2012 when my neighbour first took a G.993.2 service, I just had to "take a look". Now I'm sure you know me well enough to understand the implication of those three words . . . ;)
When the arranged time arrived, I was invited in, carrying my basic tool-kit, a Tester 301C and a Hawk. (Before the latter item became an addition to Walter's Wheelbarrow.) So there I was, sitting on the floor in front of the NTE5, with a lolly-pop plugged into the "test" socket, first with the "mole" and then with the Hawk connected. My first reaction was "Huh?", to which my neighbour asked "Have you seen something interesting?" I suggested he take a look and then said "First you see it, then you don't. The DSLAM is effectively beaconing its location, waving a flag and saying here I am."
Until I read your words, above, I had never seen the word "beaconing" mentioned in any of the documentation that I have read, from that day to this.
-
Thanks for the feedback, it's nice to know more information about yesterdays visit.
The engineer said he wasn't really qualified to tackle certain aspects of the job. He was unsure whether he was allowed to check the pole next to the crossing because of the rail line and phoned his manager about this.
The pole with the damaged outer cable at the start of the lane was seen to by a second engineer who came on the 7 April when the job was first investigated. He put a foot long plastic joint on the cable where the cable was damaged. I spoke to him at the time and he said it was going to be a difficult job. The first engineer who came earlier that morning and checked all the poles with the hoist had concluded that the problem maybe located underground from the drop pole and would need an underground team. Later OR said the fault was fixed and no underground work was done. I informed yesterday's engineer about this. I don't know if he had opened the joint at the first pole to check from there after he had been to the cabinet.
The main thing was that he reported the noise and as the first engineer had been up the poles and requested underground work he cancelled the hoist as unnecessary. Now that OR have confirmation of the problem maybe they will proceed with the underground work.
-
The internet lost connection later this morning and the phone was off so I checked outside for any work being done. There was an auger wagon near the farm and I could see they were replacing the pole which feeds the farm and carries my line to the pole with the damaged bottom cable which had the plastic joint fitted. I thought they would be replacing that pole as well but when I checked later they had gone.
Could they have replaced the wrong pole? I have had no further update from ISP.
-
Hell, it sounds like you work in an untrustworthy patch, mate ....... do you have a 'Can I go to the toilet triage team' ??. ;) ;D ;D
Where I work, if a CAL engineer has a UG issue, he will either just pass the task back for a UG engineer, or (through the managers say-so), have a UG engineer assist him on the task at hand, there and then.
Of course, we in the game know that different GM patches have different ways of working, but it seems you're 'triaged' to death !! :)
No toilet triage yet but dont go giving them ideas ;) Every now and then we take part in these trials which normally last no more than a couple of months, it gives the next manager in waiting something to do until a job becomes avaliable, and then gives him something to talk about in the interview too :D
The internet lost connection later this morning and the phone was off so I checked outside for any work being done. There was an auger wagon near the farm and I could see they were replacing the pole which feeds the farm and carries my line to the pole with the damaged bottom cable which had the plastic joint fitted. I thought they would be replacing that pole as well but when I checked later they had gone.
Could they have replaced the wrong pole? I have had no further update from ISP.
I can only guess not knowing all the details but I suspect the pole renewal is unrelated to your fault, if a cable has been damaged and needs replacing then this would be done without changing the pole aswell (unless the pole was also damaged). Possibly the pole you saw being replaced was due to be changed for a seperate reason - each pole has a unique ID so its unlikely that the wrong one would be changed.
-
I can only guess not knowing all the details but I suspect the pole renewal is unrelated to your fault, if a cable has been damaged and needs replacing then this would be done without changing the pole aswell (unless the pole was also damaged). Possibly the pole you saw being replaced was due to be changed for a seperate reason - each pole has a unique ID so its unlikely that the wrong one would be changed.
Thank you for that.
-
Further Update.
Plusnet, who have been very good regarding this problem, contacted me today to say their suppliers have completed the work on my line. However, a test by Plusnet detected another problem and asked me how the line was. I said the line noise has been quieter these last 2 days but is still there. The report they got back was as follows:-
I continued to progress to the end customer premises and performed a line test. The test failed with the fault located within the overhead network. There was a fault outside the end customer's curtilage and shown by general wear and tear and was fixed by re-terminating drop wire at DP/external block.
This is not what the engineer told me and he didn't go up the drop pole. He said it was underground between my pole and the pole at the lane entrance. I'm thinking yesterdays replacement of the farm's drop pole has something to do with the OR report. They did disconnect my wire at the farm pole which is 1 km away. Can anybody comment on this.
I am to have another engineer visit to be arranged.
[Moderator edited to fix the bbc tags.]
-
An engineer visit has been arranged for Wednesday afternoon. The noise became louder yesterday evening and it is at an annoying level again this morning. I have no doubt the engineer will hear the same noise as before but I have doubts whether their managers will authorize any digging work.
It is really bad now with loud crackles, the fibre broadband lost connection and has re-synced at 9.9mb instead of the usual 19.9mbs. Quiet line tests have constant loud crackling. The phone is unusable now.
-
The noise became louder yesterday evening and it is at an annoying level again this morning.
It is really bad now with loud crackles,
You should think about recording it while it's bad, I used a app on my mobile phone or on our 'Dect' phones to record it when my line was bad. you may need it as evidence.
-
I am using a friends internet connection as the landline is now unusable. The phone is unusable and will ring showing an external call and then stop. The line is very crackly. I have switched off my router, which could not stay connected.
I don't need to record anything now, the line is kaput now. This will be my last post till they fix this line.
-
Your pain is an engineers joy ...... something to definitely fault !! :)
-
The saga continues. I thought we had a proper "engineer's joy" but the line recovered somewhat by Sunday evening. It was not ready to meet its' maker unfortunately. I was able to phone out again but the noise was so loud with crackling and buzzing I couldn't hear a conversation, so still unusable. All good for the engineer visit today pm.
Monday, check phone constant crackling and buzzing. Unpleasant using phone.
Tuesday - same again.
Today - crackling more intermittent now. Waiting for engineer visit this afternoon. By 2.00pm I had had no text alerts from Open Reach and so phoned Plus Net to confirm the appointment. Which they duly did. Waited in all afternoon but no engineer arrived. I therefore phoned Plus Net back. They informed me the visit had been rejected by Open Reach. I am very disappointed that customers are not informed of cancelled appointments. Plus Net have now arranged a visit for PM Friday. But I notice on their line test "no fault found". I have received a text message from Plus Net informing me that, should an internal fault be found, I could incur a charge of £65 (which is also levied if the customer misses the appointment - how ironic!).
After each engineer's visit I have a feeling of hopeful anticipation - but end up with disappointment and frustration.
One last comment - I have yet to reconnect my modem due to continued and obtrusive interference on the line.
-
Yet another no show from BTOR engineer on Friday. I knew by 2pm as I had had no text alerts from OR that inform you of a visit. I phoned Plusnet and they said that they could not do anything and could not inform me if they knew OR would be coming even though they had we had agreed I would be at home on Friday afternoon. I am frustrated by this situation but I will see what Plusnet do next.
I'm back online again despite the line noise. So far I've had a few re-syncs with a lot of errors showing, at least Plusnet can see how unstable the line is. As far as the noise goes there is a pattern of constant background buzzing which is quite loud and occasional crackling with short loud bursts which can drown out a callers voice. I am not expecting anything to happen till after the bank holiday.
I've been using the excellent Dslstats to monitor the line stats. G.INP was enabled for a while on the upstream with the line noise.
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 1145 Kbps, Downstream rate = 21823 Kbps
Bearer: 0, Upstream rate = 1145 Kbps, Downstream rate = 17998 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 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.7 6.6
Attn(dB): 30.9 0.0
Pwr(dBm): 10.7 10.5
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 40 31
M: 1 1
T: 0 52
R: 6 0
S: 0.0719 0.8737
L: 5226 293
D: 8 1
I: 47 32
N: 47 32
Q: 8 0
V: 1 0
RxQueue: 120 0
TxQueue: 30 0
G.INP Framing: 18 0
G.INP lookback: 30 0
RRC bits: 0 24
Bearer 1
MSGc: 90 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 10.6667 0.0000
L: 24 0
D: 1 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 642333
OHFErr: 835 327
RS: 1332761096 2823830
RSCorr: 727285 0
RSUnCorr: 0 0
Bearer 1
OHF: 1498334 0
OHFErr: 171 0
RS: 8989635 0
RSCorr: 11742 0
RSUnCorr: 265 0
Retransmit Counters
rtx_tx: 17318154 17195
rtx_c: 1583509 15005
rtx_uc: 1044371 13749
G.INP Counters
LEFTRS: 1671 541
minEFTR: 17998 1088
errFreeBits: 381828219 3109827
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 831061592 0
Data Cells: 2266071 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 1168 249
SES: 272 20
UAS: 392 252
AS: 24072
Bearer 0
INP: 51.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 11.40
OR: 0.01 22.45
AgR: 18164.44 1167.43
Bearer 1
INP: 2.50 0.00
INPRein: 2.50 0.00
delay: 0 0
PER: 16.06 0.01
OR: 47.81 0.01
AgR: 47.81 0.01
Bitswap: 8481/8482 7/7
Total time = 2 days 12 hours 47 min 0 sec
FEC: 10964213 1532
CRC: 15256 595
ES: 1168 249
SES: 272 20
UAS: 392 252
LOS: 7 0
LOF: 45 0
LOM: 70 0
Latest 15 minutes time = 2 min 0 sec
FEC: 4450 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: 15410 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 = 12 hours 47 min 0 sec
FEC: 1178777 815
CRC: 10065 494
ES: 626 203
SES: 184 8
UAS: 274 170
LOS: 5 0
LOF: 33 0
LOM: 60 0
Previous 1 day time = 24 hours 0 sec
FEC: 4743128 472
CRC: 3613 87
ES: 295 36
SES: 65 12
UAS: 90 54
LOS: 2 0
LOF: 12 0
LOM: 5 0
Since Link time = 6 hours 41 min 11 sec
FEC: 727285 0
CRC: 835 327
ES: 180 146
SES: 9 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
>
-
If it continues much longer I would get in touch with the Openreach CEO. Everytime somebody has done so, the issue has been resolved within days. Considering you have had 2 no shows, if you have a third, I would suggest doing this. PSTN faults are meant to have a repair time of usually no more than 2 days I believe.
-
CEO = clive.selley@openreach.co.uk
He will get it sorted asap :)
-
Thanks for the advice I will use that approach if OR still refuse to sort this noisy line. I've also taken burakkucats advice and have a log of all events since the noise was first reported. Some of it contradicts what OR have reported back to Plusnet. I've sent Plusnet this log.
The noise continues as before and the Fibre broadband has taken a beating with more lost links today and it's now connected at 4.697mb. At least Plusnet can see evidence of noise on the line when their remote line tests find no fault.
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 1073 Kbps, Downstream rate = 17187 Kbps
Bearer: 0, Upstream rate = 1073 Kbps, Downstream rate = 4697 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 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): 26.0 7.3
Attn(dB): 31.0 0.0
Pwr(dBm): 9.8 10.5
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 130 131
M: 1 1
T: 0 0
R: 16 6
S: 0.8822 3.8601
L: 1333 286
D: 2 1
I: 147 138
N: 147 138
Q: 2 1
V: 0 0
RxQueue: 40 12
TxQueue: 10 6
G.INP Framing: 18 18
G.INP lookback: 10 6
RRC bits: 24 24
Bearer 1
MSGc: 90 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 10.6667 16.0000
L: 24 16
D: 1 1
I: 32 32
N: 32 32
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 0
OHFErr: 1455 211
RS: 32486260 3159157
RSCorr: 51744 921
RSUnCorr: 0 0
Bearer 1
OHF: 447875 449693
OHFErr: 1966 73
RS: 2686880 1798775
RSCorr: 20864 3818
RSUnCorr: 4348 0
Retransmit Counters
rtx_tx: 18429748 33105
rtx_c: 2172532 28862
rtx_uc: 1913144 23752
G.INP Counters
LEFTRS: 2535 901
minEFTR: 4696 1074
errFreeBits: 776897416 3398269
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 64435489 0
Data Cells: 561554 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 1901 758
SES: 474 81
UAS: 654 392
AS: 7195
Bearer 0
INP: 51.00 42.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 4733.15 1090.00
Bearer 1
INP: 2.50 4.00
INPRein: 2.50 4.00
delay: 0 0
PER: 16.06 16.06
OR: 47.81 31.87
AgR: 47.81 31.87
Bitswap: 1005/1005 38/38
Total time = 3 days 9 hours 11 min 20 sec
FEC: 17526927 2925
CRC: 27317 2388
ES: 1901 758
SES: 474 81
UAS: 654 392
LOS: 12 0
LOF: 75 0
LOM: 136 0
Latest 15 minutes time = 11 min 20 sec
FEC: 1506 14
CRC: 53 0
ES: 6 0
SES: 1 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 24117 454
CRC: 720 73
ES: 91 34
SES: 8 2
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 3 0
Latest 1 day time = 9 hours 11 min 20 sec
FEC: 1132699 1393
CRC: 11726 1752
ES: 653 479
SES: 201 61
UAS: 262 140
LOS: 5 0
LOF: 30 0
LOM: 66 0
Previous 1 day time = 24 hours 0 sec
FEC: 6608792 815
CRC: 10400 535
ES: 706 233
SES: 185 8
UAS: 274 170
LOS: 5 0
LOF: 33 0
LOM: 60 0
Since Link time = 1 hours 59 min 55 sec
FEC: 51744 921
CRC: 1455 211
ES: 169 70
SES: 22 7
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 8 0
>
-
tell plusnet if there is 3rd no show you will charge them ten gbp hour for the time you sit waiting
-
Latest word from Plusnet is they are waiting for an OR update. SMC are saying more work needed. I think the line is quite severe now and assume their line tests are picking that up.
Nothing intermittent about voice call noise now with crackling and short burst of a shrill type noise.
Caller display fails to work when the noise is severe.
-
I had a surprise text from OR this morning saying their engineer would be calling. I am retired so I was able to see her. She spent all morning on the job. No hesitation about climbing ladders to test at the poles, I was well impressed with her attitude. :)
She thinks there are two faults on the line, one being a loop. She got a hoist to enable replacement of the line between the farm drop pole and the lane pole which was in contact with some tree branches. There was a little exposure of cable wire but it made no difference unfortunately. She believes the problem lies underground between the lane pole and the pole near our house so there will be digging required. That is about 0.5 mile underground, so it will be difficult I suppose. So a job well done and now wait for the next work to start. It is not the beginning of the end but it is the end of the beginning, best sums it up .
The phone continues to be noisy with variable levels of effects. Broadband still showing lots of noise margin fluctuations and lost connections.
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 1104 Kbps, Downstream rate = 20418 Kbps
Bearer: 0, Upstream rate = 800 Kbps, Downstream rate = 6582 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 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): 24.0 13.3
Attn(dB): 30.4 0.0
Pwr(dBm): 10.6 10.5
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 146 33
M: 1 1
T: 0 0
R: 16 6
S: 0.7083 1.2955
L: 1841 247
D: 4 2
I: 163 40
N: 163 40
Q: 4 2
V: 1 1
RxQueue: 24 24
TxQueue: 6 6
G.INP Framing: 18 18
G.INP lookback: 6 6
RRC bits: 24 24
Bearer 1
MSGc: 90 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 10.6667 16.0000
L: 24 16
D: 1 1
I: 32 32
N: 32 32
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 0
OHFErr: 5749 51
RS: 92400612 3471741
RSCorr: 543590 7459
RSUnCorr: 0 0
Bearer 1
OHF: 1022692 1026813
OHFErr: 4112 60
RS: 6135782 4107254
RSCorr: 77321 3610
RSUnCorr: 7357 0
Retransmit Counters
rtx_tx: 24801386 53920
rtx_c: 812601 163694
rtx_uc: 1003223 87333
G.INP Counters
LEFTRS: 1905 4588
minEFTR: 6579 799
errFreeBits: 7807434 6006314
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 203613018 0
Data Cells: 2000419 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 1652 32
SES: 304 5
UAS: 332 193
AS: 16430
Bearer 0
INP: 48.00 44.00
INPRein: 1.00 1.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 6615.31 836.53
Bearer 1
INP: 2.50 4.00
INPRein: 2.50 4.00
delay: 0 0
PER: 16.06 16.06
OR: 47.81 31.87
AgR: 47.81 31.87
Bitswap: 6586/6586 33/33
Total time = 6 hours 30 min 0 sec
FEC: 2020789 9673
CRC: 19620 96
ES: 1652 32
SES: 304 5
UAS: 332 193
LOS: 6 0
LOF: 37 0
LOM: 66 0
Latest 15 minutes 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
Previous 15 minutes time = 15 min 0 sec
FEC: 43916 681
CRC: 348 12
ES: 68 1
SES: 4 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 6 hours 30 min 0 sec
FEC: 2020789 9673
CRC: 19620 96
ES: 1652 32
SES: 304 5
UAS: 332 193
LOS: 6 0
LOF: 37 0
LOM: 66 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 = 4 hours 33 min 49 sec
FEC: 543590 7459
CRC: 5749 51
ES: 966 14
SES: 69 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 5 0
>
-
Thank you for the update. It's good to know that things are (slowly) progressing.
If you would like to formally acknowledge and give credit to the Openreach technician, please take a look at what I posted here (http://forum.kitz.co.uk/index.php/topic,19693.msg347402.html#msg347402), in another thread, earlier today.
Looking at the latest QLN plot, I can see that the circuit is definitely "unwell".
-
I'm pleased to give the engineer a thank you by way of the OR link, burakkucat.
-
By Wednesday evening the crackling had ceased and the buzzing was very low. The fluctuations in the signal noise ratio on the broadband had also stopped. It was the same on Thursday morning when two underground engineers turned up, one of them had called on Wednesday to view the job. I told him all I knew about the previous visits as he hadn't all the information about the job. They were testing on top of No.2 pole on the far side of the rail crossing. Next they were digging close to the pole.
Some time later they called and said they had found and repaired a wet joint and asked how the phone line was now. As it had been quiet there was no obvious noise but I did detect the same buzzing noise but it was very low. Before they called on me I had been running Dslstats and didn't see any improvement that I hoped I would see on the QLN graph so I had doubts about the fix. With the low noise they were happy the fault had been fixed and we left it at that.
Some twenty minutes later I had an incoming call which triggered a lot of loud crackling, as bad as I had heard before. I went over the rail crossing hoping to see the engineers and fortunately they were still there. With phone in hand they heard it too. Testing again they couldn't be pick up a dial tone at that time which was good. Further testing revealed an intermittent fault some 10mtrs from the joint they had repaired. That was all they could do that day and said they would be back on Friday morning. Nobody came today so I will see what happens next.
Today the line has recovered a bit with less crackling but the broadband is syncing at its lowest level now. I have 18db TSRN on the D/s and 12db TSRN on the U/s The QLN is not as bad as the post but still looks poor.
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 1089 Kbps, Downstream rate = 23088 Kbps
Bearer: 0, Upstream rate = 800 Kbps, Downstream rate = 8800 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 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): 19.2 12.1
Attn(dB): 30.2 0.0
Pwr(dBm): 10.8 10.5
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 24 33
M: 1 1
T: 0 0
R: 8 6
S: 0.0883 1.2955
L: 2990 247
D: 8 2
I: 33 40
N: 33 40
Q: 8 2
V: 3 1
RxQueue: 100 24
TxQueue: 20 6
G.INP Framing: 18 18
G.INP lookback: 20 6
RRC bits: 24 24
Bearer 1
MSGc: 90 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 10.6667 16.0000
L: 24 16
D: 1 1
I: 32 32
N: 32 32
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 0
OHFErr: 17 0
RS: 803978248 3467858
RSCorr: 18128 16
RSUnCorr: 0 0
Bearer 1
OHF: 1109229 65115
OHFErr: 12 0
RS: 6655004 159799
RSCorr: 263 3
RSUnCorr: 26 0
Retransmit Counters
rtx_tx: 25103073 171
rtx_c: 3956 168561
rtx_uc: 139 158290
G.INP Counters
LEFTRS: 2 4641
minEFTR: 8797 799
errFreeBits: 2387336 8028736
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 301490760 0
Data Cells: 4647022 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 6 0
SES: 0 0
UAS: 29 29
AS: 17820
Bearer 0
INP: 55.00 44.00
INPRein: 1.00 1.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 9025.35 836.53
Bearer 1
INP: 2.50 4.00
INPRein: 2.50 4.00
delay: 0 0
PER: 16.06 16.06
OR: 47.81 31.87
AgR: 47.81 31.87
Bitswap: 541/541 1/1
Total time = 4 hours 57 min 29 sec
FEC: 18128 16
CRC: 17 0
ES: 6 0
SES: 0 0
UAS: 29 29
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 12 min 29 sec
FEC: 65 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: 108 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 = 4 hours 57 min 29 sec
FEC: 18128 16
CRC: 17 0
ES: 6 0
SES: 0 0
UAS: 29 29
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 = 4 hours 56 min 59 sec
FEC: 18128 16
CRC: 17 0
ES: 6 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
>
-
. . . would be back on Friday morning. Nobody came today so I will see what happens next.
If, after waiting an appropriate length of time (measured in days), it appears that the fault has been "forgotten" and you have not received any further updates then the time might be ripe to send a copy of your log to Clive Selley.
I have 18db TSRN on the D/s and 12db TSRN on the U/s
Assuming you mean the target SNRM (signal to noise ratio margin) . . . That will be a result of the DLM taking action.
-
Yes I meant SNRM and I assume this will not revert back over time if they can fix the fault so will I need a DLM reset?
I've just checked my Plusnet question page, it's getting quite long now, and there is an A55 for a soft dig by triage. So not forgotten. Mentions unable to get a measure on the fault which is disappointing. I was hoping to see the engineers today as I remembered a dig nearby when there was a power failure one day about 5 years ago They used a mini digger and I know the area of the excavation.
The noise is lower at the moment with occasional low crackles and the broadband noise ratios are fairly level.
-
Yes I meant SNRM and I assume this will not revert back over time if they can fix the fault so will I need a DLM reset?
In theory the DLM should revert the changes it has made once the fault has been eradicated. However the behaviour of the DLM does not appear to be following theory these days . . . So a DLM reset or a circuit "recalc" by an Openreach technician is really the only sure way of restoring sensible circuit parameters.
I've just checked my Plusnet question page, it's getting quite long now, and there is an A55 for a soft dig by triage. So not forgotten.
Ah, so that is encouraging.
-
The Beginning of the End :fingers:
Since the joint was repaired on Thursday the phone line noise has continued with variable levels of crackling and buzzing. Sometimes it's fairly quiet but using the phone seems to generate more noise on subsequent calls. One thing that has improved is the broadband stability, it managed a day without loss of sync and the SNR margins are fairly level till I use the phone. When the line did re-sync I note the D/s SNRM has halved to 9db, so it's connected at 17.9mb.
This morning the underground engineer resumed work on the job again. He said the cable from the repaired pole joint goes under the road/lane and he dug next to the lane on the other side to get at the cable to test. This is where he found a fault. The resistance of the wire was varying from 300,00ohms to 600,000 ohms when it should be 1 million+ . The other pair were better so he has swapped them as a temporary measure but both pairs are in contact with each other so further work is needed and the tarmac will need to be removed to get at the cable.
So another good job done and I look forward to the next job being the final one. :)
It was my good fortune that the line went belly up last Thursday just in time for the two underground engineers to see it completely lose the dial tone.
-
Glad resolution is almost upon you.
I'm posting here really just for reference purposes ... but resistance values between A-E, B-E and A-E (E= Earth, A and B = the pair of wires), should in fact be over 5,000,000 ohms ( More normally written as 5 Mega-ohm) for digital circuits and 1 Mega-ohm for voice circuits.
Broadband is classed as a digital circuit. :)
-
So another good job done and I look forward to the next job being the final one. :)
It was my good fortune that the line went belly up last Thursday just in time for the two underground engineers to see it completely lose the dial tone.
That is good news. :)
-
The underground engineer arrived this morning and I spoke to him before I went out. He was waiting for another crew to sort the tarmac. Since he swapped the line to the other pair the noise is reduced now and the broadband has stayed in sync for three days. However when I returned home in the afternoon no work had been done, X still marks the spot! I thought a nice sunny day they will have ideal conditions to do a good job but not to be. I don't know what happened, I hope swapping the line has not altered the prospect of a full repair. The line still has occasional crackles.
Since Link time = 3 days 5 hours 12 min 31 sec
FEC: 8253691 7
CRC: 82 0
ES: 37 0
SES: 1
-
The End :fingers:
On Friday morning the engineer arrived with the tarmac team. He replaced about 2mtrs of cable which had been damaged when the lane had been widened sometime in the past. The cable had some insulating tape round it to cover some damage. The tarmac now needs a road repair to finish the job.
The phone although a lot quieter still has a little background buzz which I don't get with the same phone on other lines but it's OK. On Friday evening I did have a lot of light crackling and the error rates on the modem went very high along with uneven SNR levels. Since then there has been no more crackling but the modem still has some random high error spikes.
One question regarding DLSTATS, I seem to be getting about 2 million fecs a day but the average error stats are much lower so I cannot match the two. Whenever I check the average fec error rates during the day they vary between 4000/hour to about 15000/hr when there has been some spikes.
Hopefully the line will stay as it is and I won't have to go through it all again.
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 1100 Kbps, Downstream rate = 22988 Kbps
Bearer: 0, Upstream rate = 800 Kbps, Downstream rate = 17998 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 8.8 12.7
Attn(dB): 30.3 0.0
Pwr(dBm): 10.8 10.5
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 40 33
M: 1 1
T: 0 0
R: 6 6
S: 0.0719 1.2955
L: 5226 247
D: 8 2
I: 47 40
N: 47 40
Q: 8 2
V: 1 1
RxQueue: 120 18
TxQueue: 24 6
G.INP Framing: 18 18
G.INP lookback: 24 6
RRC bits: 24 24
Bearer 1
MSGc: 90 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 10.6667 16.0000
L: 24 16
D: 1 1
I: 32 32
N: 32 32
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 0
OHFErr: 1 0
RS: 993728296 3862920
RSCorr: 29190 0
RSUnCorr: 0 0
Bearer 1
OHF: 1117198 73114
OHFErr: 0 0
RS: 6702817 191793
RSCorr: 40 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 25927478 35
rtx_c: 167338 170238
rtx_uc: 73817 176744
G.INP Counters
LEFTRS: 98 4657
minEFTR: 17998 799
errFreeBits: 140794584 17975942
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 621099612 0
Data Cells: 2364392 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 130 0
SES: 11 0
UAS: 68 57
AS: 17948
Bearer 0
INP: 54.00 44.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 18164.44 836.53
Bearer 1
INP: 2.50 4.00
INPRein: 2.50 4.00
delay: 0 0
PER: 16.06 16.06
OR: 47.81 31.87
AgR: 47.81 31.87
Bitswap: 2111/2111 0/0
Total time = 3 days 1 hours 54 min 1 sec
FEC: 6645638 3
CRC: 810 0
ES: 130 0
SES: 11 0
UAS: 68 57
LOS: 1 0
LOF: 6 0
LOM: 0 0
Latest 15 minutes time = 9 min 1 sec
FEC: 302 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: 685 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 = 1 hours 54 min 1 sec
FEC: 3465 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 2137045 0
CRC: 586 0
ES: 15 0
SES: 11 0
UAS: 40 29
LOS: 1 0
LOF: 6 0
LOM: 0 0
Since Link time = 4 hours 59 min 7 sec
FEC: 29190 0
CRC: 1 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
>
-
Sounds good news.
Put your DSLstats graphs on so we can see them.
-
It's difficult to relate the figures in the stats you quoted to any average because there was a resync 5 hours earlier. The figures in that last 5 hours show 29190 FECs, which is nearly 6000 per hour.
-
I will have the laptop running DSLstats from 8pm tonight through till morning to see how many fecs are occurring overnight. It must be when most of the errors are happening. To get over 2 million fecs is an average of 83,000+ /hour.
-
Most of the fecs are occurring late evening and overnight, the error counts are much lower during the day. I cannot think why it should be so but the line seems to be coping fine.
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 1100 Kbps, Downstream rate = 22691 Kbps
Bearer: 0, Upstream rate = 800 Kbps, Downstream rate = 17998 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 8.4 12.8
Attn(dB): 30.3 0.0
Pwr(dBm): 10.8 10.5
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 40 33
M: 1 1
T: 0 0
R: 6 6
S: 0.0719 1.2955
L: 5226 247
D: 8 2
I: 47 40
N: 47 40
Q: 8 2
V: 1 1
RxQueue: 120 18
TxQueue: 24 6
G.INP Framing: 18 18
G.INP lookback: 24 6
RRC bits: 24 24
Bearer 1
MSGc: 90 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 10.6667 16.0000
L: 24 16
D: 1 1
I: 32 32
N: 32 32
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 0
OHFErr: 7 0
RS: 267299992 951526
RSCorr: 1745692 0
RSUnCorr: 0 0
Bearer 1
OHF: 5128902 955408
OHFErr: 0 0
RS: 30773043 3418980
RSCorr: 292 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 25942080 38
rtx_c: 177863 170238
rtx_uc: 73823 176744
G.INP Counters
LEFTRS: 106 4657
minEFTR: 18001 799
errFreeBits: 158450144 18749198
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 2851363197 0
Data Cells: 35969594 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 132 0
SES: 12 0
UAS: 68 57
AS: 82397
Bearer 0
INP: 54.00 44.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 18164.44 836.53
Bearer 1
INP: 2.50 4.00
INPRein: 2.50 4.00
delay: 0 0
PER: 16.06 16.06
OR: 47.81 31.87
AgR: 47.81 31.87
Bitswap: 36400/36400 0/0
Total time = 3 days 19 hours 48 min 10 sec
FEC: 8362140 3
CRC: 816 0
ES: 132 0
SES: 12 0
UAS: 68 57
LOS: 1 0
LOF: 6 0
LOM: 0 0
Latest 15 minutes time = 3 min 10 sec
FEC: 1 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: 2713 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 = 19 hours 48 min 10 sec
FEC: 1719967 0
CRC: 6 0
ES: 2 0
SES: 1 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 2137045 0
CRC: 586 0
ES: 15 0
SES: 11 0
UAS: 40 29
LOS: 1 0
LOF: 6 0
LOM: 0 0
Since Link time = 22 hours 53 min 15 sec
FEC: 1745692 0
CRC: 7 0
ES: 3 0
SES: 1 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
>
-
The number of FECs certainly suggests that there are quite high levels of interference, but the error correction is working very well and there are low levels of ES.
Increased interference during the night can often be caused by strong medium wave radio stations whose signals are propagated much more during the hours of darkness. If you look at your bitloading graph you may see some holes at certain points and you may be able to relate these to specific radio stations in the list at http://www.mediumwaveradio.com/uk.php .
-
OK Eric thanks for that. Now I will see how stable the line is over time.