Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: 1 [2]

Author Topic: Advice please on dealing with OR  (Read 9829 times)

bbnovice

  • Reg Member
  • ***
  • Posts: 267
Re: Advice please on dealing with OR
« Reply #15 on: January 10, 2014, 05:53:16 PM »

A bit of a digression but I thought you might be mildly interested in the attached graph.
 
In anticipation of the arrival of the OR broadband engineer tomorrow I plotted the IP Profile/Speed statistics from the BT wholesale speed checker to demonstrate the speed I would expect to achieve from my connection. I had been intemding to do this for a while.

This is the first time I have plotted this data and I was surprised to see how it appears to demonstrate that the Home Hub 4 maintains a much more consistent connection than the HH3 from a speed perspective.

Nothing earth shattering but may be of interest to anybody planning to splash out £35 with BT to upgrade the HH3 to the HH4.

Regards     

     
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Advice please on dealing with OR
« Reply #16 on: January 10, 2014, 08:33:35 PM »

That is certainly an interesting graph. It clearly shows a significant difference between the two versions of the BT Home Hub and the recent degradation as a result of the network infrastructure fault.

Today's visit was by a (telephony) network engineer to fix the infrastructure fault, whilst tomorrow's visit will be by a broadband engineer (possibly "boost" or SFI) whose only task will be to confirm that the infrastructure is fault-free and to request a re-train of your circuit . . . something the network engineer would not have been able to do today. Crazy situation!  :-X

Assuming that tomorrow's engineer will have access to the notes from earlier today, then it should be perfectly straightforward. Especially if you show her/him your above graph.  :)
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

waltergmw

  • Kitizen
  • ****
  • Posts: 2776
Re: Advice please on dealing with OR
« Reply #17 on: January 11, 2014, 08:55:02 AM »

@ BBn,

May I congratulate you on an excellent set of records and also the BT Openreach engineer for being so persistently thorough and open with his findings.

This record shows what an impossible long-term task faces us all with the national infrastructure.

I have often wondered on the need for the tri-wire crimps, except for bridge tap connections necessary for line protection units.
As well as a water ingress point when left open, they readily provide a mechanism for crossing pairs etc.
(However a tri-wire connection does provide an engineer's monitoring point without disturbing the actual line connection.)
These crimps, along with the significant number of corroding "Blue Bean" crimps still in service long after they were condemned, must surely be responsible for major line reliability impediments.

These situations, along with the threats (or promises ?) of end-user charges and the hideous difficulties in communicating efficiently with those indirectly involved in maintenance and repair operations must surely be having a major impact on the viability of the entire broadband and telephone network ?

Kind regards,
Walter

Logged

bbnovice

  • Reg Member
  • ***
  • Posts: 267
Re: Advice please on dealing with OR
« Reply #18 on: January 11, 2014, 02:44:12 PM »

Thanks Walter.

Funnily enough, your point was reinforced by the broadband engineer who visited today. He was 3 hours late, but had just come from a job for a Sky customer the resolution of which took 6 hours. DSL connection was present and correct but internet pages would not load. Sky said it was an OR problem. The OR SMC said the connection was good and that it was a Sky problem, the onsite OR engineer's test kit reported no faults. Many hours later (with the customer and the onsite engineer stuck in the middle of this conundrum) a port change fixed the problem. So it was an OR network problem. But the deficient equipment continues to check out OK. So whats wrong where?

The test kit obviously has limitations, and that's not comforting when considering the new BT policy of trying to charge the EU if no fault found anywhere.   

I think he was glad of my job as a rest cure. Quick test with the JDSU. 100% error free. Yesterday's PSTN engineers work yesterday is obviously good. DLM reset and I'm immediately back to the same throughout as before the PSTN fault.
   
Until the next time.......

       
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Advice please on dealing with OR
« Reply #19 on: January 11, 2014, 03:26:36 PM »

Success!  :thumbs:
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: Advice please on dealing with OR
« Reply #20 on: January 12, 2014, 12:19:27 AM »

yeah you had a good engineer who lucky for you overuled the tests that were passing.  glad you got it sorted in the end, I am curious why so often port changes improve things.
Logged

BritBrat

  • Kitizen
  • ****
  • Posts: 1359
Re: Advice please on dealing with OR
« Reply #21 on: January 12, 2014, 09:05:54 AM »

A bit of a digression but I thought you might be mildly interested in the attached graph.
 

What did you record the graph with?

Could it be JD speed tester?
Logged

bbnovice

  • Reg Member
  • ***
  • Posts: 267
Re: Advice please on dealing with OR
« Reply #22 on: January 12, 2014, 03:41:48 PM »

A bit of a digression but I thought you might be mildly interested in the attached graph.
 

What did you record the graph with?

Could it be JD speed tester?

Data is from the BT Wholesale Speed Test site, plotted as a chart using EXCEL 2010
Logged

Black Sheep

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5717
Re: Advice please on dealing with OR
« Reply #23 on: January 12, 2014, 06:46:46 PM »

Thanks Walter.

Funnily enough, your point was reinforced by the broadband engineer who visited today. He was 3 hours late, but had just come from a job for a Sky customer the resolution of which took 6 hours. DSL connection was present and correct but internet pages would not load. Sky said it was an OR problem. The OR SMC said the connection was good and that it was a Sky problem, the onsite OR engineer's test kit reported no faults. Many hours later (with the customer and the onsite engineer stuck in the middle of this conundrum) a port change fixed the problem. So it was an OR network problem. But the deficient equipment continues to check out OK. So whats wrong where?

The test kit obviously has limitations, and that's not comforting when considering the new BT policy of trying to charge the EU if no fault found anywhere.   

I think he was glad of my job as a rest cure. Quick test with the JDSU. 100% error free. Yesterday's PSTN engineers work yesterday is obviously good. DLM reset and I'm immediately back to the same throughout as before the PSTN fault.
   
Until the next time.......

       

No, it wasn't an OR Network fault it was an equipment fault, two completely different things I'm afraid.

I've had the same scenario as you have had just a couple of times, whereby to all intents and purposes the tester/modem is 'talking' to the DSLAM and passing data error-free, but the EU can't access web-pages. Protocol is to contact OR's Helpdesk and request our side of the circuits 'Build' details, which are the C-Tag and S-Tag parameters. We then get passed to BT Wholesale who confirm these parameters against their side of the 'Build'.

On both occasions, the 'Build' was correct. The only way we found to solve the issue was to perform a 'Lift & Shift' (New port) to a completely different card. Even porting to a 'Spare' on the same card didn't work. These were both ECI vendors as well I might add.
The problem, along with other issues, was found to be the V-TUC cards in the VDSL Cabinet that ECI had provided. Their latest firmware upgrade appeared to be incompatible with the V-TUC V3 cards, and so a programme was put in place locally to swap out all these cards for the V-TUC V2 cards. I actually rode shotgun with the guy that did it, and umpteen issues we had went away overnight. The very same card situation had also caused major problems in York, the ECI engineer told me, as he had been there the week before doing 'Swap outs'.

   
Logged
Pages: 1 [2]