Remote Analysis of Disconnections? (Hull, not Plusnet!)

[#1]

Hi Chaps,
I'm in the unenviable position of trying to work out why my parent's ADSL connection keeps dropping... remotely. It's made a little more awkward by being on Hull's telephone network, using the local Karoo ISP.
I have been reading up on here (PN is my ISP, and I find this place one of the more helpful), and the information on kitz.co.uk. I've employed RouterStats (some use), DMT (currently no use), and my own logging through "Cacti", which grabs the line statistics every 5 minutes - provided the line hasn't disconnected and re-assigned an IP address.
Can anyone offer either form of advice... what can I do to better monitor & adjust things remotely? And what should I have on my list of things to do when I visit?
The best description of the problem is: The ADSL connection disconnects frequently between (roughly) 6pm and 9pm. It has been doing this noticeably since Christmas, but may have been happening some time before. However, it used to be perfectly stable around a year ago, on MaxDSL, at roughly 7Mbps. We just found out that Hull upgraded their exchange kit to ADSL2+ sometime in summer/autumn last year, so I'm wondering if that may be part of the problem.
When I first got my Mum to monitor the line stats (in January), we were getting:

Sync: 6700-7100 down, 510 up.
Noise: 3-4db down (dipping lower frequently, raising to 6 occassionally)
Attenuation 46 down, 14.5 up.

Back then, we'd get more disconnections, but we weren't doing enough to systematically monitor the line, so can't be sure of the exact scale of the problem.
Karoo's first attempt to "fix" the problem had the effect, I guess, of raising the target noise margin. Their line-testing equipment reported 3 faults "outside the property", so they arranged for Kingston Communications to visit, but saying that they wouldn't need access to the property. Unfortunately the engineer turned up when only my dad was home - who isn't clued up on technology at the best of times - so we only have a vague report on what happened.
Apparently he discovered "one of the wires touching the wall" causing an earth problem, and made an adjustment... Certainly the ADSL modem noticed, as it started to sync at 1021 upstream, but only 5114 downstream - but at least it was now consistent at those sync speeds. After this, the disconnections still happened, but were now more restricted to the early evening period - usually between around 6pm and 9pm.
A new report to KC got another engineer, but he reported that they could find no further fault.
Current setup & statistics are:

Router: Netgear DG834Gv3, Firmware V4.01.06 
Attenuation: 46db downlink, and 14.5 uplink
Noise Margin: Downlink: 10-13db overnight (00am - 8am)
                        13-15db during daytime (8am-4pm)
                        10-13 at end of daytime (4pm - 6pm)
                        8-10db late evening (9pm - midnight)
              Uplink: 7-10db

It's hard to see what the downlink noise margin is between 6pm and 9pm, because of the disconnections . I think the general trend is to continue a slow downward trend seen earlier, to a low point around 9pm - but the 5 minute gaps between checks probably misses many of the slumps.
We've tried to get RouterStats to generate graphs - which is does reasonably well. However, it also regularly locks my Mum's computer, and loses the data, so isn't much use for gathering data that *I* can see..
I've also tried DMT to get more SNR information out, but it isn't compatible enough with the DG834Gv3 (or at least the firmware currently on there).
So I'm monitoring the line from my own server - which grabs data every 5 minutes (so doesn't catch many of the fluctuations in noise margin) - but suffers losses at the time of the disconnections due to dynamic IP and a less than perfect DynDns client in the router). Some example graphs are attached.

