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] 3

Author Topic: newt and engineer  (Read 13000 times)

Ixel

  • Kitizen
  • ****
  • Posts: 1282
Re: newt and engineer
« Reply #15 on: February 14, 2015, 01:48:07 AM »

G.INP isn't enabled, interesting as depth is indicative.
Logged

WWWombat

  • Kitizen
  • ****
  • Posts: 1674
Re: newt and engineer
« Reply #16 on: February 14, 2015, 03:14:40 AM »

The thing that stands out is DLM has set 0 for the INP values, but 1 for delay - allowing 1ms both up & down.

You then have both FEC and interleaving active in both directions, but relatively weakly.

Downstream: FEC is 10/254, or 4% and interleaving is 17*254.
Upstream: FEC is 16/254, or 6% and interleaving is 8*127

Quite different from a normal reset...
Logged

Black Sheep

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5722
Re: newt and engineer
« Reply #17 on: February 14, 2015, 09:03:41 AM »

Can you talk us through what actually happened, NS ?? We're not supposed to 'just do resets' without first finding a fault. I have my own thoughts on that, but I like to think I do as good a job as I can ?  :)

He must have at the very least carried out a PQT, as this is mandatory on any kind of BB fault, be it ADSL or VDSL.

BS didnt you say you have done resets before starting the job to stop it affecting test results?If newt had a reset it didnt last long.

Yes I did.

The problem with having an engineering workforce our size (circa 20k), the protocols fed down from above have to applied in generic terms. They have to take into account every engineer ..... and as we all know, that is quite a spectrum.
Hence the, 'Do not perform a DLM reset unless you have found a fault', briefing.
My own personal view of why this was introduced, is because certain engineers were performing a reset before attending site, and 'voila', when he ran his tests in front of the EU ..... a perfect working circuit !! As we all know, days later the EU would be re-reporting the circuit and the 'stats' were revealing the true picture.

However, I like to think I have half-a-brain and as the engineer attending site I make my own decision as to whether or not I perform a reset before I attend site, based upon 28-day retrospective vision of the circuits performance (using our WHOOSH tool), along with local knowledge of the network etc.

The problem with not re-setting the circuit is, it can mask what is really happening by way of CRC's, ES, FEC, speed, stability .... and to the untrained eye a heavily stabilised circuit can appear to be working just fine.
Coupled with the fact that most engineers will only at a push use WHOOSH 'Summary' data, rather than delve into individual parameters (SNR, Attenuation, Loss-of-link and so on), the same heavily stabilised circuit will again appear to be working just dandy.

The 'Summary' screen shows every hour of the day over a 28-day period, and depicts the ILQ (Indicated Line Quality) for that hour by various colours ...... from green (good) to red (bad). The heavily stabilised circuit will be a sea of green, and again to the untrained eye, will give the impression of a great circuit.
At this point I hasten to add, our WHOOSH training courses are woefully, and I mean woefully inadequate !! You guys know how difficult it is interpreting graphical data .....  ;) We get a couple of hours tuition from someone who has probably never used it in anger, and has a set format to how it's rolled out. It's only by 'Playing with it' (oo-er missus) that I've got to grips with it to a fashion.

So, long story short ...... I (and I suspect other similar engineers), will perform a rest before attending site. I have never been pulled up for this, and I welcome the higher echelon to prove what I am doing is incorrect.  ;) ;D

Back to NS's problem though ....... I'm still struggling with the fact that the engineers JDSU wouldn't work at the extension socket, but would at the master socket ?? It would imply that due to the sensitive nature of our JDSU's that this may be the problem with NS's circuit ??
Logged

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: newt and engineer
« Reply #18 on: February 14, 2015, 12:28:01 PM »

Back to NS's problem though ....... I'm still struggling with the fact that the engineers JDSU wouldn't work at the extension socket, but would at the master socket ?? It would imply that due to the sensitive nature of our JDSU's that this may be the problem with NS's circuit ??

Yes it was a pitty the JDSU didnt sync from the RJ11 plug on the data cable as it's just 10 meters of CAT5e with a RJ45 and RJ11 at each end the cable is marked as Excel 100-060 cat 5e cable white ISO11801 4 pair 24AWG ETL verified 305m (2014/09)

I know nothing about JDSU's BS so maybe if you get time to run a simulated test on this type of cable on your JDSU.

