Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Berrick]

evening all,

Sounds like you are having a worst time then me. Though there are similarities to the problems I'm having and not just with the faulty adsl line, beatie not showing up, not doing what was agreed, deciding after a five minute line test that all the stats we have collected don't me anything. O and that crc errors aren't important

Whats your plan of action next ??

[kitz]

PN have been on to BT today about this  & it has been escalated to their Management

I've got the engineer booked for you for 10/08 between 8am and 1pm.

I've made our supplier's management fully aware of the nature of the problem, and am hoping this visit will be productive.

I'm therefore hoping that Saturday brings an engineer who can locate the fault

[sheddyian]

It shouldn't be down to luck but, well.. good luck! 

Ian

[jabns]

Hi all,

Sorry for not posting the graphs. I had to shoot back off to Liverpool and much to my annoyance someone had plugged there own wireless router that was using the same IP as the shared internets router into their ethernet jack at my block off apartments where I was staying. I could not even set the ARP entry manually because I did not know the MAC of the right BT Hub. So I have had no internet for 2 weeks and not been able to VPN into the box doing the graphing  .

I have got the graphs for the last 2 weeks if it will be of any help though Kitz. If so I will post them for you.

Once again sorry for the delays,
James

[kitz]

Cheers James,  not sure if they will help...  I think this is more likely to be a HR fault on my own line as it is ongoing even though Im now off the BE* MSAN.    I'm also pretty sure that after today, this is going to be written off as a no fault found

[kitz]

Copy of the reply Ive just sent to PlusNet

Engineer has just been.   Hes tried various tests but the line appears to be perfectly fine.   This is something that I cant disagree with because the line is behaving itself at the moment.

The engineers tests show that my SNRm is fluctuating and do do so when the phone rings, this can be replicated by the engineer who confirms this on his equipment. 

The result however is that the line (today) passes all normal BT tests and whilst there is a problem on the upstream, as far as BT are concerned, downstream is more of an issue.

During his tests he could see that upstream SNRm was fluctuating between 18dB and 6dbB, but this didnt cause the line to drop, nor did it produced any errors.   

TBH Im not surprised at either of these observations because with an SRNm of 18dB, a loss of up to 13dB isnt going to cause the line to drop... nor would I expect errors to start generating at 6dB..  as you know most lines wont start generating a huge amount of errors until <6dB SNRm or <3dB SRRm (adsl2+) - hence why the Target SNRm is set why it is.

He also tested from the cab, and could see that from there that the same SRNm fluctuations were still occuring, although slightly less.

The engineer reckons that my upstream SNRm is set at 18dB by the DLM to try and stabilise my line - this is the only thing that I disagree with -  Its actually a SURPLUS margin because under good conditions the line is capable of syncing at way more than 20Mbps. 

The engineer was very polite and helpful, I have no complaints about the work he tried to do to try and trace the fault, which obviously is going to be difficult with an intermittent fault.. and because the line was behaving today.  As per normal, an incoming call will always help stabilise the line, and since he called to say he was on his way, then SNRm returned to 18dB  after the call was terminated.   

I fear there is nothing else he could have done today, regrettably I wont be too surprised if in a couple of days it all starts up again as it has done in the past.   BT dont seem to be too concerned because it is only the upstream affected. 





-------------------
PS

An observation is that WOOSH does not appear to have logged all of my Loss of Syncs.  I know 100% that the line has lost sync on occasions yet for some reason these arent being recorded. Why this is Ive no idea...  the only thing I can assume is that very quick resysncs arent caught.   The engineer could see from my uptime here that sync events have occurred, but there isnt anything showing on WOOSH.    The only reason I could think for this is that (like most router monitoring software) it only polls at set intervals and doesnt always catch quick events. 

and something not added in my reply....  but between you guys and me...  I think this case is one of the reasons why BT dont like the EU being able to see their stats....     All I'd know is that my line would intermittently drop out for no reason.  I wouldnt even know that it was only my upstream.   I may eventually put 2+2 together and notice that it occurred during phone calls, but this would likely be at a much later stage when the line would be in a much poorer condition.

