Print

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

[dgilbert2]

@re0 I appreciate your help this weekend, thank you 

At the end of the day I think my only option was to cap and see what happens anyway. I'll post back with any developments 

[dgilbert2]

I have now removed the cap as no DLM activity was triggered and now I'm still where I was, ie Fast Path, no DLM "interest".

I guess all I can do is wait, even longer, to get back to my old connection performance prior to supplier migration.

Nothing more to do?

[re0]

I am afraid I cannot offer much more insight into this.

All I know is that for myself it took approx. 1 month of the line being activated before G.INP was finally activated.

As I stated before in one of my earlier posts:

I know that on my line (on the Standard profile, as opposed to Speed which you are on), in reference to Mean Time Between Errors (MTBE) and Mean Time Between Retrains (MTBR), it was pretty much always in the Amber/Green for Downstream MTBE, Green for Upstream MTBE, and MTBR was mostly in the Green here (except when my router decided it wanted to reboot itself 3 times in a short space of time).

I think my line suffered from sudden bursts of errors prior to this, which encouraged the DLM to hurry up and enable G.INP. Though I had never noticed them impacting the service nor causing the MTBE to exceed the thresholds leading to corrective measures. Indeed, they were very minor when looking at the bigger picture.

[dgilbert2]

I have finally had G.INP applied to my line again - only taken nearly 6 months 

I am surprised that its also been applied to the upstream!? I was not expecting that, as I thought BTOR has disabled it for upstreams.

What triggered it though? In the last 1-2 weeks I've been using a power supply in the "next room" to the router. This was causing errors on the downstream which caused interleave to come on. Until then I had been on Fast Path. This additional noise, which was only for a few hours a day, seems to have triggered it. I could not have planned this, I was aware of the "new" errors but I could do nothing about it as I have to use this other power supply for other interests. If fact, it was concerning me as I knew the errors were now appearing, but its proven to be a bonus!

Hope G.Inp stays when I stop using the offending power supply 


                                  Downstream   Upstream
Line attenuation (dB):     19.8      0.0
Signal attenuation (dB):   Not monitored     
Connection speed (kbps):   56666      16740
SNR margin (dB):           6.1      6.1
Power (dBm):               13.1      7.4
Interleave depth:          8      4
INP:                             48.00      45.00
G.INP:                      Enabled      Enabled
Vectoring status:          5 (VECT_UNCONFIGURED)

[re0]

AFAIK, G.INP on the upstream is not disabled where it is needed; it will be activated providing the modem supports it and the DLM sees a need for it. Although, a rare occurence it is to see it on the upstream. It was disabled for a period of time due to modems not supporting G.INP.

It would be interesting to see your error statistics over this time period so the MTBE can be calculated.

Can't say about the upstream staying, but on the downstream usually sticks around from experience.

[adslmax]

I have finally had G.INP applied to my line again - only taken nearly 6 months 

Six Months for G.INP to be applied? Blimey cor me! That's half a year to wait!

[skyeci]

wow.. 6 months. my mum's line just had a full port swap and was back on open profile, with no g.inp and reduced sync after the work was done. It only  took 2 days for g.inp to be applied to the DS. Dlm has already started applying the lower snr too so all very quick to return the line to how it was.