cancel
Showing results for 
Search instead for 
Did you mean: 

REIN trouble (mostly fixed)

ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: REIN trouble (DLM strangely inactive)

Fortunately the interference is no longer slowing the broadband to a crawl. It's still possible to tell when it starts and stops from the stats, it can still be heard with an AM radio, but otherwise wouldn't be noticed. Either the BT line tests knocked some sense into the DLM interleaving settings, me opening the junction box moved the wiring (it does spill out a bit on removing the cover) which improved the situation, or the source of the interference was moved, fixed, or has an marginally faulty component which got a little better on its own.
Edit: I did think to check wifi uptimes, which can be seen from scan results, which didn't reveal anything. Mostly surrounded by BTHub3 units, but the nearest neighbour probably has a sky adsl router as old and similar to my netgear.
ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: REIN trouble (DLM strangely inactive)

Graphs from Monday and Tuesday mostly more of the same really, the FEC errors show when the interference is on. Except on Tuesday, presumably one of the big noise spikes was big enough or lasted long enough to cause a re-sync, from 3558 / 708 to 3562 / 612.
ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: REIN trouble (DLM strangely inactive)

The interference presumably wasn't present on Wednesday and Thursday. The enormous burst of noise at around 20:30 Thursday can't have been the source of the interference exploding because it appeared to be back on at 13:20 on Friday and continued throughout the evening. There was an anomalous reading for the upstream noise margin of 49.4 at 15:23 on Friday.
The interference no longer has any significant impact on the broadband besides the stat graphs. It may have been fixed by:

  • The maximize INP tweak actually did something.

  • Removing the cover of the junction box to take the photo moved some wiring.

  • The line test on Friday did something to the interleaving settings.

  • Something else entirely, maybe the source of the interference was moved, fixed, shielded better, or a marginally faulty component got a bit better by itself.


Some of the theories don't quite tie in to the time the problem went away or the fact interference is still detectable with an AM radio.
ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: REIN trouble (mostly fixed)

Just for comparison, here's how a thunderstorm looks on the graphs in 20130723 02:00 - 04:00 (the interference starts at about 17:00).
ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: REIN trouble (mostly fixed)

Our telephone line went completely dead (phones didn't ring, no dial tone, although broadband still worked) earlier this week. It was fixed on Thursday. It wasn't me who was home when the openreach engineers visited, but the old grey Post Office Telecoms external box was replaced with a similar shape and size beige BT plastic box. Apparently there was also a "massive" fault at the exchange.
At 7am yesterday I decided to remove the +2db extra noise margin tweak, returning closer to the default settings of the netgear, which might have been bad timing as that might have been the time the interference started up. This resulted in a slightly higher speed, but also about 49618 error seconds out of 86400, 58%, which probably isn't very good.
[tt]AR7 DSL Modem Statistics:
--------------------------------
[DSL Modem Stats]
       US Connection Rate:     684     DS Connection Rate:     3814
       DS Line Attenuation:    60.7    DS Margin:              6.0
       US Line Attenuation:    37.1    US Margin:              5.0
       US Payload :            115972512       DS Payload:             1354765344
       US Superframe Cnt :     5126747 DS Superframe Cnt:      5126747
       US Transmit Power :     0       DS Transmit Power:      0
       LOS errors:             0       SEF errors:             0
       Errored Seconds:        49618   Severely Err Secs:      3494
       Frame mode:             0       Max Frame mode:         0
       Trained Path:           1       US Peak Cell Rate:      1613
       Trained Mode:           16      Selected Mode:          1
       ATUC Vendor Code:       54535443        ATUC Revision:  3
       Hybrid Selected:        3       Trellis:                1
       Showtime Count:         1       DS Max Attainable Bit Rate: 4088 kbps
       BitSwap:                1       US Max Attainable Bit Rate: 1089733 bps
       Annex:                  AnxA    psd_mask_qualifier: 0x0000
       Power Management Status: L0     DS HLINSC: 0
       US ACTPSD:              -345    DS ACTPSD: -366
       Total init. errors:     0       Total init. timeouts: 0
       Showtime init. errors:  0       Showtime init. timeouts: 0
       Last showtime init. errors: 0   Last showtime init. timeouts: 0
       ATUC ghsVid:  b5 00 54 53 54 43 05 10
       T1413Vid: 00 00         T1413Rev: 00            VendorRev: 00
       ATUR ghsVid:  b5 00 54 53 54 43 00 00
       T1413Vid: 00 00 T1413Rev: 00    VendorRev: 00
       [Upstream (TX) Interleave path]
       CRC:    21      FEC:    330980  NCD:    0
       LCD:    0       HEC:    23
       [Downstream (RX) Interleave path]
       CRC:    295027  FEC:    149536316       NCD:    0
       LCD:    0       HEC:    0
       [Upstream (TX) Fast path]
       CRC:    0       FEC:    0       NCD:    0
       LCD:    0       HEC:    0
       [Downstream (RX) Fast path]
       CRC:    0       FEC:    0       NCD:    0
       LCD:    0       HEC:    0
[ATM Stats]
       [Upstream/TX]
       Good Cell Cnt:  2416094
       Idle Cell Cnt:  138182524
       Tx Packets Dropped Count:       0
       Tx Bad Packets Count:   0
       [Downstream/RX)]
       Good Cell Cnt:  28224278
       Idle Cell Cnt:  755659010
       Bad Hec Cell Cnt:       177531
       Overflow Dropped Cell Cnt:      0
       Rx Packets Dropped Count:       0
       Rx Bad Packets Count:   0