[Bald_Eagle1]

and something not added in my reply....  but between you guys and me...  I think this case is one of the reasons why BT dont like the EU being able to see their stats....     All I'd know is that my line would intermittently drop out for no reason.  I wouldnt even know that it was only my upstream.   I may eventually put 2+2 together and notice that it occurred during phone calls, but this would likely be at a much later stage when the line would be in a much poorer condition.

TBH, quite a number of believe that is the MAIN reason that BT had the modems locked down.

I can understand that BT wouldn't want 'meddlers' to mess up otherwise healthy connections by fiddling with settings etc., but I'm sure they could have allowed read only access - a bit like the mileometer, speedometer or temperature guage in a car.

Most 'normal' users will no doubt be blissfully unaware of what actually goes on with their connections & just accept that it is what it is.

[kitz]

>>> but I'm sure they could have allowed read only access - a bit like the mileometer,

Totally agree with you.

----

Ironically if I had still been on adsl2+, they would have had to do something about it by now because my connection would be up and down like [insert common saying]. 

Be's DLM (nor any other adsl2+ DLM)  would not be able to keep hold of a line like this because the line needs a large Noise Margin to remain connected due to the huge variation in NM that Im routinely seeing. 

Its rather unfortunate that the fault only occurred at the time Id requested my MAC to go FTTC.   My SNRm graphs from early in this thread when still on adsl2+ show logs where Id be losing sync many many times in periods of just 1/2 hr.   Moving to FTTC has given me spare margin.. and why the line often holds whilst still being sick underneath.

[kitz]

Question.   Am I wasting time proceeding with this?   Plusnet seem willing to give it another go without me even asking and have automatically sent it back.

Its just the the engineer this w/e implied that Ive nothing better to do with my time than worry about my connection and how it works... which is kind of ironic since I feel like Im running round like a blue ass fly trying to fit everything in atm.

The upshoot is that it does lose a huge amount of upstream when the phone rings (up to 18dB) and it will always lose 2dB of downstream SNRm when on a call.   This was replicated by the engineer but it appears to be classed as a small loss and of no significance because its upstream.     

I fully appreciate that HR faults are hard to trace, so Im not blaming engineers...  but the fact that its an intermittent fault - seemingly worse whent the weather is hot.   Its also not helped that my Loss of syncs arent being picked up on WOOSH, making me look stupid.

The tests that the engineer did last Sat showed nothing much other than being able to replicate the loss of SNRm.   Also why would him simply testing from the cab cause an immediate and permanent loss of 2dB of SNR?

Do I just suck it up and accept that I have a fault and that my line is going to often lose SNRm and drop out...  and wait god knows how long before it fails completely.    Im already starting to use my mobile more often because of the landlines intermittent but unpredictable noise.

Im dreading the thought of another fruitless engineer visit and me looking like a twat/idiot/'someone with nothing better to do'.

[Bald_Eagle1]

Im dreading the thought of another fruitless engineer visit and me looking like a twat/idiot/'someone with nothing better to do'.

I know those feelings far too well 

As one of my very long threads confirms, I experienced almost 11 months of intermittent, but genuine line faults/disconnections/low sync speeds etc.

The symptoms were very similar to yours except it was DS that always took the clobbering & US remained reasonable.
I would very often see DS SNRM drop gradually (during hot/warm & dry weather) or suddenly when using the phone).

The other difference was that as my connection has no spare SNRM due to line length, SNRM would often drop into negative values & cause an almost immediate resync when using the phone & also at other random times, usually at much lower speed.

As the usual engineer line tests etc. invariably resulted in LTOK, it was incredibly difficult to prove there actually was a fault, despite possessing detailed raw & graphical data over a very long period of time.

I even resorted to purchasing a battered Mole TDR tester from ebay which actually confirmed my suspicions of a dodgy joint at the pole mounted DP across the road from my house.

When that fault was EVENTUALLY fixed, I enjoyed around 7 months of perfectly acceptable line stability & sync speeds (30 Mbps DS on around 1000m of D-side line length).