We've already tried a number of things to try to either diagnose or rectify, but it's a bit difficult getting my Mum to sort out what I'masking for:
- Karoo attempted something from their support desk. From the line statistics, I'm guessing that they increased the target noise margin.
- KC have sent an engineer around, who fixed the line, and made some improvements
- Disconnecting other equipment from the socket
- Using alternative filters
- Turning off heating etc, to see if it caused interference
Things I plan to do when I visit:
- Try another modem/router. I have a Belkin ADSL 2+ box sitting idle at the moment, but I'm not sure how good diagnostics I can get out of it.
- Try yet another filter.
- swap out the DECT cordless
- Get an AM radio to look for interference
- Upgrade DG834G firmware
At the moment, I'm a bit stumped as to what more I can do to either get bettter information now, or work out what more I can try when I visit. I don't want to do a remote upgrade of the modem's firmware.
Is there more that I should be trying to monitor out of the DG834G right now? I get the impression I should be watching for some counters related to RS (Reed/Solomon) or ES (Errored Seconds), but I haven't yet found where to get these values out of the modem, and also haven't worked out what are good & bad values to get.
I also need to plan what to do when I next visit. I have a small list above, but if anyone has anything else to suggest, I'm all ears.
(Hmmm. I wrote most of the above offline, on Saturday, but it turns out I needed to make a sudden visit up there. I'll get to take a proper look at things tomorrow. Any ideas will definitely be helpful!)
Cheers,
    Mike

[#2]

Can anyone tell me how to get the bits per tone and/or SNR per tone graphs for a DG834Gv3? I'm looking enviously at the graphs coming out of RouterStats & DMT for some other versions, and trying to work out how best to get them for this particular modem. Will the DG Team firmware let me get hold of that information?
Mike

[#3]

Just spoke to my Mum, and it seems that the one socket in the house is actually an extension... The line enters elswhere, and goes through a different box first, in the living room. This other box has a KC logo, but doesn't have a socket - it's just a blanking plate. Strange, eh?
Mike

[#4]

You'll have to have a look at the box, I've not had any dealings with KC stuff, post what you find.
As regards these RouterStats can't help at the moment on that, except have you posted in the RouterStats forum about the lockup. When I had a quick look there the other day he seemed helpful. Don't know if OJ knows about the v3. Any info on Kitz site?

[#5]

Unfortunately the bits per tone etc. is only available with the Broadcom chipset (DG834GT and 834G v4) the earlier versions of the SDG834G had the AR7 chipset which don't support it.

[#6]

I posted on the RouterStats forum, and the answer matches Oldjim's comment too - that the DG834G v3 doesn't seem to support getting hold of the bits/tone and snr/tone information under any version of the firmware (official or otherwise)
That's something of a shame 

[#7]

OK, I've had a little look now, and found that - suprisingly - the blanked-off box is actually KC's version of an NTE-5. A Hull logo on the outside, and a 80's-vintage BT logo hiding inside the blanking plate. The plastic looks like it has faded a little, and has a slight sooty residue inside.
The master-part of the box looks fine. You can see behind that it is fed with a 6-core cable (coming up from the ground; no aerial cables here), and that the blue/white pair feed up to the screw terminals. I've currently got the router plugged (via a filter) into the test socket, to see what happens to the line stats.The initial feel is that I've improved the downlink SNRM a little - but probably just under 1db. But at this time of day, I have plenty of margin - it's when the sun goes down that the fun starts 😉
The front (blanking) plate holds the wiring toward the extension, and has wires to pins 2, 3 and 5. The tails seem excessively long, and the cable isn't tied, so it doesn't appear to be a seriously professional job.
My thinking here is that I'll move the router to this location permanently, put an ADSLNation front plate in, and tidy up the tails onto the new front plate. I'll certainly check about whether I can get rid of the bell wire to the extension, but am I right in thinking that it can stay in place if it's wired off a proper ADSL-filtered front-plate?
Mike

[#8]

I've also looked at the extension - which was the only box in the house with an actual phone socket in it.
For this one, the faceplate looks bright white - much newer than the wall-mounting box - and makes me wonder if the KC engineer installed it on his visit a month ago. However, it also has a new-ish BT logo on it, which is a bit strange.
Inside, it appears to have the components for a master, with the surge protector & resistor still in place, and the capacitor missing. Wires 2, 3 and 5 are connected, with the other 3 cores tidied up.
The cable itself is only perhaps 20' long, but I definitely seem to have made an improvement of around 1db by plugging in to the test socket.
For this one, I think the plan should be to remove the 2 components (I've seen that being recommended in the "business case" thread at the moment), and do the same change as at the master end, to disconnect the bell wire.
Mike

[#9]

If that plate was only fitted a month ago I wouldn't worry about the surge protector especially if you plan to supply it from a filtered faceplate. But  yes, get rid of the bell wire and resistor, do that now, the difference in SNRM after dark should be significant and maybe in daylight also.
Edit: You can reconnect the bellwire from the filtered side of a filtered faceplate.

[#10]

Well, I can report some improvements certainly... I've been getting the noise margin to rise, all with no effect on the sync rate (which has stuck at 5114 down, 1021 up).
Putting the modem into the master socket seemed to have the effect of both lifting the noise margin by around 1db, and making the fluctuations over time (eg through the middle of the night, or middle of the day) less severe - where we would see 2-3db fluctuations, we're now seeing 1db. Removing the ring wire & resistor , and generally tidying the wiring may have given me almost another db.
Upgrading the router has given me a UI option to restrict the setp to ADSL or ADSL2+. The modem syncs at the same rate with either setting, but seems to be stable (connection-wise) on the ADSL setting. I've left it there for now, while I get everything else more stable, but I'll return to see what happens with this later, and over longer periods.
An ADSLNation faceplate arrived this morning, and has also had a dramatic effect - giving me another 2-3db increase in noise margin. The 17-18db SNRM from the initial connection (with the frontplate there) now seems to have dropped back to more in the region of 16-17db over 2 hours or so, so we'll see what can be sustained until dusk. I'm going to keep my hands off now, and see if the modem can keep sync through the dusk period. If it can, that'll be a great improvement!
I'll admit that I'm a bit puzzled that the modem chooses to keep the sync speed to 5114 while the noise margin varies so much. Perhaps this will change after a period of some stability...
Mike

[#11]

I was exploring the DG834v3 through the debug telnet port, and came cross these files, which look promising.
It certainly looks like the raw data *is* available for creating at least the tone allocation graph, if not the SNR charts.

# pwd
/proc/avalanche
# ls
avsar_bit_allocation_table    clear_eoc_stats
avsar_channels                cpmac_config
avsar_dsl_modulation_schemes  cpmac_link
avsar_modem_stats             cpmac_stats
avsar_modem_training          cpmac_ver
avsar_oam_ping                developers
avsar_private                 eth0_rfc2665_stats
avsar_pvc_table               led_cfg
avsar_qos_enable              led_ver
avsar_rxsnr0                  marvell
avsar_rxsnr1                  psp_version
avsar_rxsnr2                  vlynq_link
avsar_sarhal_stats            vlynq_ver
avsar_ver                     wan_bridge
#
# cat avsar_bit_allocation_table
AR7 DSL Modem US Bit Allocation:
00 00 00 00 00 00 00 07 09 0a 0b 0b 0c 0c 0c 0d
0d 0d 0d 0d 0d 0d 0d 0d 0d 0c 0c 0c 0c 0b 0b 0a
AR7 DSL Modem DS Bit Allocation:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 08 09 09 0a 0a 0a 0b 0b 0b 0b 0b 0b 0b 0b 0b
0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b
...

From that bit allocation file, I generated a graph, which looks suspiciously like the ones from DMT and RouterStats.
Mike

[#12]

Well, yesterday was the first time the connection has survived the evening rush, and kept up for more than 24 hours 
Thanks to the comments on here, plus those I've read on other similar topics - which have all gone to help my understanding. Watching how, as a community, you've been helping others has been very instructive
The solution was probably somewhere in this list, ordered by what I reckoned had the biggest impacts:

• moving router to the master socket (which we never knew was there, and was blanked)


• removing the bell wire, and components in the extension


• swapping from an in-line, cheapo, filter to an ADSL nation faceplate-filter


• upgrading router firmware, and restricting it to ADSL only

I've attached a graph from the last 28 hours or so, which is when I fitted the faceplate, and then left everything to settle. Compared to previous days, it's become impressively smooth. Also interesting to see how the first few hours (into dusk) behaved, compared to the same period today. Evidence of bit-swapping, as the modem learns the line, perhaps?
Cheers,
  Mike

[#13]

48 hours and counting. My mum's quite impressed 😉
I grabbed another copy of the bit allocation table overnight, and plotted it out in Excel to see the differences over time. I plotted some sections in amber (where the router has started to use bits that it hadn't originally allocated) and in red (where the router has stopped using the bits). It is very interesting to see the large chunk removed at tones 197-206.
I might have found a program that will read & plot the bit allocation table from a DG834 v3 properly. I'll post separately if it turns out to be good.
Mike

[#14]

Well done Mike, you've done an excellent job and the improvements are significant.
(Nice bit of investigative work too!).
I don't know if DGTeam Firmware http://dgteam.ilbello.com/ will allow you to do more, you might want to give it a look.