Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Psimpson144 on May 27, 2022, 02:40:35 PM
-
Good Afternoon
I'm new to the forum and am not a phone line or signal processing expert so please be patient :)
I have a problem with my Talktalk broadband connection which drops out at fairly regular intervals. The router is a Fast 5364 router and until about 3 weeks ago had been working faultlessly for 3 or so years. Then about 3 weeks ago, the box started dropping its connection, and over the following days, I've noticed that the connection drops out every 7 hours (approx) and is then off line for 70-80 mins. I gather this info as I use a ddns service which reports by email every time the connection drops and resumes.
A snap shot of the line parameters are:-
(downstream, upstream)
Noise margin 0.0, 6.0
Attenuation 19.10, 0.0
Power 11.4, 7.10
Actual rate 38778,9995
Max rate 44362,9995
I've 'discussed at length' the issue with Talktalk but with no success.
I'd therefore welcome any thoughts and suggestions as to what the problem could be.
Very many thanks in advance.
Paul
-
Welcome to the Forum, Paul! :)
I don’t understand the value "noise margin 0.0"
Has TalkTalk not been willing to put this down as a fault and book an OR engineer?
-
Hi & Welcome
Do you have a different modem to try?
-
Hi Paul.
From you description there would certainly appear to be an issue with your BB service, can't really understand why TT would not recognise this!
Would need a lot more information on your system/setup before an opinion on any potential fault state or otherwise could be offered.
From your quoted DS/US "actual rate" presume you are on VDSL-2 (FTTC) service, is this synch speed or data speed (via speed test utility)?
Is your VDSL-2 contract with TT for 40/10 or 80/20 service?
Is your local fibre cabinet (DSLAM) Huawei or ECI?
What's your local setup, router connected to master socket, any phone extensions in circuit?
The DS attenuation figure quoted "19.10dB" would indicate you are on a comparitively long line to the DSLAM (fibre cabinet) which would be unlikely to achieve close to 80Mbps DS even under ideal cross talk conditions always assuming you are contracted for 80/20 service.
As "Weaver" has said, the DS "noise margin" of "0.0" quoted can't really be correct, normally refered to as SNRM (Signal to Noise Ratio Margin), even on a Huawei DSLAM with DS G.Inp active the lowest reading expected would be 3dB.
As "parkdale" suggests, can you substitute the router?
Have no experience of the TT Fast 5364 Hub, noted that it does use a Broadcom chip set but not sure if a stat's utility such as DSLStats can be used to extract more detailed line stats which would certainly assist with diagnosis of the issue, I'am sure some of the forum patrons who use or have used TT services will be able to advise further on that.
-
It could be that the DSLAM has lost power, is lasting 7 hours on batteries and the down time is batteries being changed?
I can't think of any other reason for such a gap in service so frequently.
Check the local roadworks website for works upcoming next to your cabinet.
-
Welcome to the Kitz forum. :)
. . . I've noticed that the connection drops out every 7 hours (approx) and is then off line for 70-80 mins. . . .
That is an interesting observation. j0hn's suggestion as to the cause make sense to me as a set of SLA batteries, when brand new, could maintain the equipment in service for eight hours.
If you would be willing to disclose the cabinet number (and/or your location) we might be able to find some information regarding the infrastructure hardware.
-
It could be that the DSLAM has lost power, is lasting 7 hours on batteries and the down time is batteries being changed?
Something that would never have occured to me I must admit.
Obviously that scenario would effect all VDSL subscribers on that cabinet so a considerable amount of queries/complaints would be expected to various ISP's who via their respective diagnostics would be aware that the DSLAM was down.
Wonder if this would be recognised as the "common factor" with a number of reported issues involving various ISP's who would be unlikely to have any occasion to talk to each other?
Would an OR engineer change out the DSLAM backup batteries without establishing that the previous set were actually being charged?
-
Can't be sure but from the symptoms it could well be a power problem at the FTTC cabinet, the fact that it is a regular interval is suspicious. Have look at this excellent U-tube video.. https://www.youtube.com/watch?v=TBMoR1NMwVg (https://www.youtube.com/watch?v=TBMoR1NMwVg) :)
@tiffy If the power to the Cab has failed they just change the batteries every 8 hours or so.
On the other hand do TT not consider a noise margin of 0.0 to be possible problem? :o
-
Like the video ;D
@tiffy If the power to the Cab has failed they just change the batteries every 8 hours or so.
Ahh, yet another scenario I hadn't considered, a complete mains outage, was thinking more of a battery failure or charging issue with periodic mains loss!
Still, would have thought that TT would have been made aware of such an occurance if this is indeed the case and would have passed on the information to effected customers especially when they actually raised an issue with their ISP in the first place.
-
If an FTTC cab’s battery goes flat and there’s no mains, how does it ever come back on again? If the mains isn’t always off then the batteries will recharge and presumably service will come back up. If the mains is off then the batteries won’t recharge and the services will be down for good. Perhaps it’s a design limitation that the PSU cannot draw enough current to drive the FTTC hardware and recharge the batteries at the same time. Is it the case that once the batteries go flat the fttc hardware can’t provide service while the batteries are in the recharging state? ie the batteries have to recharge to a certain level before services become available. That level is presumably 100% because the downtime is 70-80 mins. It’s a state machine and I don’t have a picture of it.
-
@Weaver I don't think anyone is implying they are charging the batteries on-site, they are simply coming every 8 hours and swapping them out with fully-charged ones.
Its an odd one, but I imagine hooking a generator up the cab is a health and safety nightmare. For one thing, if something has failed in the mains feed then if they had the staff to disconnect that then surely they would also be the same people who would fix it? So this is a last-ditch "solution" for when the mains feed can't be touched.
-
If an FTTC cab’s battery goes flat and there’s no mains, how does it ever come back on again?
An engineer physically swaps them out for a charged set.
The cabinet runs on mains power. When power is lost the DSLAM switches to the batteries. Openreach change the batteries every 8-12 hours, depending on staff availability and their work load.
I recall Chrysalis having a similar issue. Every 8'ish hours he would lose sync for 10 minutes. It was only after this had been going on for a few days that Sky were able to tell him that there was a power issue at the cabinet.
So in his case it appears they were pro actively changing the batteries before they were depleted (at least some of time).
If the OP is having a 70-80 minute outage then that sounds like the batteries are only lasting 7 hours and Openreach are changing them every 8 hours or are just changing them when they die and the DSLAM goes offline.
The batteries can last for anywhere between 4-16 hours, entirely dependent on the number of subscribers on the cabinet and presumably the condition of the batteries.
I don't know if the DSLAM batteries also power the G.Fast/VDSL2 expansion "pods" that are attached to the side of some PCP's as these pods piggyback off the power supply of the primary DSLAM.
Does anyone know? (looks in Blacksheeps to direction)
Edit: started typing this about an hour ago. I see Alex has answered the main point.
-
Its an odd one, but I imagine hooking a generator up the cab is a health and safety nightmare.
Batteries respond immediately to a loss of power. That's probably some requirement particularly with the PSTN closure now and the need for emergency call provision.
They could then hook a generator up upon the initial set of batteries dying but it's probably cheaper/easier just swapping them out every so often. You would still need someone to refill the generator and in many areas an unmanned generator wouldn't last long without being stolen :D
Only the DNO can restore the power supply.
-
I don't know if the DSLAM batteries also power the G.Fast/VDSL2 expansion "pods" that are attached to the side of some PCP's as these pods piggyback off the power supply of the primary DSLAM.
Does anyone know? (looks in Blacksheeps to direction)
That question can be simplified to: Does a 240V AC mains feed or does a 50V DC battery feed transit through Openreach ducting, linking the PCP with the DSLAM cabinet? I've just looked through some photographs and it does appear that the latter is the case. (Which is what I would have expected.)
In either a Hauwei or ECI equipped cabinet the incoming 240V AC mains feed is connected (via a circuit breaker) to a rectifier unit. The rectifier unit outputs a 50V DC feed to a battery charging/control unit. The battery charging/control unit supplies a 50V DC feed to the DSLAM. The DSLAM is provisioned with a modular (slot in) power unit that accepts the traditional (UK) PSTN 48 - 52 Volt DC feed. There are four series connected SLA batteries (of 6 cells each (at 2.1V)), which are on constant trickle-charge, monitored by the charging/control unit. Fully charged, the bank of batteries outputs 50.4V DC.
So a "fibre" cabinet's power supply consists of four separate sections --
- The incoming 240V AC mains feed. (The DNO's responsibilty.)
- The rectifier unit. 240V AC input, 48 - 52V DC output.
- The battery set charging and control unit. 48 - 52V DC input.
- A bank of four series connected SLA batteries. (50.4V DC output when fully charged).
By considering the above, it can be seen that if the DSLAM is operating from the battery bank then there is no way that it can continue to operate when the battery bank is being changed.
-
Firstly apologies for posting in the incorrect forum, and thank you for the responses. I'm humbled by the detailed and thought provoking discussion. Thanks again.
In response to some of the points made.
Unfortunately I don't have another router to try, and indeed I don't currently have physical access to it as I'm in Greece for a few weeks. But I do have access via a VPN (when the line is up) and now have other observations. Since the original post, I've been monitoring noise figures and gain and these do not change! This suggests to me that the router is not measuring these, rather are just reporting some default values. The only parameters that change are the upstream and downstream rates which fluctuate at just under 10 and 40 Mbits / sec which is what I would expect?
If it is the battery issue as discussed above, and this seems very plausible, then I suspect I'll have an interesting conversation with TT telling them to task OR to investigate unless someone can tell me otherwise.
For info, we live in a residential area of Weymouth.
However, I've noticed something else, after a reconnection, the router reports a connection up time of x mins (say) but also reports a system up time of about x mins, suggesting that the router itself has been off, I would assume that in the event of loosing its connection, the router would stay active (is this a valid assumption?) if so, it might be the router? But why would it go off every 7 OS so hours for 70ish mins? That said, based on the noise etc comments above, I probably have reservations about these time up parameters.
Attached to the router is a nas (which provides the VPN into my home network and a raspberry pi based Web server plus a few other non wired devices, now I accept that my next question is probably out of scope for this forum, but could something attached be causing this odd behaviour?
Once again thank you all for your thoughts.
Paul
-
Hi
ALL DSLAM's are constantly auto-monitored for their current standing, with a range of 'states' from Major incident, to AC Power Fail to Flapping .... and another 8 status's in between.
Currently, across the whole of the suite of DSLAM's there are only 10 showing as AC Power Fail, with 3 of those already in attendance by OR guys. The dwell times are incredibly tight as you might imagine where power is concerned.
B*Cat summarised j0hn's question up perfectly well, the side-pod is indeed fed via a combined fibre/power cable to the main DSLAM itself.
-
For info, we live in a residential area of Weymouth.
Do you know the cabinet number through which your service is provided? If yes, and you are willing to share the information, then its status could be checked . . .
If you do not know, then try using the Magenta Systems "CodeLook" (https://www.telecom-tariffs.co.uk/codelook.htm) web-site.
-
Router uptime should almost certainly be accurate, not known any OS not monitors its own uptime as a standard core function of the OS itself.
Especially if the uptime is only slightly longer than the sync time it would indeed suggest its rebooting.
If its not coming straight back up, I wonder if something is going wrong in the PSU and its cutting out completely with an unusually long reset time before it starts outputting voltage again?
One thing to not is if the router uptime is a lot longer than the sync time, so we know its booted but not gotten sync.
Another possibility is if you are using DDNS rather than a static IP address, that could cause a delay getting back into the VPN if DNS has not updated yet for the new IP address.
-
All
Many thanks for the above thoughtful suggestions. However .... to close this thread off ...
As I think I mentioned, I was out of the country when these issues started, and indeed they started May time. Since being back at home, I've had a chance to look at the issue from this end. TalkTalk were unable to diagnose an issue with their line tests.
It appears that TT issued a firmware update in May, and I believe this was the start of my disconnection errors. Despite being out of the county, guests at the property were able to cycle the power on the router, however this had no long lasting effect.
To cut straight to the chase (and omitting a wasted days worth of diagnostics), I performed a factory reset on the modem/router and manually reconfigured my port forwarding rules, new SSID etc and hey presto - NO MORE DISCONNECTS.
So it looks as if the new firmware and my configuration caused some form of corruption in the device which a full reset resolved.
I'm still switching to a new ISP though !!
Paul
-
Thank you for the update. I'm pleased to know that the problem has now been resolved.
A firmware update can leave a device in an unstable state and a hard-reset can often be the cure. Just as you discovered.
-
I have faced the issue of dslam shutting down after 6-8 hours of no electricity and fault in local grid station. Internet disconnected and phone dead too. Usually, ISP installs a backup generator to power the MSAG.