Connection drops frequently... REIN?

[#1]

That checker just says 'available' for everything.  To be honest, I've been relatively patient with this...  new router first because I was using those ancient linksys ones, followed by a new modem when that didn't help.  We're probably talking about 5 months of unreliability, so any electrical works etc probably not that relevant.
I'll keep this running over the next couple of days because we normally experience some downtime each weekend. If that confirms it's not a line issue or anything about the house that's outside of my control, then it's not the end of the world if I need to get a new router (or use this technicolored dreamrouter).
I must admit I haven't updated the modem fw, so I'll certainly check that before I replace it.  As long as I know I've got a fallback plan with the current router, I'll happily keep on with a bit of testing.

[#2]

Quote

Link Information Uptime: 2 days, 17:00:35 DSL Type: ITU-T G.992.5 Bandwidth (Up/Down) [kbps/kbps]: 1.087 / 15.207 Data Transferred (Sent/Received) [GB/GB]: 1,99 / 1,99 Output Power (Up/Down) [dBm]: 12,8 / 0,0 Line Attenuation (Up/Down) [dB]: 15,2 / 30,0 SN Margin (Up/Down) [dB]: 6,3 / 5,3 System Vendor ID (Local/Remote): TMMB / ---- Chipset Vendor ID (Local/Remote): BDCM / IFTN Loss of Framing (Local/Remote): 0 / 0 Loss of Signal (Local/Remote): 0 / 0 Loss of Power (Local/Remote): 0 / 0 Loss of Link (Remote): - Error Seconds (Local/Remote): 63 / 0 FEC Errors (Up/Down): 845 / 630.687 CRC Errors (Up/Down): 198 / 82 HEC Errors (Up/Down): 214 / 1.463

Worth reconnecting my phone extension (without bell wire) today and see if anything changes?

[#3]

Those stats are still looking very good although there's a few more CRC errors on the Upstream than one would like to see bearing in mind how good the DS is, they aren't bad by any means - as I mentioned the US SNRM graphing looks a touch messy and that is probably why.
Every time I look at the webserver, everything looks just as it did from the outset - except RS has done a wobbly when you went to use the computer and post
Now bearing in mind this comment -

Quote from: Timmymac

I'll keep this running over the next couple of days because we normally experience some downtime each weekend..........(or use this technicolored dreamrouter).

the answer to

Quote from: Timmymac

Worth reconnecting my phone extension (without bell wire) today and see if anything changes?

Is no.
Are you really that desperate to have it connected? I would want to leave it until later tomorrow to see if you do get any downtime with things as they are.
Now, as for this "dreamrouter" you don't sound like you are too keen on it for some reason. It can be a pig to customise some of the settings and some aspects might require use of  CLI commands. Perhaps if you tell us what you don't like and any particular setup aspects you need/want we might be able to help with settings?
Another thought that could be relevant, what Firmware version is this particular 582n?

[#4]

It's nothing in particular really. Other than the truly awful web interface...
Just that I have a much more modern, dual band one.  Not that wifi speed is of particular concern to me.
Product Name: TG582n
Software Release: 8.4.4.I
I can live without the phone extension for now...
Is having a SNRM of less than 6 downstream of no concern?

[#5]

The current SNRM DS of 5.3 is of no concern as it is stable (as you can see). In fact on a 21CN connection which you are on, if DLM sees the line as good enough, it can lower the target SNRM from 6dB to 3dB which IMHO would be likely to occur.
The fact that is actually at 5.3 right now might be for one of three reasons -
1) there was slightly less noise when sync was establish than there is now - not too likely I reckon but see 3), because the SNRM appears to have been rock solid since stats have been visible
2) possible thermal effect - it starts at 6, but as it warms up (within about 30 minutes) it drops slightly - whilst possible it's not that common, although I have seen it on other devices.
3) It starts at 6 with a full compliment of tones available, but at some point a number of specific tones become unusable due to some sort of interference (this would lower the SNRM), the modem marks them as unusable and thereafter the very specific interference whether present or not has no further effect as no other tones are affected.
This latter is a good possibility but we may be able to have a clue about this if you post the Bits/Tone plot. Make sure it's set for 0-512. If it is and you've got it being captured to your hard-drive, then post the latest one. Otherwise, right click the graph, select Capture Now, and post that one (attach to a post) (you need to have defined the Capture Folder as I mentioned in the Setup guidelines). Make sure you have maximised the window before doing the capture.
OK, understood about the modem/router, but stick with this one for now as it has good diagnostic ability when needed which a lot of people know and understand.
The interesting thing is the firmware version, there aren't too many of those about.  Was this a Plusnet issued TG582n?
But in any event, if you can log into it, goto >Technicolor Gateway >Information ..(System Information) and look at the data there, can you post the following -
Boot Loader Version, Product Code, and Board Name also the first 6 characters only of the serial number.
Does yours have the USB socket on it?

[#6]

Looks like it was originally issued by Primus!
I'll see if I can get that bits/tone plot on the webserver (which needs restarting anyway!)
Product Name: TG582n
Serial Number: CP112
Software Release: 8.4.4.I
Software Variant: AJ
Boot Loader Version: 1.0.5
Product Code: 36847780
Board Name: DANT-T
Ed: Has USB
adie:green removed some of the serial number]

[#7]

Can't access the webserver atm, is the IP address still the same? It would be a lot easier to capture it and attach it to a post where we can all see it.

[#8]

Same IP

[#9]

Well that comes as no surprise. A block of Tones missing from ~473 to 499. There seems to be an odd couple of tones missing either side. If it were a radio transmission that might be side-bands, it might be a red herring! The centre frequency is a touch too high for the Amateur band, which leaves Beacons and Marine & etc.
Do you live very close to a Marina, or Airport or some other similar establishment (maybe military) Tim?
The only other thing that I've found associated with that frequency, is the clock frequency of some Toshiba Netbooks and Acer TravelMates. I wouldn't have thought they'd be the only ones but nevertheless one would have to have gone faulty in some way to be pushing out interference at the level needed to knock out those tones. I suppose it could equally be some other processor controlled equipment with that clock frequency. Whether it's coming up the mains or not is another matter.
One thing seems fairly certain, it's not the usual Switch Mode PSU interference as there's nothing showing below this frequency.
As far as the firmware goes, I've only come across 2 (IIRC) users on here that had that version firmware (I'm sure there must be others). One observation one of them made was that the web interface seemed a bit nippier than later firmware. That said, the 10.2.x.x. has better noise immunity especially on the Upstream. It would be interesting to see how the Tx SNRM is affected, if at all, with the later firmware if you fancy having a go upgrading it.
Other than that, certainly up until some point yesterday evening when I last looked and was able to access the web server, the connection hadn't dropped, so I'm suspecting that this interference which would have been picked up more strongly, along with any other interference whilst the bell-wire was connected on the extension wiring, coupled maybe with some incompatibility between the previous modem and line card, was responsible for the drops and much slower performance.
I can't access the webserver again at present, just to check if anything has changed. The advantage of uploading graphs to a forum post as attachments - rather than embedded as your last post and where uploaded from an external server (which may disappear or get deleted at some future point) is that they remain as a permanent record on the thread which is helpful to anyone reading later with a similar problem or trying to recap the thread.
The graphs that would be the most informative would be the Bits/Tone, and the Rx SNRM and the Tx SNRM along with the latest full xDSL stats in a post when you can conveniently do that (before any disconnects or firmware upgrade).

[#10]

That's fascinating. I don't want to dive straight in for the red herring but I live by Crosby beach which is a busy shipping lane into Liverpool/Birkenhead.  I also have a little NAS device sat next to the router which will of course have a small cpu in it.  Not sure the current Bits/Tone graph shows the same problem though?
I hadn't figured out the attachments before. They're much more convenient anyway! I've attached what you suggest but there's only really bits/tone any use because I had to restart RS. Looked as before though, with wobbly TxSNRM.
I have indeed reconnected... server is here now: http://87.114.192.165:8080/routerstats.htm

Uptime:	0 days, 13:40:21
DSL Type:	ITU-T G.992.5
Bandwidth (Up/Down) [kbps/kbps]:	1.080 / 14.818
Data Transferred (Sent/Received) [MB/GB]:	205,59 / 1,99
Output Power (Up/Down) [dBm]:	12,3 / 0,0
Line Attenuation (Up/Down) [dB]:	15,1 / 30,0
SN Margin (Up/Down) [dB]:	6,4 / 6,0
System Vendor ID (Local/Remote):	TMMB / ----
Chipset Vendor ID (Local/Remote):	BDCM / IFTN
Loss of Framing (Local/Remote):	9 / 0
Loss of Signal (Local/Remote):	1 / 0
Loss of Power (Local/Remote):	0 / 0
Loss of Link (Remote):	-
Error Seconds (Local/Remote):	333 / 0
FEC Errors (Up/Down):	0 / 0
CRC Errors (Up/Down):	1 / 247
HEC Errors (Up/Down):	0 / 1.047

[#11]

Oops

[#12]

RS has gone wotsit up again at time of posting this.  It obviously didn't like whatever CPU intensive task you started at ~1928.
The current Bits/Tone doesn't show the same problem (yet?) but that's because you had a loss of sync (note also LoS 1), which was at around just after 0400 if posting time and Uptime are anything to go by. The Bit and Tone allocation will be renegotiated as sync is re-established. This does suggest that whatever knocked out those tones previously is not present all the time. Nor looking at the above stats is any significant interference currently present as the SNRM is just above 6 where it would be expected. There's a small amount of bit swapping going on as can be seen in the first of the two Bits/Tone graphs where there is light green plots for some tones - probably due to dusk to dawn AM propagation.
Now the question is, what caused the loss of sync at around 0400. Have a look at the 582n Event Logs and see if there is anything showing for around that time. The GUI log is rather small so if there have been lots of events since, the entries around that time won't be visible. A larger log can be obtained by telnetting. Do you have Telnet enabled on your machine? If so I'll give you the command.
Also, a firmware update, do you want to have a go at that?

[#13]

Can tenlet..  Will update. 

Ed:
Any particular firmware? - Will have to come back to this when I have a working Windows VM..  only have OS X or Ubuntu machines in the house at present!
The router thinks it's January 2000 at the minute, which I'm itching to update but I wont incase it throws the logs out!
Looks like logs only go back about 10mins...??  I've not rebooted!

[#14]

OK, telnet.
Open a command prompt, preferably in a directory where you can save the log.
>telnet -f events##.log 192.168.1.254       .........this will copy the output to a file events##.log , change the ## to a number (before or when saved. If you don't want to do it that way, just leave out the -f  events##.log and then copy the output and paste it to a file).
You'll then get prompted for a username and password. Use a different user from the one RS is running.
When you are logged in -
>syslog msgbuf show hist=enabled
If you've copied the output to a file (either method) then
>exit
That's that. Get the Event log before doing a firmware update, whatever times it's showing we might be able to make head or tail of it.
If the time isn't showing correctly for some reason its not getting to the ntp.plus.net servers, odd. Anyway, firmware update should sort that.
See here http://products.plus-payh.co.uk/firmware/
In the early days all the 582n's were issued with USB ports, latterly they were only sent to FTTC customers. Hence USB port TG582n's use later FTTC firmware. The 10.2.5.2 firmware is configurable for FTTC or ADSL.
You may as well go for the 10.2.5.2.FO , there are a few people using it, I'm using the EO, haven't got round to upgrading to FO. I would download the EO as well, just in case you have an issue with FO and one of the LAN ports not working.
See the "How to use the firmware update tool" BEFORE downloading the tool. You'll see in the Library article the tool(s) are for the 585 AND the 582n, this is mentioned in the "Download section", but note you probably need the Windows 7 version (in compatibility mode if on a later OS). If it's XP/Vista, it's the original tool.
Unpack the tool, and IIRC unpack the firmware and put it in the Builds folder. Then off you go. Do the upgrade off-line of course and the configuration. Log into the 582n and click Disconnect, the after a few seconds pull the power plug , wait a few seconds and then unplug it from the line. Then power it up again to do the upgrade.

[#15]

I don't know why/how but the log must have been flushed at some point in the last few hours... 
fw will have to wait but I will have a go tomorrow if I can.  Don't know why RS is up and down all the time either but it seems to be ok presently.
http://pastebin.com/YJvcR3gj
Cheers,
Tim