Charging Plusnet for unfixed faults

[#1]

@SteveA,

Whilst what you say has merit, the reality is that the BT infrastructure is not set up to do 10 second interval recording and plotting of SNRM, which is what would be required to profile REIN.

Further the majority of causes of REIN come from within the user's premises, so it's a matter of self help here.  The user needs a solution to THEIR problem, if it is REIN, they are going to need to help themselves, as inevitably if a REIN engineer were called out ... the cause of the interference has a fair chance of not being present at the time of the visit.

Reading between the lines, I suspect that this is an ADSL user, not a fibre user.

[#2]

@Townman - REIN is a problem... oddly enough I was told by the BT Engineer on Visit 1 that REIN does not affect Fibre.... make of that what you will.

Yes detecting intermittent issues is hard to do (I was running routerstats and pingplotter for over a month) but for non technical people is it asking too much? I don't expect to have plug diagnostic tools into my Volvo and drive around with stuff monitoring the whole system just to pick up the occasional misfire....I expect the engine management system to do that and then an engineer can pull the results.

So the BT infrastructure isn't set up... maybe it should be......

[#3]

---

@SteveA wrote:

I don't expect to have plug diagnostic tools into my Volvo and drive around with stuff monitoring the whole system just to pick up the occasional misfire....I expect the engine management system to do that and then an engineer can pull the results.

---

yet that is something that the mechanic will often have to do.
Ie plug in a dongle and go drive about so that stats can be gathered>

engine management will do log fault codes, but won't keep a second by second log of what the engine is doing (or not doing).

so unless you want to let the openreach engineer live in your house for a few days and use your internet, how else will the required data be gathered?

[#4]

---

@chenks76 wrote:

so unless you want to let the openreach engineer live in your house for a few days and use your internet, how else will the required data be gathered?

---

Not a difficult extrapolation using existing and emerging technology.

• Hardware is cheap so adding processing / storage to a router to manage faults is simple.
• TR069 (may needs enhancement) exists to control the I/F
• IoT development is already addressing large scale non priority data flow / management
• Extend SNMP functions to the router to allow NOC (Network Operations Centre) type fault management to collect the data.

I'd love to be back in Network product development - lots of challenges to be met.

M

[#5]

@SteveA,

REIN does not affect fibre - sounds like more BT hogwash!  FTTP I might agree with, but FTTC still delivers an anologue signal over the cabinet to home copper pathway which has the same susceptibility to LOCAL REIN as does ADSL.  Given that VDSL uses a wider frequency spectrum one could suggest that VDSL (FTTC) is logically more susceptible.

[#6]

---

@MauriceC wrote:

---

---

Not a difficult extrapolation using existing and emerging technology.

• Hardware is cheap so adding processing / storage to a router to manage faults is simple.
• TR069 (may needs enhancement) exists to control the I/F
• IoT development is already addressing large scale non priority data flow / management
• Extend SNMP functions to the router to allow NOC (Network Operations Centre) type fault management to collect the data.

---

yes, and watch the tinfoil hat brigade explode into action when they find out routers can log your connection and send it back to "them".

[#7]

@Townman - I'm just telling you what I was told to my face by a BT engineer (who also turned up to investigate a recurring line drop... which was not the fault I'd reported). He said it was because it used a wider and higher frequency.

I'd not want a BT engineer sitting in my house for days - my point is that expecting people who are not tech savy to install software and leaving it running 24/7 to provide data which may, or may not, prove useful to an engineer isn't something that should be expected with something that is being sold as a consumer grade product.

Have BT come in and leave test equipment connected could, and should,  be a possibility... I know my parents had Norweb come in and install monitoring equipment on their mains supply when we were having problems with power fluctuations (It turned out to be caused by a welding company 3 miles away)

[#8]

Happy to hear you're back up to speed @bin

---

@bin wrote:
Engineer didn't do anything.

.....is there anything you want to tell me?

---

There's really no benefit to us with capping your speed. Your service is provisioned on our new network (well, I say new, it's not so new anymore) so the connection profile on your account has little bearing on your throughput.

Moreover, this wasn't a throughput issue. It was a slow sync problem. We have no control over this, except by changing the SNR target which we haven't done since at least I started taking an interest in this fault.

Others have provided possible explanations.

Let us know how you get on, fingers crossed it doesn't drop again.

[#9]

Well, here we are one week down the road. So far so good.

Engineer no 5 left at 12.30, off to next job, no further action - so I know he did nothing to bring about this miraculous repair at 15:15

Obviously it is nice that things have settled down. DSL Stats reports pretty well constant speeds with just slight variations as SNRM wobbles around.

[#10]

That is a potentially worrying statement - is that data speed test variation or synch speed variation?

Data speed variation is to be expected, though it would be rash to associate that with SNRM variation as you do not indicate how much variation you are seeing on SNRM.

Synch rate variation would be worrying as it implies numerous drops in synch which could lead to a progress increase in target SNRM and an associated reduction in synch speed. Though a chore, to be sure of what you are looking at I recommend setting up some detailed monitoring - it's not overly complex. See links below.

[#11]

Current xdsl info as below - SNR down was rock steady at 6.0 till Sunday 11.50am. Up was also solid at whatever it was.

Current variations are only in points - 5.9 to 6.3 down, again only since Sunday when there was a power cut.

There must have been a drop last night as uptime only shows 15 hours. Prior to power cut it didn't drop.

xdsl info expand=enabled
Physical Layer Statistics:        

  Modem state:                           up
  Up time (Days hh:mm:ss):               0 days, 15:32:28
  xDSL Standard:                         ITU-T G.992.5
  xDSL Annex:                            Annex A
  Channel Mode:                                Interleaved

  Number of reset:                       4

  Chipset Vendor info (G.994.1):            Local         Remote
    Country code:                           B500          B500
    ID:                                     BDCM          BDCM
    Specific:                               0000          A3A7

  System Vendor info (showtime):          Local         Remote
    Country code:                         0F00          0000
    ID:                                   TMMB          ----
    Specific:                             3C61          0000

  Bearers generic info                    DS             US       
    Payload rate [Kbps]:               6551        1239   
    Attenuation [dB]:                  35.5           19.9           
    Margins [dB]:                      6.1            7.3            
    Output power [dBm]:                19.8           12.0           

    Number of bearers:                   1
    Bearer 0                             DS             US       
      INP [DMT symbols]:                 0.00           0.00           
      Delay [ms]:                        0.24           0.24           
      Depth []:                        1              0.00
      R:                               0             0       

G.997.1 Statistics (Current):        

  Failures:
    Line failures                            Near end
      Loss of signal (LOS):                 4       
      Loss of frame (LOF):                  35      
      Loss of power (LPR):                 0       

  Performance monitoring:
    Line PM:                             Near end
      Error second (ES):                  1493    

    Channel PM:                         Near end     Far end
      Bearer 0:
        Code Violation (CV):             2161         4021    
        FEC:                             0            0       

    ATM data path PM:                     Near end     Far end
      Bearer 0:
        HEC violation count (HEC):            4538         N/A

G.997.1 Statistics (last 15 minutes):        

  Failures:
    Line failures                            Near end
      Loss of signal (LOS):                 0       
      Loss of frame (LOF):                  0       
      Loss of power (LPR):                 0       

  Performance monitoring:
    Line PM:                             Near end
      Error second (ES):                  0       

    Channel PM:                         Near end     Far end
      Bearer 0:
        Code Violation (CV):             2161         4021    
        FEC:                             0            0       

    ATM data path PM:                     Near end     Far end
      Bearer 0:
        HEC violation count (HEC):            4538         N/A

G.997.1 Statistics (last 24 hours):        

  Failures:
    Line failures                            Near end
      Loss of signal (LOS):                 4       
      Loss of frame (LOF):                  35      
      Loss of power (LPR):                 0       

  Performance monitoring:
    Line PM:                             Near end
      Error second (ES):                  1470    

    Channel PM:                         Near end     Far end
      Bearer 0:
        Code Violation (CV):             2161         4021    
        FEC:                             0            0       

    ATM data path PM:                     Near end     Far end
      Bearer 0:
        HEC violation count (HEC):            4538         N/A

{admin}=>

I'll leave DSL Stats running today and see what happens.

[#12]

Happy to hear your speed is consistent.

Let us know if things change.

[#13]

5.9dB to 6.3dB variation between day light (6.3) and night time (5.9) hours is not unreasonable - this arises from AM transmission interference which is more pronounced after dark.  Providing there is no loss of synch you will not see a change in SYNCH speed from this variation, though you might see a small change in data throughput speeds.

What does remain of some concern is the cause of the drop.  A single short spike of electrical noise could cause the link to drop.  Have that repeat often enough and the DLM will raise the target SNRM and you'll be back to slow speeds.  To discern spike events I recommend a stats logging / sample interval of 10 seconds.  That ought to be fast enough to catch REIN events likely to bring the synch down.

Note one of the big issues with DSL stats is that it repeatedly logs on and off the router, thereby filling up the router log - this has been known to obliterate useful information recorded in the router log file and is one of the reasons I recommend Router Stats instead.

[#14]

Interesting - running Router Stats 6.9 under Wine - we'll see how it goes.