I currently feel in somewhat a similar position again, having seen DS sync speed lowered, in distinct stages, by almost 10 Mbps since December, DS power in the D2 band lowered correspondingly & having a number of LTOK engineer visits.

Fair play to Plusnet, they are still pursuing explanations & a resolution from BTOR.

The latest BTOR comment is that they can do no more to investigate the issue as my connection is stable (true) & performing quite close to estimated speeds (also true - but they seem to conveniently ignore the fact that my speed estimates have been quite recently lowered to not much above 20 Mbps from the achievable 30 Mbps they had been for around 10 months or so).

Good luck with this, don't give in just yet - patience is a virtue 

[sevenlayermuddle]

I fully appreciate that HR faults are hard to trace, so Im not blaming engineers... 

Actually, I think that is quite a charitable attitude.

Having spent my career in telecomms/datacomms (mainly software and not telephony), I can honestly say that few things motivated me more than a seemingly inexplicable and hard to find fault.   The sheer satisfaction of getting to the bottom of a problem that initially seemed unsurmountable is hard to beat.   Or at least, it was always one of my biggest motivations, what a shame so many so called 'engineers' don't seem to see things that way.   

[kitz]

Thanks BE..  I know youve been through the mill twice with BT faults, so you understand how I feel atm.  I dunno how you stood it for months on end.     

>> Fair play to Plusnet, they are still pursuing explanations & a resolution from BTOR.

Yep.... my experience too..  theyve chucked back a few times now saying its not good enough.   My ticket tonight came back saying when are you available for another appt and I inwardly groaned at the thought of going through all the explanations again


>>> I even resorted to purchasing a battered Mole TDR tester

That reminds me, I dont know if he did a TDR test..  apparently the Test Head at the exchange was down and he couldnt complete all of the usual tests. 

BlackSheep - he did a test on the JDSU which showed the upstream SNRm fluctuating between 18-6 dB when the phone rang...  dunno what test that was?   By flipping to another screen it showed FEC/CRCs


>>> my speed estimates have been quite recently lowered to not much above 20 Mbps from the achievable 30 Mbps they had been for around 10 months or so).

and this is what is making me feel bad..  when the line is stable and I dont use the phone then I get a good 80/20.   When its stable it flatlines....  yep straight boring no deviation at all, not even 0.5 dB 
When its playing up I still get 80Mbps down....  its just the upstream which dips from 35Mbps achievable and will sync down to 10Mbps. 

[ColinS]

I can't remember who is responsible for the following paraphrased quotation, but it should be written as a reminder on a card for every fault-finder as a source of encouragement and inspiration

Absence of evidence is not evidence of abscence (of a fault)

[sheddyian]

Question.   Am I wasting time proceeding with this?   Plusnet seem willing to give it another go without me even asking and have automatically sent it back.

I don't think you're wasting your time - it's a fault.  It can be replicated. 

But I understand how frustrating and awkward it can make you feel.

Sometimes there are those situations where you just feel "this isn't right" but you can't explain why to those who say it's all ok, but in your case, you've got graphs 

Regarding BT et al not allowing EU to see stats : I'm mostly in agreement with you on this, although I've been on the other end of things and it can be frustrating.

%%%%Mists of time%%%%
Multi-user VAX/VMS system.  Every month or two there would be a user phoning or visiting in person to complain/accuse (sometimes loudly) that I clearly favoured user x over themselves, because they'd discovered $MONITOR/SYSTEM and it PROVED that user x was getting twice the CPU cycles that they were getting on the shared system and WHY WASN'T IT FAIRLY SHARED.

Telling the user that they should write more efficient code or that their process was waiting on I/O from a physical device more than user x's process was would either enrage them further or send them away quietly fuming to Write A Memo.

We tried education, it had (some) success, but ultimately, leaving the users in the dark (by restricting access to $MONITOR/SYSTEM) was the policy that quietened things down.

Ian

[neilius]

Question.   Am I wasting time proceeding with this?

Not at all, like any enthusiast (and pretty much all of us here if i may be so bold as to speak for them in this instance) you just want the best your line can deliver. Embrace the OCD!