Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: spudgun on July 05, 2019, 10:47:10 PM
-
I'm pretty sure that this didn't used to happen on my HG612 + Router setup on FTTC, but I've noticed that on my g.fast line when the router is rebooted to update the firmware, for example, it also triggers a resync and I get a new connection sync speed.
If it is of any help I am running an ASUS AC68U with Merlin firmware connected to the MT992 - but has anyone else noticed this and is it a 'feature' of g.fast as I think it is a bit odd as the modem handles everything on that side and the router just authenticates the session?
-
That is weird. ???
I don't doubt what you report but, basically, it should not happen. Here is an experiment to perform. With the modem and the router both powered up, linked with an Ethernet patch lead and the G.Fast circuit operating normally --
- Watch the LEDs on the modem and disconnect the Ethernet patch lead that links it to the router. Only the LAN LED should be extinguished.
- Watch and wait, say one minute.
- Reconnect the Ethernet patch lead and keep a close watch on the modem's LEDs.
I wonder if one of the two device PSUs is faulty . . . when the router is rebooted, the load on the power supply momentarily increases. Hmm. That doesn't really make much sense. Are the PSUs connected via the same mains socket? A dual gang-socket or a trailing multi-socket extension?
Double hmm. Somebody mentioned something like this in the Thinkbroadband forum (https://forums.thinkbroadband.com/fibre/t/4621041-re-any-gfast-ultrafast-users-here.html), earlier today. :-\
-
Thank you for your assistance, this is a bit odd isn't it.
I'll give the lead experiment a go later as I'm away from home at the moment.
That's not me on the thinkbroadband forum and I gave up reading that thread recently when it got all argumentative about latency in the last couple of days! I do share an ISP with that user though and as there are no stats available other than what we can see via Zen's portal that is all we both have to go on in terms of when resyncs happen, which seems to be a couple of hours behind in updating, but it is far better than nothing.
In terms of power, both the modem and router are plugged in to a double socket like this - https://www.toolstation.com/axiom-switched-socket/p17663 with the modem in the left hand socket and the router in the right.
Will do the lead test as soon as I get back :)
-
Hmm
I've mentioned a few times about the difficulties on my daughters g.fast line when it comes to rebooting modem or router in that it appears to have some weird affiliation. She also experiences difficulty that if the line loses sync, then the router can have a heck of a time getting connectivity to the Internet. It's sometimes it is difficult to figure out if the line has lost sync or just PPP.
Whilst I can't say for certain that rebooting the Fritzbox router causes the line to lose sync (as its not anything I've observed whilst there).. they have been told to reboot both modem and router in order to get Internet connectivity even if the MT992 is showing as being in sync. Their line appears to drop out quite a lot and they were given a replacement Fritzbox to try & rule out it wasn't that which was faulty and causing lack of connectivity.
I'd be interested in your result of the above test.
-
I'm pretty sure that this didn't used to happen on my HG612 + Router setup on FTTC, but I've noticed that on my g.fast line when the router is rebooted to update the firmware, for example, it also triggers a resync and I get a new connection sync speed.
If it is of any help I am running an ASUS AC68U with Merlin firmware connected to the MT992 - but has anyone else noticed this and is it a 'feature' of g.fast as I think it is a bit odd as the modem handles everything on that side and the router just authenticates the session?
1 question, 1 point.
How do you know the sync speed is changing as the MT992 gives zero stats?
Are you sure it triggers a resync? The G.Fast sync speed is constantly changing, it uses SRA.
ISP portals can't deal with the SRA, so every PPPoE resync they will see a new sync speed.
The sync speed changes ALL the time though.
-
So, I've unplugged the wan cable on the router - only the LAN light went out on the MT992 and it stayed that way for a couple of minutes whilst I was unplugged - so that's exactly as expected
Router plugged back in and I'd guess from a few quick speed tests that i've done that there has been a change in sync speed, but it will be a couple of hours before the Zen portal gets updated.
Maybe J0hn is on to something with SRA as the Zen portal is all I have to measure sync speed by - will update as and when the reconnecting of the router appears on my line data.
-
The sync speed definitely changes continuously as SRA is enabled.
Rather the SNRM varying with the sync staying static, the sync varies to keep the SNRM at its target margin which is 3dB by default on G.Fast.
If the Zen portal only updates the sync speed when reconnecting the PPP session then that just sounds like the portal isn't designed to deal with SRA.
I've no idea how the whole IP profile thing works with SRA.
Perhaps it updates to the current sync speed when you reconnect the PPP session which could account for any big difference in speed tests.
-
So, I've unplugged the wan cable on the router - only the LAN light went out on the MT992 and it stayed that way for a couple of minutes whilst I was unplugged - so that's exactly as expected
Router plugged back in and I'd guess from a few quick speed tests that i've done that there has been a change in sync speed, but it will be a couple of hours before the Zen portal gets updated.
As I understand it, you have shown that the modem does not re-train (i.e. re-synchronise with the DSLAM) when the router "goes away" and then "re-appears". Nor does it re-train when the PPP session is established/terminated/re-established or when the router is re-booted.
The more I think about SRA, and j0hn's reminder of its mode of operation, it appears that you have misunderstood the significance of the change in the synchronisation speed and have attributed the change to something that does not occur.
Ignore all my irrelevant queries with regards to PSUs and the sockets into which they are plugged. ("I see nowt wrong with tha double-gang socket.")
-
Thank you for all of the guidance offered so far, it is truly appreciated.
Having given this some thought, I wonder if this is something that is not being handled effectively at an ISP level? The Zen portal identifies a current maximum download speed (mine is 220711Kbps.) down from 229151 at the last record). If we are to assume that SRA is capable of going both up and down as it adjusts it should follow that there will be times that I am able to do speed tests where the max is greater than the value identified in the portal (and, obviously lower as it adjusts down) - however, this is something that I have never encountered and I wonder if a 'hard cap' is being applied at the top end even though SRA would suggest that it can go both up and down from what it is identifying as the current sync level and max speed in the portal.
My current experience seems to be that my identified sync/max speed on the Zen portal seems to match exactly what I am getting and it doesn't fluctuate as the rate adapts.
I could be missing something obvious here - but feel free to enlighten me as I am always willing to learn more :)
-
Looking back at your opening post, it appears that you upgraded the router's firmware whist it was deployed as an in-service device. I would never perform a firmware upgrade that way. My preferred method is to download a copy of the firmware image to a local computer, then take the device out of service and, with nothing else connected to it (in the case of a router), link the device and local computer with an Ethernet patch lead. Then perform the firmware upgrade, etc.
-
I believe (but happy to be corrected) SRA will vary the sync speed constantly up and down as needed but will not go above the initial sync speed at the time of connection.
Without access to live stats on the modem it's difficult to compare the current sync with actual throughput.
Can you see the IP profile of a number on G.Fast?
Does anyone know how that works?
Can you try entering your number on mouselike and seeing if it gives an IP profile.
https://windows.mouselike.org/be/index.asp?DoAction=BrasChecker
-
i think john is correct
also to add the reason you only see variable throughput on pppoe reconnect is probably ip profile related it looks like zen need to rework their systems for SRA
-
I believe (but happy to be corrected) SRA will vary the sync speed constantly up and down as needed but will not go above the initial sync speed at the time of connection.
Without access to live stats on the modem it's difficult to compare the current sync with actual throughput.
Can you see the IP profile of a number on G.Fast?
Does anyone know how that works?
Can you try entering your number on mouselike and seeing if it gives an IP profile.
https://windows.mouselike.org/be/index.asp?DoAction=BrasChecker
Thank you for your further assistance, the evidence that I am seeing supports the theory that the initial sync sets an upper limit, but in fairness I don't see it adjust downward - but that may be just down to the properties of my line.
The tool does work and gives values that are in keeping with what the Zen portal has for my line
The current Downstream BRAS rate is: 219.75 Mbps
The current Upstream BRAS rate is: 50 Mbps
Again, thank you for your help and suggestions with this, it will provide useful information for those that follow as it seems that g.fast works a little differently to a vdsl connection and that establishing/dropping a pppoe session can change the maximum speed that you can attain.