[SAR AAL5 Stats]
       Tx PDU's:       705663
       Rx PDU's:       1014576
       Tx Total Bytes: 81815268
       Rx Total Bytes: 1299389505
       Tx Total Error Counts:  0
       Rx Total Error Counts:  17973
[/tt]
ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: REIN trouble (mostly fixed)

Edit: at 10:37 the DLM put the SNRM up by 3 before I got around to putting it back up by 2.
ReedRichards
Seasoned Pro
Posts: 4,927
Thanks: 145
Fixes: 25
Registered: ‎14-07-2009

Re: REIN trouble (mostly fixed)

I have quickly scanned through this thread and I cannot see how your REIN problem is "mostly fixed".  But there was a big gap between your latest posts and previous ones.
I have REIN problems at the moment which started a few weeks ago, almost as soon as new neighbours moved in to the house next-door-but one.  The REIN has settled into a pattern where the source is on for an hour or two in the early morning and again for a similar time period in the late evening but exact timings vary from day to day.  Sometimes it is on during the day also, but not too often.  Today is a Sunday and they haven't switched it on yet, which is unusually late - must be having a lie-in.  I am running Routerstats 24/7 on my computer and the transitions, which typically add about 4dB of extra noise, are very obvious.  I have wandered round my house and my area with a MW radio when the noise source is on and when it is off so I could tell you what I experienced.  I have approached my neighbours but they rapidly became defensive at the notion that something in their house could be causing a problem.  Oh, and just before they moved in they had their guttering replaced, which would have scared-off any birds nesting on the roof!
Anyway, I would be happy to compare notes if you wish.
ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: REIN trouble (mostly fixed)

At the end of June, when the interference started, the broadband was almost completely unusable, impossible to load a single webpage due to 80% or so packet loss. The microfilters were changed, and a 582n was given a go, which dropped the connection like a hot potato. Later, for some uncertain reason, the interference is still present but hardly affects things besides making the stat graphs look bad.
After openreach re-did the connections for the star wiring on Thursday, to fix the telephone, I made the mistake of seeing if I could stop increasing the noise margin by 2. While the broadband was completely unusable, obviously the DLM was happy to sit around doing absolutely nothing. But after 27 hours of being connected at 3814k, the DLM decided that was too fast, and decided it needed to jump in and fix that, and slow things down, by increasing the noise margin by 3.
The noise margin will probably go back down after a couple of weeks if I leave things alone, and hopefully the interference will have gone away by the end of September anyway.
ReedRichards
Seasoned Pro
Posts: 4,927
Thanks: 145
Fixes: 25
Registered: ‎14-07-2009

Re: REIN trouble (mostly fixed)

My line worked very happily for 2 years with a target noise margin of 3dB, even at night when the reported noise margin could drop to 0-1dB.  Then I had a telephone line fault and the DLM pushed the target noise margin up to 6dB.  Before I got around to having it set back to 3dB again the noise source moved in.  Now when the noise source is on my connection is more-or-less unusable when the noise margin reads 3dB.   This must mean there is noise and there is bad noise (/interference) which is worse.  To keep  my internet going at all times I have to resync my router when the noise source is on.  If I need some speed for a large download I have to resync the router when the noise source is off.  It is very annoying but I am saved by the fact that I rarely need my full bandwidth.
My noise source might go off to university at the end of September - I am very much hoping so.
ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: REIN trouble (mostly fixed)

There's an odd behaviour of the upstream in the graphs from the 8th and 10th, there have been a couple of times when a phone call has interrupted the broadband, but not always. Anyway, the utterly-useless-in-every-regard DLM decided to stop being mean on the 12th.
ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: REIN trouble (mostly fixed)

Strangely I'd never tried setting ADSL2 mode rather than the default auto which results in ADSL2+. Yet it made a surprisingly large difference, besides calculating the attenuation differently, it stops the low bit loading of the first few downstream tones, and most of the upstream tones:
[tt]US Connection Rate:    882    DS Connection Rate:    3678
DS Line Attenuation:    58.6    DS Margin:              6.0 (+2)
US Line Attenuation:    36.9    US Margin:              5.2
[/tt]
nanotm
Pro
Posts: 5,756
Thanks: 156
Fixes: 2
Registered: ‎11-02-2013

Re: REIN trouble (mostly fixed)

it also changes the default behaviour of INS circuits....2+ just doesn't work great in any situation where there's electronic noise at certain frequencies, and given the numbers of people experiencing the same problems it has to be something to do with the backhaul equipment being damaged by cable damage induced surges, if that is truly the case then the faster BT get all the old copper swapped out for something with zero scrap value the better, its not as if there fast at getting things replaced or repaired never mind the extra troubles being caused by malicious damage
just because your paranoid doesn't mean they aren't out to get you
ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: REIN trouble (mostly fixed)

I'm not really sure what you mean by "impulse noise suppression" or that it even exists as such. There is:
INP = Impulse Noise Protection
INM = Impulse Noise Monitoring
INS = Impulse Noise Sensor (according to the ITU G.992.3 PDF)
SuperZoom
Grafter
Posts: 353
Registered: ‎17-05-2013

Re: REIN trouble (mostly fixed)

I think nanotm is just having a bit of fun posting nonsense all over these forums.
There's no harm so long as nobody takes it seriously.
Post #25 in the YouTube thread was a bit of a classic too.
The clue, if one were needed(!) is in the studious shunning of sentence case - that's what the Millennium Dome Experience content designers did to show they were taking the Michael too  Grin
SuperZoom
Grafter
Posts: 353
Registered: ‎17-05-2013

Re: REIN trouble (mostly fixed)

Oh, and you're right about ADSL2 - I found it to be a lot more stable on a noisy line than 2+.