Kitz Forum
Broadband Related => ADSL Issues => Topic started by: soreilly on April 15, 2012, 05:08:58 PM
-
Good Afternoon Guys,
I need some help diagnosing a fault which has appeared over the last couple of weeks and now appears to be getting worse.
Firstly here are the important details
ISP: Xilo (on Be LLU)
Attenuation: 34.0dB Down / 16.0dB Up (under normal conditions)
Sync Speed: 10Mbps Down / 1Mbps Up (under normal conditions)
Router: Cisco 887W (also have a spare Netgear DG834v4)
Up until about 3 weeks ago I had a fairly stable internet connection then one afternoon there was a short period (~30 - 45 minutes) where several disconnections were seen and the speed and attenuation fluctuated. At the end of it, the router reconnected at its normal speed and attenuation and everything was stable. I didn't think too much of it at the time.
Fast forward to Easter where this happened again but this time it went on for about 3 hours. My sync speed went from 10Mbps down to 2Mbps and everything in between with the attenuation rising to over 40dB. Eventually it calmed down and returned to normal. I raised a fault with my ISP (which is still open) and they advised that if the router is loosing sync then it's something "local".
A few days ago it started getting worse and on Friday I had the day off so decided to troubleshoot. So to start with, I disconnected everything and plugged a phone (no microfilter) into the test socket and did a quiet line test (here after referred to as QLT). This was absolutely silent. I then plugged a microfilter into the test socket, connected a phone and did the QLT again. Again this was silent. I had seen the disconnections on both the Cisco 877 and the Netgear. I tried both routers during the troubleshooting and was able to hear "broadband noise" from both of them.
I kept the QLT open and plugged the ADSL connection in. When the DSL was connected (and when it was connected) I could hear a constant noise (like static) on the line. If I hung up and redid the QLT, it would drop the broadband connection (at which point the QLT became silent).
At this point, I'm thinking the filter is dodgy so I grab some spares I've got and change them over. After some further testing (with the broadband in the main socket instead of the test socket), I finally get a quiet line and making a phone call no longer kicks the broadband off. Excellent I thought. Connection remained stable for about 14hrs before the symptoms reappeared - frequent disconnection / fluctuating speeds / noise on the line with the broadband.
On Saturday, I decided to go one further and replace the cabling and re-terminate all the connections. So, with Krone tool in hand I started with the connection from BT that terminates on the NTE5 (yes I know I shouldn't touch this). Did that and then did a QLT - absolute silence with and without microfilter). Then redid the extensions. Performed a QLT from each socket (without the broadband) and each one was quiet.
All the sockets worked, no noise on the QLT, reconnected the broadband and left it alone.
Today I'm in work (until 7pm) and decided to check the router and noticed that it had been bouncing wildly this afternoon. I can't check to see if there is any noise on the line, but I suspect it may be present.
So to sum up, line is silent when just using a phone for a QLT, but when the DSL is active, noise can be heard. I'm guessing it's internal to me, so what could it be and how do I stop it?
Edit: I'm assuming the fault is local to me, could it in fact be something like a HR fault on the line?
I've tried about 6 different microfilters at home, 3 different ADSL cables and 2 different DSL routers.
Many thanks for reading and sorry for the long post.
Regards,
Stuart
-
The fact that the loop attenuation has shown variations, coupled with the "static-like" noise you can hear when the circuit is attempting to operate as it is designed (modem/router in sync with the DSLAM, telephone "off hook" and in use), is clearly indicative of a developing HR joint somewhere external to you in the Openreach cabling. :(
Ideally you would require the services of a SFI Openreach engineer to run some stress tests on your line whilst monitoring it with her/his JDSU, Exfo or Hawk in TDR mode.
Perhaps Black Sheep will offer his opinion, please?
-
Hi
As you have the netgear I would also run routerstats [/url this is a good trouble shooting tool . .will graph most stats ,showing when any problems arise . In your post you indicate that your stats were going bad without the phone being in use and also when phone in use . RS will show the effects in real time this will give you data for any investigation .
Regards Jeff (http://www.vwlowen.co.uk/internet/files.htm)
-
Gentlefolk,
For completeness, it might also just be worth checking for star wiring inside or outside the house itself, even though this quite unlikely.
Kind regards,
Walter
-
Hi Guys,
Thanks for the replies.
@Jeffbb - I have heard of (and used) RouterStats in the past. I'll try and get the Netgear reconnected this evening and see if I can run RouterStats tomorrow to record any variation. At the moment the fault appears to be intermittent.
@Walter - From what I can see, it's a fairly simple setup. There is a BT pole outside the house which feeds about a dozen properties in the close. The overhead cable comes from the pole to a juction box(?) under the eves on the property and from there, the BT cable comes down the outside of the house to the front room where it enters the property. It goes into another small box which has jelly crimps inside it and from there to the NTE5. Internally from the NTE5, there is a single extension to a phone socket upstairs.
Regards,
Stuart
-
Ive had similar problems as you recently and I could fix it by messing about with it also..then later it would start again...for me it turned out too be a "crossed wire" after switching me from BT Wholesale to SKY SVBN, they went too fix this and now I have no phone line and slow broadband as they require access to my home to complete the job. For me I had your symptoms but also the phone rang randomly twice and when we 1471 it we could hear noise and conversations on the line, incoming calls dropped the broadband, also, sometimes when I picked up the phone there was noise & engaged tone....not much help here but just pointing it out.
sorry I can not be of much help, it sounds like burakkucat may have defined what it is - you just need to convince your ISP of this so they can get a engineer out
-
It appeared to "go stable" late yesterday afternoon and remained stable overnight. At 10:45 this morning the connection dropped, the attenuation went up a couple of dB's and the sync speed dropped from 9Mbps to 5.9Mbps. As I type this, it's gone again, now up +3dB on attenuation to 37dB and sync speed down to 4.5Mbps.
Unfortunately I'm at work (on 12hr shifts) until Wednesday so can't do anything before then. I'm hoping to see if a pattern emerges - like between 10:00hrs - 17:00hrs and then I can grab some further diagnostics on Thursday / Friday.
Stuart,
-
It still reads as a HR, semiconducting or otherwise marginal joint in your D-side cable. :(
-
Hi Guys,
There is definately a problem. I ran RouterStats on the Netgear today. It was raining this morning and the SNR stayed stable. But after lunch when it dried up, the SNR and attenuation started jumping all over the place before settling down a few hours later.
So, what's the best way to report this my ISP (Xilo) to ensure I get an engineer who is clueful about these type of faults and not somebody who just sticks his test equipment, confirms the service is working and buggers off leaving me with a massive bill?
Stuart,
-
Continue to monitor your line with routerstats, print out copies of the graphs that show the effect of the intermittent error and send copies of the same to your ISP. (It wouldn't go amiss to suggest that they also monitor this forum thread.)
A weather diary, collating line abnormalities with temperature, humidity, high winds or whatever, would also be worth keeping.
You will need the services of an SFI Openreach engineer.
Perhaps Black Sheep will be able to add a few helpful comments?
-
Hi Guys,
I've been collecting some data over the last few days with RouterStats and have put it up here:
http://www.stuart.aurora-solutions.co.uk/dsl/index.html
It has a link to each day, gives a brief summary of the weather and the stability of the broadband. As you can see, the broadband is stable when the circuit is wet. Each page has screenshots of the RouterStats output showing the stability.
Today was really quite bad so I decided to use my camera phone to try and capture what I was hearing. Anyway, that was done at about 1pm today. The filter you see at the start of the video was brand new and still in its wrapping when I borrowed it from work on Friday. The video shows me swapping out for an ADSL Nation filter which doesn't make much difference.
When I was recording this, during a QLT I heard a really weird noise and want to know if someone can identify it. On the video it starts around the 2:10 mark. At this point only the phone is plugged into the filter into the test socket.
It started raining (very heavily) at 15:25 and the circuit has been stable since then. :(
I also used the DMT Tool to query the Netgear when it was playing up and this is what I got (file: DMT_With_Fault.png). I then queried the Netgear again after the circuit had been rained on and got this (DMT_After_Rain.png). I'm no expert, but certain tones that were missing this morning are now present and I get a higer bit loading after it rained?!?!
Video Link: http://dl.dropbox.com/u/69515152/Broadband.wmv
Thanks,
-
Apologies B*Cat, only just seen this thread.
"So to sum up, line is silent when just using a phone for a QLT, but when the DSL is active, noise can be heard. I'm guessing it's internal to me, so what could it be and how do I stop it?
Edit: I'm assuming the fault is local to me, could it in fact be something like a HR fault on the line?"
Yes, I would say that's the case, re: the HR. You shouldn't be able to hear the white noise from the router when using the phone, absolutely not.
The problem is how to progress this !!
As it sounds like a HR in its early stages, the chances are the line will test ok on a normal remote test. You could enquire if you SP has access to the CIDT testing systems that perform the normal test, then ping the router with various frequency tones which will determine if there is indeed a HR on your line.
As B*Cat says, ideally you need an SFI engineering visit. If you get a Network engineering visit, the chances are you will get billed and nothing done. I wont go into the semantics behind this, just take my word for it. ;)
If you imagine a HR as being a worn through wire like this ......... }{ .......... with the gap in the middle being the HR. When it rains the water 'fills' the gap thus giving a more stable line ......... ==== ....... ie: the width of the wire is constant. Apologies for the awful icons, but I cant demo it any other way. :-[
So, to concur with others, request an SFI and stress the point audible noise is present with the router plugged in, and that this is causing extreme ammounts of interleaving. It then depends on the quality of engineer you get, and his relevant knowledge. You could ask that interleaving is switched off and that you run in 'Fast path' mode, so that the errors are way more noticeable to both the ISP and the engineer. He may well ignore RS (FEC's), but shouldn't ignore CRC's (Errored Seconds) which will be racking up nicely once Interleaving is removed.
Your choice mate. ;) ;D
-
I've been collecting some data over the last few days with RouterStats and have put it up here:
http://www.stuart.aurora-solutions.co.uk/dsl/index.html
<snip>
Video Link: http://dl.dropbox.com/u/69515152/Broadband.wmv
Both your graphs and video are excellent evidence of a cable fault external to your home.
I would suggest that you make contact with your ISP by e-mail, allow them to digest the information and stress that the fault is only present on warm, dry days. (Provide them with the links to your graphs, the video and this forum thread.) As Black Sheep has mentioned, they may be able to use CIDT to observe the fault for themselves.
Make a request for them to book a visit from an Openreach SFI engineer to trace and eradicate a HR fault.
As your ISP is Xilo (a.k.a. Uno) they should listen and thus be suitably reactive to your complaint.
[EDIT: The odd sound is - er - odd. Sorry but I do not recognise it. :no: ]
-
If you imagine a HR as being a worn through wire like this ......... }{ .......... with the gap in the middle being the HR. When it rains the water 'fills' the gap thus giving a more stable line ......... ==== ....... ie: the width of the wire is constant. Apologies for the awful icons, but I cant demo it any other way. :-[
FWIW, apart from the noise on a Quiet Line test when the router is connected, this all sounds quite similar to my FTTC connection (i.e. the possible link to wet & cold weather that seems to create a more stable connection).
-
. . . this all sounds quite similar . . .
@Bald_Eagle1, To eliminate any potential for possible confusion by someone speed-reading this thread, I believe you intend the above to be --
. . . this all reads quite similar . . .
I think the distinction is necessary, for the OP has posted a link to a video, complete with an audio soundtrack! :-X
-
Ah, yes.
Thanks for pointing that out b*cat.
It does read similar in that use of the phone occasionally causes disconnections & there does appear to be a link to this issue cropping up during warm & dry weather, disappearing as soon as the weather turns wet & cold again.
Unlike the OP, my phone is ALWAYS quiet when conducting a quiet line test.
-
Black Sheep & b*cat,
Many thanks for your help and advice. I forwarded the information onto my ISP for their analysis. They have agreed an SFI engineer is required however due to personal and work commitments I am unable to do anything before the May bank holiday.
Thanks again.
-
Good old HR faults eh. I have the CIDT tool here so if your line is a BT line i can test it for you giving it is a WLR3 line and not a classic line as the classic lines still use the remote diagnostics which ain't going to give me anything but a LTOK. All you will need to do is plug all your kit in and give me your number by PM and i will test it. Had one of these yesterday. CIDT was picking up an HR fault at CA. Turned out to be the router causing it as i broke the line down. Tested with the faceplate removed to expose the test socket and LTOK. Tested with the faceplate on and nothing else connected and LTOK. Surprised it was the router but there you go nothing can surprise in this job :lol:
Gary
-
Hi Guys,
Quick update - Unfortunately I've been rather busy on other things and this got put on the back burner. Anyway, I have requested an SFI engineer for next Monday (awaiting confirmation from the ISP). The weather looks like it's going to be dry and warm this weekend so hopefully I can get more data. It's rained virtually every day since my last update meaning the fault has not presented itself.
My ISP does not have access to the CIDT testing tool but I have speaking with coolsnakeman via PM and he ran a couple of tests which "unfortunately" came back clear.
We'll see what happens once the SFI has been.
-
Good luck with the SFI visit he should beable to clear the issues for you. Keep us posted in what was said and done ;D
Gary
-
Hi Gary,
SFI engineer booked for Monday AM.
When they turn up I'll explain the problem I am seeing, show them the graphs and the video and then let them decide.
Should I mention that I think it's a HR fault or is that telling him how to do his job?
-
Update:
SFI engineer has just been. Showed him the RouterStats graph and the video before he started. He first reaction was "possible HR fault". Great I thought, this is what I want to hear.
Unfortunately it all went downhill from there. He stuck his equipment on the incoming pair, ran a multitude of tests with his equipment and confirmed the line is perfect. AC balance was perfect, minimal loss. He even checked the cable back from the PCP to the exchange.
He left his equipment plugged in for about 15 minutes to check for errors and I watched the screen. HEC / CRC and FEC all showing 0 on the downstream and upstream. This is the one time I want to see errors but unfortunately they just weren't there. :(
Pair quality test proved the line is "perfect". The only thing he did do is replace the jelly crimps with another type of crimp in the box where the drop wire comes in just before the NTE5. He did this because he'd been told the jelly crimps "could" cause interference but he'd never seen it.
The only other suggestion he could offer me is that the fault affecting me was affecting other people as well and that an engineer had been out prior to this visit and repaired whatever the fault was. The PCP is not in my road so I can't tell if an engineer had been out.
If the fault is still there, then I'll just wait until it gets really bad before I report it.
Oh well, I now expect a bill for the SFI visit as no fault was found despite showing the engineer the evidence. :(
-
Dispute the charge if you have eliminated the fault to being your own equipment then ask the service provider to give you written or verbal evidence to prove the fault was in your own domain. Did the engineer leave advising a charge would be raised or did he suggest what the issues could be to you ie faulty router etc. Did he mention any aspect of your internal wiring or your own equipment. If he didn't then the charge would not be deemed as a fair charge. Problem is intermittent so it will be just put down to the fault not being there on the engineers visit.
Gary
-
The only thing he did do is replace the jelly crimps with another type of crimp in the box where the drop wire comes in just before the NTE5. He did this because he'd been told the jelly crimps "could" cause interference but he'd never seen it.
There could just be a reason for the above. By doing some work on the line, which would be in his report -- replacing the gel crimps because he was suspicious of the existing pair -- then your ISP should not be charged. Hence no charge should be passed to you. ;)
-
Dispute the charge if you have eliminated the fault to being your own equipment then ask the service provider to give you written or verbal evidence to prove the fault was in your own domain. Did the engineer leave advising a charge would be raised or did he suggest what the issues could be to you ie faulty router etc. Did he mention any aspect of your internal wiring or your own equipment. If he didn't then the charge would not be deemed as a fair charge. Problem is intermittent so it will be just put down to the fault not being there on the engineers visit.
Gary
Hi Gary,
I'll wait and see what my ISP does re the charges. The engineer didn't make any mention of any charges nor did he specifically state the fault was my equipment. He was actually very helpful and explained quite a lot. When he saw the video he could see there was a problem and wanted to try and find the fault. Unfortunately the fault "wasn't there" so he couldn't do anything.
Regards,
-
The only thing he did do is replace the jelly crimps with another type of crimp in the box where the drop wire comes in just before the NTE5. He did this because he'd been told the jelly crimps "could" cause interference but he'd never seen it.
There could just be a reason for the above. By doing some work on the line, which would be in his report -- replacing the gel crimps because he was suspicious of the existing pair -- then your ISP should not be charged. Hence no charge should be passed to you. ;)
Hi b*cat,
He had to snip the old crimps off to test the cable pair. When he finished he said he was putting on a different type of crimp for the reason stated above.
Hopefully he's done as you suggested above.
I'll continue to monitor the connection and see how it performs.
Thanks for everyone's help.
-
From everything you have told us with regards to the engineer's appointment, I suspect that he will make a note in his report that there is an intermittent fault which was not traceable at the time of his visit.
-
From everything you have told us with regards to the engineer's appointment, I suspect that he will make a note in his report that there is an intermittent fault which was not traceable at the time of his visit.
Here's hoping. :)
-
From everything you have told us with regards to the engineer's appointment, I suspect that he will make a note in his report that there is an intermittent fault which was not traceable at the time of his visit.
Hi b*cat,
Unfortunately not. Here is the email I got from my ISP today:
We've received the following back from the engineer.
"Unable to find a fault with the EU line. EU is complaining of connection noise on his line when the router is connected. I have checked this and no noise can be identified. Have pq and fast tested the line and both pass. Sync test is clean and without ANY errors. sync up @9.6mbps."
Unfortunately, as no fault was found a charge has been made for the engineer call out. This will be added to your next service invoice.
Tom
--
Support
uno Broadband
-
Dispute that charge! Noway can you be liable for that charge when you have clearly elimated the problem as NOT being the EU's equipment. Make sure you state that point and state the investigation that you have carried out at your end to prove this fault does not lie in your domain. Make a strong point to them that this problem only occurs when it is dry (if i have gotten that right) and that it is intermittent for this reason. Obviously you can not predict the weather conditions so this may need to be escalated for you in order to get this resolved.
Gary
-
I second Gary's comments. You have a fault with the service. The fault is not within your domain or control. The fault is intermittent. You reject your ISP's attempts to pass any charge onto you. Your ISP should, in turn, reject Openreach's attempts to pass any charge onto them.
Make it quite clear that the fault does still exist and needs to be escalated within Openreach to those with the correct equipment/means to identify and eliminate the cause of the fault.
-
If you really get problems with an unjustified bill give Mr Livingstone a call at the BT Centre in London, or your ISP's equivalent. As already mentioned to you, the fact the BT engineer went outside and carried out work on the line means he must have confirmed you had a genuine fault. Do not stand for this stupidity.
-
BT should only charge you in the event of :- 1. Customer not knowing how to operate the equipment.
2. Customer's OWN equipment was faulty.
3. When the circuit was `Right When Tested' ( RWT )
BT should not charge for a fault on THEIR line or equipment, or an FNF report, as by BT's own definition an FNF report can only be applied if the BT engineer has witnessed a fault, that had subsequently disappeared.
Unless BT has changed their fault definitions since I was employed by them, the above is correct.........
-
Hi All,
Dispute has been raised. Let's see what happens.
Strangely my connection has been more reliable of late - coincidence?
-
Good man but make sure you certainly do not take no for an answer ;D. That could be coincidence but if it has started to work ok just be happy with that and keep a close watching eye on it.
Gary
-
This is a bit of a longshot, but would you mind me asking if you have a fridge or freezer anywhere near your router?
-
This is a bit of a longshot, but would you mind me asking if you have a fridge or freezer anywhere near your router?
Hi,
Cabling or router go nowhere near the fridge / freezer.
Regards,
-
One more longshot: do you think your phone cable (behind the test socket) would run close to your mains electricity power cable? (e.g. do they share the same ducting)
-
One more longshot: do you think your phone cable (behind the test socket) would run close to your mains electricity power cable? (e.g. do they share the same ducting)
Hi,
Sorry for the delay in replying - been away for a few days.
In regards to the question - nope. We live in a close. There are two BT poles with overhead cables to all the properties. Our cable comes off the pole to a box under the eves and then down the outside of the house to the front window where it enters the property.
Regards,
-
BT should only charge you in the event of :- 1. Customer not knowing how to operate the equipment.
2. Customer's OWN equipment was faulty.
3. When the circuit was `Right When Tested' ( RWT )
BT should not charge for a fault on THEIR line or equipment, or an FNF report, as by BT's own definition an FNF report can only be applied if the BT engineer has witnessed a fault, that had subsequently disappeared.
Unless BT has changed their fault definitions since I was employed by them, the above is correct.........
Mostly true apart from the highlight mate.
A 'FNF' is when the diagnostic tester (Front desk) has witnessed a fault using remote testing equipment, and the subsequent engineering visit reveals everything to be OK. This can not be charged against the ISP/EU. :)
-
Hi Guys,
Sorry for dragging this thread up again, but I checked my monitoring graphs today and saw erratic behaviour. I'm also monitoring the link via the BQM at Thinkbroadband. Unfortunately I can't run RouterStats as I'm not at the property (and won't be until next week). The router is powered up in case someone needs to use the net via Wifi.
The screenshot is from a server running MRTG and polling the router every 60 seconds. The light blue area is downstream data and dark blue is upstream.
Here is the BQM link which shows a lot of packet loss across the link, where as the MRTG graphs so virtual no traffic all day (around 300bps).
http://www.thinkbroadband.com/ping/share/4ad3b828eea50c720c897d1e79b8ee4f-20-06-2012.html
EDIT: Currently using the Netgear DG834 router.
Thoughts?
PS, the dispute ticket for the SFI engineering visit last month is still open with my ISP.
-
Hi Guys,
I know it's been a while but, sadly, whatever is affecting my line is back again. :(
Things had been relatively fine (bar the thousands of CRC & HEC errors clocking up even when the connection wasn't being used). I was synced at 11Mbps getting a good throughput.
That was, until earlier this week. The dry warm weather arrives and my line starts playing up again. On Sunday, according to RouterStats, the connection was unstable for an hour or so in the middle of the day. Today over a period of 4hrs, RouterStats showed the connection was unstable (and unusable according to a family member. I was at work).
So, how do I trace this fault?
- ISP has tested the circuit and confirmed no fault.
- SFI engineer out in May who confirmed no fault. Dispute ongoing re charges.
- Fault only appears to happen in prolonged periods of dry warm weather.
- Changed router / cabling / filters - fault still apparent.
- Connected at the test socket - fault still apparent.
- Tried different hardware - fault still apparent.
I'm at home tomorrow, and judging by the weather forecast (http://www.bbc.co.uk/weather/2652053), I can probably say with some certainty the connection will be unstable at some point.
I'll post a link to the RouterStats data once I have looked through it.
Edit: I thought it might be the router overheating but the router is located in a room that does not get the Sun on it until mid afternoon. It also happened when the router was located in other rooms around the house. The router is warm to touch but not hot.
-
and you have tried other routers?
did the engineer do a Wideband Noise test? looking at the report he done a Pair Quality test and Fast test, these are just basic "quality" tests, he most certainly hasnt done a Wideband Noise test (unless its not listed in his report), ive had an SFI engineer out before who didnt even run these kind of "obvious" tests - the 2nd one (who found the problem by using a Wideband Noise Test) wasnt even gunna try until I pushed him into it shoving evidence in his face (print outs of SNR & QLN before & after showing noise on the line) - the point here is the engineer may not have run basic wideband noise tests which would show noise on the line - sounds like that SFI engineer is looking for narrowband noise (audible such as crackling, clicking, whistling, popping etc)
there are a few more tests he could have carried out but sounds like all he has done is test that its functional for phone & broadband regardless of noise and speed, as long as some throughput comes through & can make and receive a call then its a pass, but he needs to be reminded that it wasnt always like this and he should pursue further tests - you really have to push them or your stuck with it...I was in same boat.
I think the reason a previous poster mentioned about the fridge/freezer is that they run even harder on warm days, could it be emitting REIN when its running?
Ive heard that wet weather may make overhead lines heavier and the weight creates more pull on the connections which may be making them better if they are badly corroded or something?? hence dry weather reverses this
as you have massive error counts this shows there is wideband noise activity, what you need to do is get another SFI out on a hot day when the problem is occurring and remind your ISP to remind him its his job is too stay all day until the problem is resolved (which is what I was told by a few people and a rep at sky) - he could run other tests, also go to each point in the line and check the joins etc, test each section between each joint if needs be.
this will be a right head-ache for you, I know because i went through same thing and took me 3 months and 7 engineer visits to get it put right
-
Snadge,
I believe the line expands during hot weather and contracts during cold weather or the other way about i am not 100% sure. One thing i do know is that an engineer is not required to stay all day to fault find because if he did that he would be in some serious trouble by his field engineer. They are given an allocated time (usually 2 hours) to fault find and if they do not find a fault in that period they either have to sign the job off as FNF or advise on another engineer visit if they believe there is still more work to be carried out. I do believe from the domain checks that you have done this problem is most certainly on your service providers network and it certainly is down to them to make sure this is repaired. Have you checked with other neighbours around you to see if they are encountering the same sort of issues? This always helps when gathering evidence to go to the SP with as snadge would agree. Getting an SFI sent out during a hot day is going to be a tough one. Your going to have to keep up with the weather man/woman and hope to god they get it right on the day of your visit.
Regards
Gary
-
The weather effect on a xDSL is something that Black_Eagle1 is familiar. After 11 months, it was traced to a pair of poor connections at the pole-top DP. Not on the drop-cable to DP side but on the feed-cable (from underground) to the DP side.
-
@ Gary - isnt that 2 hour thing just with ordinary Line Engineer? I was told by tier 2 tech rep at sky and the SNS Engineer that an LL14 Broadband Engineer has to stay all day until the problem is resolved.
is SFI a Broadband Engineer?, I always thought they were 2 different engineers - at least come across like that to me cos I could have sworn that when I had problems with the 1st BB Engineer he talked about getting in SFI, but i may be wrong.
anyway, they told me that they are supposed to stay all day until the problem is fixed and they are allowed to do anything physically possible to try and get your speed back such as shortening pair route if possible via pair diversion, changing cable etc etc - this was pointed out again by an annoyed sky rep when the 1st Broadband Engineer shot off after 4 hours putting in a new line to no avail (except fixing the phone problem).
-
It depends how far down the chain you have gone. In a first fault visit for both PSTN and Broadband the time the engineers are given to fix the fault is 2 hours and that is across the board for OR. However if you have had mutliple visits with no resolution to your issue then it would be granted probably by a field manager to expand the length of time given to fix the fault and the field manager himself may want to attend the fault to supervise the engineer to make sure the job is done and the fault is fixed. That is my intake to this but BK and BS would probably be your best bet to confirm this as they work out in the field themselves.
Regards
Gary
-
It depends how far down the chain you have gone. In a first fault visit for both PSTN and Broadband the time the engineers are given to fix the fault is 2 hours and that is across the board for OR. However if you have had mutliple visits with no resolution to your issue then it would be granted probably by a field manager to expand the length of time given to fix the fault and the field manager himself may want to attend the fault to supervise the engineer to make sure the job is done and the fault is fixed. That is my intake to this but BK and BS would probably be your best bet to confirm this as they work out in the field themselves.
Regards
Gary
:lol: :lol: :lol: I'm not laughing at you Gary, but that comment highlighted above, has just made my day mate. Field Managers wouldn't know if the engineer was doing a good job, a bad job or an average job. They are in effect data-analysts, they look at out i-Pop data ..... strike that .... they intensly scrutinise our i-Pop data, to see if they can scrape another 3 minutes worth of toil out of an individual. I have my own thoughts about BT 'management', but will leave it there.
Back to the question though ............... the '2 Hour rule' is the time given on the job. The i-Pop data expects us back within that time, and the ISP will pay us for this ammount of time. If we find a network fault during our investigations, then we are expected to work on until it is repaired. If all compliance tests pass at the EU's premises, and we can't find anything untoward, then off we go. We will not hang around waiting for it to rain, or for a gust of wind to blow the dropwire. It would be business suicide if we did.
If we can't find a fault when visiting the premises, we can still bring the internal installation 'up to par' if needed, within the 2 hrs paid for.
Hope that makes sense ?
-
Yeah BS makes perfect sense. Well you are going to have a different view on field managers anyway :lol: However those views are left for a different day 8)
Regards
Gary
-
and you have tried other routers?
did the engineer do a Wideband Noise test? looking at the report he done a Pair Quality test and Fast test, these are just basic "quality" tests, he most certainly hasnt done a Wideband Noise test (unless its not listed in his report), ive had an SFI engineer out before who didnt even run these kind of "obvious" tests - the 2nd one (who found the problem by using a Wideband Noise Test) wasnt even gunna try until I pushed him into it shoving evidence in his face (print outs of SNR & QLN before & after showing noise on the line) - the point here is the engineer may not have run basic wideband noise tests which would show noise on the line - sounds like that SFI engineer is looking for narrowband noise (audible such as crackling, clicking, whistling, popping etc)
there are a few more tests he could have carried out but sounds like all he has done is test that its functional for phone & broadband regardless of noise and speed, as long as some throughput comes through & can make and receive a call then its a pass, but he needs to be reminded that it wasnt always like this and he should pursue further tests - you really have to push them or your stuck with it...I was in same boat.
I think the reason a previous poster mentioned about the fridge/freezer is that they run even harder on warm days, could it be emitting REIN when its running?
Ive heard that wet weather may make overhead lines heavier and the weight creates more pull on the connections which may be making them better if they are badly corroded or something?? hence dry weather reverses this
as you have massive error counts this shows there is wideband noise activity, what you need to do is get another SFI out on a hot day when the problem is occurring and remind your ISP to remind him its his job is too stay all day until the problem is resolved (which is what I was told by a few people and a rep at sky) - he could run other tests, also go to each point in the line and check the joins etc, test each section between each joint if needs be.
this will be a right head-ache for you, I know because i went through same thing and took me 3 months and 7 engineer visits to get it put right
Hi Snadge,
Thanks for the reply.
I have tried other routers (Netgear DG834 v4 which I'm currently on, a Cisco 877W and a brand new Cisco 887VA). A friend has also agreed to let me borrow a Speedtouch 585v6 at some point.
As far as I'm aware the engineer just the basic tests (PQ test etc). He never mentioned Wideband Noise test and I hadn't heard of it until your post. Looking back on it, I'm annoyed at how little he did. I explained the problem, presented him with graphs from RouterStats showing wet vs dry days and the video evidence. He tested the line from the house and the PCP and said it's fine, no error. Didn't mention other tests or offer to try different things.
Re the post about the fridge / freezer, I will look into that.
Regards,
-
soreilly
Please dont be annoyed with the engineer. If anything, be annoyed with the processes put in place by the ISP's, Openreach and OfCOM. All 3 parties agreed to the how circuits should be tested when LLU was put in place, and that's what you get.
The 'Wideband Noise' test is built in to the PQT test, so he will have carried one out.
-
Agree with BS don't be annoyed with the engineer be annoyed with the system. It will get to the stage where there will be that many people complaining about the process they will have to change it but god only knows when that will happen.
Regards
Gary
-
It wasn't an attack on the engineer, just an observation following the visit.
@BS you mentioned about the agreement between ISPs / OR and Ofcom about how LLU circuits should be tested. I seem to recall (and again I'm annoyed at myself for not querying this at the time), when the engineer placed his tester on the line he could do a sync test (which showed no errors) but for some reason he said he couldn't do a "full data test(?)" as it wouldn't let him log in (I think his tester had a red light on it).
If there is a process to test LLU circuits, surely the above is not completing the process, and how could he declare my line error free?
-
I am not to sure but i don't think the engineers equipment can authenticate with another providers radius as it is only setup to authenticate with BT's radius. Again i am not to sure but BS or BK i am sure could confirm that.
Regards
Gary
-
I seem to recall (and again I'm annoyed at myself for not querying this at the time), when the engineer placed his tester on the line he could do a sync test (which showed no errors) but for some reason he said he couldn't do a "full data test(?)" as it wouldn't let him log in (I think his tester had a red light on it).
If there is a process to test LLU circuits, surely the above is not completing the process, and how could he declare my line error free?
Openreach are only responsible for the physical infrastructure and not the CP's (ISP's) service that runs on the physical infrastructure. So assuming that the engineer has performed all the designated tests to prove the continuity of the pair and that the quality of the pair is such that it can support a service, including a sync with the exchange MSAN, then it is correct to declare the line "error free".
You hare proved that the issue does not originate within your domain. Good.
Openreach have tested and confirmed that the issue does not originate within their domain. Good.
So now what is left? :-\ :hmm: That domain which every CP / ISP will always swear blind is above question. Their MASN line-card and their exchange based circuitry/equipment. :-X
-
It wasn't an attack on the engineer, just an observation following the visit.
@BS you mentioned about the agreement between ISPs / OR and Ofcom about how LLU circuits should be tested. I seem to recall (and again I'm annoyed at myself for not querying this at the time), when the engineer placed his tester on the line he could do a sync test (which showed no errors) but for some reason he said he couldn't do a "full data test(?)" as it wouldn't let him log in (I think his tester had a red light on it).
If there is a process to test LLU circuits, surely the above is not completing the process, and how could he declare my line error free?
Hmm ?? Terminology can be the difference between success and failure. With that in mind, I'll try and put over what 'we' do on-site (or should do), but with my terminology. Other engineers may use different wording ?
The first test should always be a PQT, as if there is an underlying network fault, then by identifying and repairing it the DSL will most likely improve of its own accord. Not all engineers have HHT's, ergo not all engineers can perform a PQT. All BB/FTTC-P engineers should be HHT enabled due to the testing of higher frequencies.
The second test that I do, is that of an Eclipse or Fast Test. They're both the same low-frequency test, and IMO, unwarranted if the engineer has carried out a PQT, as this is the higher-end test. That said, it is the Eclipse/Fast Test that the SP's demand that we do. As an aside, sometimes there will be a CIDT linked to the Eclipse Test (but we engineers don't know this until the results are given back via SMS text), which is slightly more in-depth than the bog standard test. These occur on probably 5% of the tasks I attend.
The third test I will then perform is called a 'DSL Close-out' test. This can be set to the default 5 minutes, or an extended 15 minutes. This will synchronise with the ISP's Exchange Equipment and give the normal stats (Speed, SNR, Atten etc), then it will pass data back and forth for the allotted time looking for CRC,HEC and RS. It will then present a 'Pass' or 'Fail' result at the end. Both the PQT and the DSL Close-out tests are blue-toothed back to our laptops and then transferred via 'Tarvos' to a data-base for all and sundry to see. All the tests mentioned above can be done on all circuits.
As mooted by BK, 'we' are only interested in the bit from EU to DSLAM/MSAN. We can input each EU's log-on credentials and passwords into the HHT to check for a PPP Session, but TBH it's that damned awkward to do, nobody I know bothers. It's easier to ring the ISP and ask them if they can see an active PPP Session. But again, if we've proved its connected to the right Exchange Equipment we don't need to concern ourselves with the PPP side of the fence, however most of us will go that extra mile. :)
The red light you mention on the tester. I have a JDSU (so can't comment on the EXFO) and there are 2 lights we are concerned about, synch .... and data. The synch light will always go green if the obvious has been accomplished, the data light will go green for BT circuits thus dictating an active PPP Session, for LLU's it will remain red. This last piece of information I retrieved from one of the training guys, so can't confirm this to be absolute fact, but have no reason to disbelieve this particular gentleman.
I hope this clarifies things, or if it doesn't, I'm struggling to put it into words any better. :)
-
Thank you. It has certainly added to my knowledge base, BS. :)
-
Welcome sir. :)
-
the engineer that eventually fixed mine ran a PQ Test when the line was still at fault and came up trumps and started to pack his gear away... not happy I reminded him that all the other engineers did the same test and they all came up LTOK, but the noise issue remained, so he proceeded to do other tests, it was with these tests he indicated there was 'wideband noise' on the line - so I dunno HOW him and the other 6 engineers did not detect wideband noise on my line if the test for it is built in to the PQ test itself? as we all know mine turned out too be a split leg (one of my wires in contact with someone else's which stopped noise cancellation from working properly) - I cant be sure what test he ran to detect that, but I assume a Wideband Noise test would reveal any such anomalies and it certainly wasnt the PQ test, I know that much anyway.
the problem soreilly has is that it only happens at certain times and its gunna be hard getting his ISP to get an SFI Engineer out when its happening (and then pushing that Engineer to do more than basic tests for the phone line & broadband sync).
if the engineer could not complete his tests then AFAIK he should not declare the line ok - I had 6 engineers do the same with my line, declare it as OK - but it wasnt. as long as the phone works and a sync is made then thats all they are bothered about because they are told to do just that.
@ Gary - I know the BT Broadband Engineers kit detected SKY's LLU etc - if by 'Radius' you mean connect to their hardware and get a sync...yes they done that, if thats not what you meant then sorry :)
-
For Snadge .......... as sure as I've got a hole in my bottom, the PQT test on a JDSU DOES inform of 'Wideband Noise' in the form a dB reading.
I doubt your fault was a 'split leg' if other engineers had also peformed PQT tests at your house. If that was the case the AC Balance would have been awful, and the capacitance readings (A-B) wouldn't be great either. It sounds more like your line was in contact, ever so slightly, with a 'Dead pair'.
As you have pointed out, the 'Wideband noise' test will pick up on this.
For your information, and then we're not pushing out false information to other forum users, the PQT is a 'Scripted Test'. That means it runs through a plethora of 'scripted' tests, such as Voltages, Capacitance, Resistance, AC Balance, REIN and Wideband Noise.
Each and every part of the scripted test can also be tested on an individual basis. For example, if the PQT returns a low wideband noise reading, I then wouldn't peform a PQT at every point I accessed in the network. I would only carry out a wideband noise test, as I know everything else is ok. The PQT take approx 4 minutes to complete. The individual tests take seconds.
So with that in mind, I assume that when you say your engineer carried out a special wideband noise test, which no previous engineer had, that he had indeed accessed the individual WN test !!.
In closing, I dont what our HHT 'WN' parameters are set at ?? With AC Balance it is between the 45-50dB mark which will return a 'Fail' result. If the PQT returns a 'Pass' result, then the test has passed within the WN parameters set by our peers.
To ram it down your throat again, IF this is the case, and the other compliance tests also pass ...... we are told to walk away. Again for information, this isn't Openreach alone dictating this course of action. This is the agreement made by ISP's, OfCom and Openreach as a collective.
Until changes are made to the SIN, then thats what you get. Not the engineers fault I'm afraid.
-
Snadge,
When i meant radius i meant there authentication servers which gives out PPP. As already stated the engineers can connect to these ok but it would take them to enter in the customers username and password details in order to do this but that to them is a pain in the a** (i put the starts in so you know hahaha).
Regards
Gary
-
@ BS - trying to think back he mentioned some figures - it may have been A/C Balance but I can not be sure, I know one of the previous ones who done A/C balance said it wasnt great, but wasnt poor either, but the last engineer done other tests AFTER the PQT and thats when he picked up on the problem, all other engineers just ran a PQT and FAST test and off they went.
- Thinking about what you just said about the DEAD PAIR (not in use) that sounds about right as you describe it, are these pairs on the MDF so close together that this sort of thing happens?
what the hell is a SPLIT LEG exactly anyway? I have googled but all I have found out is its something to do with pairing legs from different pairs - is it because the pair is not twisted that it causes problems for broadband?
@ Gary - ahh right, I see what you mean - hey Sky are recruiting in my area for CST, im applying hehe
-
@ snadge -- I remember certain parts of your thread quite clearly. It was observing the poor AC balance which allowed the last engineer to finally fix your line.
As for split legs, you have found the correct answer. I'll just add the comment that the xDSL transceivers operate in differential (i.e. difference) mode, so any signal that is in common on both wires of the pair is ignored. So consider a twisted pair connecting two xDSL transceivers that passes by a localised noise source. That noise is induced into both wires of the pair in (virtually) equal level and phase. Hence the noise is rejected at the receiving end. Now consider the case where there are multiple pairs, as in a typical D-side cable and, by accident, one wire from one pair is used with one wire from another pair. A telephone connected via that pair of split legs will still work without any obvious fault. However a pair of xDSL transceivers connected at each end will each be subjected to substantial induced noise signals which cannot be rejected by the differential circuitry . . . because that induced noise is not equal on each wire of the pair. :no: As far as the transceivers are concerned, the noise "seems" to be part of the wanted signal :-X and is amplified. :'(
-
Hmm ?? Terminology can be the difference between success and failure. With that in mind, I'll try and put over what 'we' do on-site (or should do), but with my terminology. Other engineers may use different wording ?
The first test should always be a PQT, as if there is an underlying network fault, then by identifying and repairing it the DSL will most likely improve of its own accord. Not all engineers have HHT's, ergo not all engineers can perform a PQT. All BB/FTTC-P engineers should be HHT enabled due to the testing of higher frequencies.
The second test that I do, is that of an Eclipse or Fast Test. They're both the same low-frequency test, and IMO, unwarranted if the engineer has carried out a PQT, as this is the higher-end test. That said, it is the Eclipse/Fast Test that the SP's demand that we do. As an aside, sometimes there will be a CIDT linked to the Eclipse Test (but we engineers don't know this until the results are given back via SMS text), which is slightly more in-depth than the bog standard test. These occur on probably 5% of the tasks I attend.
The third test I will then perform is called a 'DSL Close-out' test. This can be set to the default 5 minutes, or an extended 15 minutes. This will synchronise with the ISP's Exchange Equipment and give the normal stats (Speed, SNR, Atten etc), then it will pass data back and forth for the allotted time looking for CRC,HEC and RS. It will then present a 'Pass' or 'Fail' result at the end. Both the PQT and the DSL Close-out tests are blue-toothed back to our laptops and then transferred via 'Tarvos' to a data-base for all and sundry to see. All the tests mentioned above can be done on all circuits.
As mooted by BK, 'we' are only interested in the bit from EU to DSLAM/MSAN. We can input each EU's log-on credentials and passwords into the HHT to check for a PPP Session, but TBH it's that damned awkward to do, nobody I know bothers. It's easier to ring the ISP and ask them if they can see an active PPP Session. But again, if we've proved its connected to the right Exchange Equipment we don't need to concern ourselves with the PPP side of the fence, however most of us will go that extra mile. :)
The red light you mention on the tester. I have a JDSU (so can't comment on the EXFO) and there are 2 lights we are concerned about, synch .... and data. The synch light will always go green if the obvious has been accomplished, the data light will go green for BT circuits thus dictating an active PPP Session, for LLU's it will remain red. This last piece of information I retrieved from one of the training guys, so can't confirm this to be absolute fact, but have no reason to disbelieve this particular gentleman.
I hope this clarifies things, or if it doesn't, I'm struggling to put it into words any better. :)
Hi BS,
Thanks for this insight.
The circuit was unstable from Mon - Thurs last week. Air temperature was hot - around 28C at its peak. On Fri the conditions changed. It cooled to around 23C and was overcast for the majority of the day - result was that the connection became stable with just 1 dropout. Saturday was cooler again but with broken cloud, again connection was fairly stable.
I am reluctant to book another SFI engineer because of the intermittent nature of the fault and the possible charges that will be applied. The engineer has confirmed the circuit is testing okay. Secondly, I cannot guarantee the weather situation. When I booked the engineer in May, it had been dry and warm for several days and I had been experiencing the fault. On the day of the visit, it clouded over and cooled meaning the connection became stable!
PS, sorry for the delay in replying. My PC crashed just before I went on a run of night shifts and I've only just fixed it.
-
@ snadge -- I remember certain parts of your thread quite clearly. It was observing the poor AC balance which allowed the last engineer to finally fix your line.
As for split legs, you have found the correct answer. I'll just add the comment that the xDSL transceivers operate in differential (i.e. difference) mode, so any signal that is in common on both wires of the pair is ignored. So consider a twisted pair connecting two xDSL transceivers that passes by a localised noise source. That noise is induced into both wires of the pair in (virtually) equal level and phase. Hence the noise is rejected at the receiving end. Now consider the case where there are multiple pairs, as in a typical D-side cable and, by accident, one wire from one pair is used with one wire from another pair. A telephone connected via that pair of split legs will still work without any obvious fault. However a pair of xDSL transceivers connected at each end will each be subjected to substantial induced noise signals which cannot be rejected by the differential circuitry . . . because that induced noise is not equal on each wire of the pair. :no: As far as the transceivers are concerned, the noise "seems" to be part of the wanted signal :-X and is amplified. :'(
excellent explanation there B'Kat and thank you ;) - thats how I thought it would happen - so when this engineer said i had a SPLIT LEG it means when sky switched my phone from WLR3 to SVBN it did so onto a pair with "SPLIT LEGS" and why my phone still worked but broadband suffered, kinda shocking that all the other engineers did ignore this A/C Balance thing cos I know 2 of them defo tested for that including the first Broadband/SFI Engineer...
@ soreilly - I sympathise with you 100%, its going to be a right twit to get sorted out, I dunno if theres much more you can do, perhaps write to your ISP's CEO office and complain, when I got mined involved they bent over backwards to help, If your very persistent you will get it done and just refuse to pay any costs, did you say you are with PlusNet...? cant remember, but i know they do (or used too) keep records of users connections, such as speeds they are getting every hour of everyday and how many dropouts etc (I seen a pic of it somewhere) so if you have lots of dropouts on hot days then they will be able to see this on their system and therefore should recognize there is a fault, it will call on you to be a bit persuasive with engineers that come out and try and get them to do extensive testing not only more than PQT's but also all other possible tests and at all points down the line to the exchange - either that or ditch your DSL connection for a Virgin Cable one..
-
@ soreilly - I sympathise with you 100%, its going to be a right twit to get sorted out, I dunno if theres much more you can do, perhaps write to your ISP's CEO office and complain, when I got mined involved they bent over backwards to help, If your very persistent you will get it done and just refuse to pay any costs, did you say you are with PlusNet...? cant remember, but i know they do (or used too) keep records of users connections, such as speeds they are getting every hour of everyday and how many dropouts etc (I seen a pic of it somewhere) so if you have lots of dropouts on hot days then they will be able to see this on their system and therefore should recognize there is a fault, it will call on you to be a bit persuasive with engineers that come out and try and get them to do extensive testing not only more than PQT's but also all other possible tests and at all points down the line to the exchange - either that or ditch your DSL connection for a Virgin Cable one..
Hi snadge,
I agree it will be a pain to sort out. I'm actually with Xilo on their Be LLU product. With regards to the logs for dropouts etc, it doesn't always dropout, the SNR just fluctuates wildly. So I could have a line that fluctuates wildly but only drops a couple of times, and that is all that would be recorded on my ISPs logs.
I'm continuing to monitor it along with checking the area for any REIN (no joy so far).
As for moving to Virgin, things are not that bad yet. :)