at the moment i'm in limbo the SNRM swing is going in the right direction 6+dB yet the errored seconds just seem to high looking forward to 3rd day (DLM SUNDAY  ;D)
Logged

les-70

  • Kitizen
  • ****
  • Posts: 1254
Re: newt and engineer
« Reply #19 on: February 14, 2015, 12:41:26 PM »

   The DLM situation is not obvious.   If you were on Plusnet you would be fine and running at about half the limit of 2880 ES/day.  You show up on MDWS as BTW, maybe that is just BT.  For BT I don't think the limit is established.  It may be 2880 but I recall comments that it is the standard profile,, like TT and 1440ES/day.  For the 1440 some DLM action looks possible but marginal.  If it increased the interleaving just a small bit more you should then have an OK ES rate still be close to fast path.  Whatever the cause of your very low interleaving rates they are very encouraging if they are a new face to the DLM.
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7388
  • VM Gig1 - AAISP L2TP
Re: newt and engineer
« Reply #20 on: February 14, 2015, 02:32:58 PM »

If newt had a reset it didnt last long.

Chry the DS interleaving depth went straight to 17 after reset  :-\

then it wasnt a proper reset in my view.

Is totally bizzare, as a reset should have took you to fast path.
Logged

Black Sheep

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5722
Re: newt and engineer
« Reply #21 on: February 14, 2015, 03:45:12 PM »

The line has either been reset, or it hasn't ....... there are no 'levels' as such.
Logged

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: newt and engineer
« Reply #22 on: February 14, 2015, 05:23:39 PM »

Is totally bizzare, as a reset should have took you to fast path.

I just don't know why after a reset it's ended up like this the line must have a lot of noise on it as you would expect with a local loop length of 1000 meters and this is as close to fastpath as i'll ever get.
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7388
  • VM Gig1 - AAISP L2TP
Re: newt and engineer
« Reply #23 on: February 14, 2015, 07:00:33 PM »

The line has either been reset, or it hasn't ....... there are no 'levels' as such.

the post doesnt explain anything.

Why did he have FEC on the downstream immediatly after a reset?
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: newt and engineer
« Reply #24 on: February 14, 2015, 07:24:42 PM »

Why did he have FEC on the downstream immediatly after a reset?

I can accept that the DLM reset status is binary . . .

To answer the above question, I pose another. In the time taken for everything to be reconnected and circuit statistics gathering to be restarted could the DLM have already taken action?

And isn't there a possibility of having FECs on "fastpath"?  :-\  I think B*Eagle1 has observational data that supports the case. 
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: 7388
  • VM Gig1 - AAISP L2TP
Re: newt and engineer
« Reply #25 on: February 14, 2015, 07:29:02 PM »

yes he is on fastpath with FEC's and we already know its possible.

But this is the first case I am aware off where someone has it immediately after a reset.
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: newt and engineer
« Reply #26 on: February 14, 2015, 07:33:16 PM »

Agreed.

But let's regard it as a valid observation until proven otherwise. Not to do so would imply that N*Star has "committed a folly"!  :)
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.

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: newt and engineer
« Reply #27 on: February 14, 2015, 07:42:48 PM »

To answer the above question, I pose another. In the time taken for everything to be reconnected and circuit statistics gathering to be restarted could the DLM have already taken action?

The reset was the last thing the engineer did before we waved each other goodbye, kitz said the DLM should be wide open for 2 days after a reset it still gathers data but will not act on this until the 3rd day but she did say if the errors were really bad the DLM will take action straight away, don't quote me on this it's all coming from my grey matter running at 1 billion MHZ  :P
« Last Edit: February 14, 2015, 07:53:27 PM by NewtronStar »
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: newt and engineer
« Reply #28 on: February 14, 2015, 09:14:54 PM »

Yes, I agree with that stated action plan.

The behaviour of the fibre DLM process in the first few days following the provision of the service is actually spelt out in one of Beattie Bellman's many SINs . . . Section 2.2.1 on page 16 of SIN498:)

Clearly your circuit is behaving somewhat differently, perhaps a "corner case".
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: 7388
  • VM Gig1 - AAISP L2TP
Re: newt and engineer
« Reply #29 on: February 14, 2015, 09:38:34 PM »

yeah so I can think of 2 possible reasons.

newt's line was extremely bad when it first reconnected and DLM considered it an urgent change. (as bcat said)
or
the default profile for long D sides is different to the default profile for short D sides.
Logged
Pages: 1 [2] 3
 

anything