Hi Adam,
Thank you for your update as discussed in our PMs - very much appreciated.
The news that the SNRM reset failed is in some ways good news as it rather removes the possibility of significant REIN, though I still await visibility of the RouterStats graphs as and when Avodat has the time.
I asked NPR for a view on the router tantrums and this is what he said...
| Quote from: npr |
AFAIK the "kernel warn restart" just indicates the router has had a unrecoverable error, could be anything really. IIRC the TG586v7 suffered badly from this before being fixed with new firmware, it was often claimed to be improved by giving the router better ventilation and or disabling UPnP. Running P2P was often claimed to exacerbate it.
His connection quality looks ok but he did use a fair bit if data in just under 2 days, more that just browsing -- is he using p2p?
Could the problem be a fault (cheap Chinese) laptop power supply giving out lots of RF?
My daughter had one of these once, she destroyed 3 of my routers (well the routers power supply) before I discovered the cause. A simple test with a AM radio will prove a faulty (RF emitting) power supply.
Sorry I can't be more help but good luck with this one.
|
Is there any way the PN product guys can ask TG about the TG586v7 issues and see if there is any relevance / applicability to TG582n throwing a "kernel warm restart" please? Have any such issues been addressed in the more recent TG582n firmware versions?
@Avodat,
In summary I believe there are a number of things going on here, however not a single one of them is solely the cause of the issues you are experiencing. As suggested by npr, it looks as though the disconnections (if they all are associated with router tantrums) are being caused by the sum contribution of a number of marginal issues.
1. Line performance (as reported by the router) is no where near where it ought to be for your line's (reported) attenuation. However if you are who I think you are, it is performing far faster than the BT estimate of 12Mbps.
2. The router is reporting high levels of errors, however not enough to cause the Dynamic Line Management (DLM) to seek to adjust the line.
| Quote from: Adam |
Having run the diagnostics and checked the details, it appears that there is no banding in place and the status of the line is actually shown as Green so nothing appear to have kicked in as a result of the dropping connection.
|
The action proposed by Adam to move the target SNRM to 6dB ought to reduce the levels of errors being seen and managed by the router, however that will be at the sacrifice of some raw synch speed. Once we have got the link stable though, we can return to this.
3. I suspect that the internal wiring is contributing to the lower than expected synch speed, possibly even some of the errors. There is no proper NTE5 termination, there are various bits of apparatus prior to the LJU master socket and the bell wire appears to be connected. For good ADSL operation none of these are ideal, but on its own not the cause of these issues.
Adam, what is the possibility of getting BTOR to bring this installation up to specification FOC without an attributable fault please? Given the description I'm guess that the installation could be 30+ years old.4. The line appears to remain stable when the computers are not switched on / used.
Can you please clarify this point - when you are not actively using each computer, are they switched off or just left switched on 'idle'? The correlation between disconnections and computer use could be down to either electrical interference (REIN) from the computers / power supply or be down to data throughput stress. The RouterStats graphs should identify if there is REIN present. If it is a throughput issue, then it is more than likely related to the known issue on other TG routers.
For the immediate investigation can you please...
1. Advise of the firmware version
2. Watch out for disconnections - these could either be experienced or surmised by noting the connectivity duration (uptime) as seen here -
http://192.168.1.254/cgi/b/dsl/dt/?be=0&l0=2&l1=03. When you observe a disconnection, can you please try to grab the router log (category = all) through the CGI or if you have routerstats up and available, there should be an icon (to the left of the house symbol) which looks like a piece of paper coming out of a printer with a magnifying glass - click the drop down arrow and see if there is a TELNET log option. This one will provide much more details.
4. When you have time, routerstats graphs would be most useful.
I really do understand that you have other pressing things to do. just get back here when you can and we'll try to move the issue closer to resolution.
Kevin
PS: Looks like there has been another event and Anotherone has responded whilst I've been keyboard bashing - looks like he's also pointing in the direct of telnet...
Superusers are not staff, but they do have a direct line of communication into the business in order to raise issues, concerns and feedback from the community.
