Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: vdsl on October 12, 2020, 09:23:05 PM
-
Hi,
Just moved house and finding that the internet connection is a little less stable than I've been used to.
I'm on Zen FTTC and using the provided Fritz!Box 7530 as a bridged VDSL2 modem in front of a Unifi USG. I've installed a filtered faceplate and disconnected all 5(!) telephone extensions that were daisy-chained from the master socket.
Working from home and seeing my Cisco Anyconnect VPN dropping quite regularly throughout the day. Often it reconnects very quickly and the only indication of the issue is the popup notifications (disconnected, reconnected). Sometimes it stays disconnected and I lose RDP connection to the office, which is a bit more intrusive. Streaming video/audio occasionally a bit choppy. Also seeing occasional desync events - longest single sync session has been about 5 days.
I've attached my modem stats. Not shown is the current uptime (43 hours).
Am I right in thinking that an SNR of 3-4 dB indicates that I'm synced at close to maximum expected speed for this line?
More pertinently to the stability issue, do the error counters seem reasonable? 40,000 corrections in 15 minutes seems like a lot of packets are being corrupted?
I've got a spare TP-Link VR400 router (Broadcom chipset) - is it worth giving this a go and comparing to the Fritz!Box? The cabinet I'm on is a Broadcom chipset too.
-
AFAIK corrected should mean no stability issues, as its performing as intended. Its a high level of uncorrected that would be a problem.
I'm sure some of the more experienced users will drop in with a more knowledgable response.
-
Hi and a very warm welcome to the forum! ;D
What Alex said.
-
Thanks both! :)
As long as that count being high just means G.INP is doing it's job, that's fine.
Anything else worth checking given the VPN disconnect / reconnect issues? Or does everything look to be in order?
-
If it tells you the time its been in sync anywhere, that's a good thing to keep an eye on.
If not, just keep a log of the sync rates (that appears to confusingly be labelled current throughput), if it changes you know its re-synced. If it happens a lot then it would indicate a problem.
-
To me the stats look ok - very similar speeds and error rates to my line in fact. It should however stay in sync for more than 5 days at a time so that is a bit odd. I'd say it's worth giving the VR400 a go to see if its Broadcom chip performs any better.
My work also uses Cisco Anyconnect and I too find it can occasionally drop out. I put this down to their system however as I don't see any issues during 'normal' use.
Ref the extensions you have disconnected - as long as they are all hanging off of the filtered side of the faceplate then it should be absolutely fine to reconnect them if you want to.
:)
-
Ref the extensions you have disconnected - as long as they are all hanging off of the filtered side of the faceplate then it should be absolutely fine to reconnect them if you want to.
:)
Although if there are three wires do not reconnect the ring wire and if you don't need them, better to leave them disconnected to avoid any potential for them acting as antennas.
-
The line has stayed in sync for 7.5 days and counting now, I think the filtered faceplate has helped with stability compared to the filter that came in the box.
Turned on smart queues on the USG and it's made a big difference to the latency spikes I was seeing (at the expense of some speed though) - the spikes are much smaller and more spread out now:
(https://www.thinkbroadband.com/broadband/monitoring/quality/share/thumb/562e3442145800bf88fb1ea005b5fe332e8664f2-18-10-2020.png) (https://www.thinkbroadband.com/broadband/monitoring/quality/share/562e3442145800bf88fb1ea005b5fe332e8664f2-18-10-2020)
I'll try the VR400 when it next drops sync, interested to see how long that will be. I'll maybe reconnect the phone extensions then too (to the filtered side of the faceplate), assuming that just the blue/white pair should be used from each cable?
-
Replaced the Fritz!Box with a Zyxel VMG8924-B10A, after finding the VR400 doesn't support CLI. It's synced about 3000 kbps faster downstream, no obvious change upstream.
Installed dslstats, amazing how much more information is available!
Not entirely sure how to interpret some of the graphs and tell what is good/bad, in particular information around QLN and HLog seems to be pretty sparse online. I also noticed that on some of the higher tones, SNR sometimes goes negative - would this indicate there is more noise than signal?
I notice that the line is flagged as having REIN (INPRein = 1.00) and has interleaving applied (depth 4), so I guess it's worth checking if there is anything in the house that might be interfering.
Noticed a few big dips in SNR last night that correlated with high errors (corrected and uncorrected) and Netflix streaming intermittently losing a lot of quality. Nothing so far today though, so I'm just monitoring for now.
EDIT: Is it normal to have an SNR of 0.0 in the second upstream band (if I'm using the correct term?) and for this band not to appear at all on HLog or bitloading graphs at all?
-
I have noticed that I sometimes don’t get upstream info at all. However I’m using Our Very Own Johnson’s modem software (https://github.com/johnson442/custom-zyxel-firmware/releases) and looking at the graphs that it serves up directly by http, and I’m using ADSL2 not VDSL2. This might suggest that it’s something fundamental and odd about the raw numbers that the modem’s reporting subsystem produces.
-
Good point - the HLog text file shows all values for the missing band as -96.2500 which seems suspiciously consistent!
The initial band plan shows these tones, but the final band plan doesn't use them. Is there a usual explanation for this (e.g. distance from cabinet, noisy line, etc)?
xdslctl info --pbParams
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 7114 Kbps, Downstream rate = 45708 Kbps
Bearer: 0, Upstream rate = 7114 Kbps, Downstream rate = 45293 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3959)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205)
DS: (33,859) (1216,1961) (2793,3915)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 7114 kbps 45708 kbps
Actual Aggregate Tx Power: - 1.1 dBm 11.8 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 10.3 42.4 N/A N/A N/A 18.7 50.3 80.0
Signal Attenuation(dB): 10.3 41.7 N/A N/A N/A 26.7 49.9 100.3
SNR Margin(dB): 6.2 6.2 N/A N/A N/A 3.3 3.3 3.3
TX Power(dBm): -12.0 -1.4 N/A N/A N/A 8.5 7.8 3.0
>
-
Good point - the HLog text file shows all values for the missing band as -96.2500 which seems suspiciously consistent!
The answer can be found in the ITU-T recommendation G.992.3, section 8.12.3.1 --
The channel characteristics function Hlog(f) shall be represented in logarithmic format by an
integer number m(i), where i is the subcarrier index i = 0 to NSC – 1. The m(i) shall be coded as a
10-bit unsigned integer. The value of Hlog(i × Δf) shall be defined as Hlog(i × Δf) = 6 – (m(i)/10).
This data format supports an Hlog(f) granularity of 0.1 dB and an Hlog(f) dynamic range of
approximately +6 dB to –96 dB.
An Hlog(i × Δf) value indicated as m(i) = 210 – 1 is a special value. It indicates that no measurement
could be done for this subcarrier because it is out of the PSD mask passband (as relevant to the
chosen application option – see annexes) or in the BLACKOUTset (see clauses 8.13.2.4, 8.13.4.1
and 8.13.4.2) or that the attenuation is out of range to be represented.
The value -96.3 (i.e. -96.25 rounded to one decimal place) is just the special value, as described in the third paragraph, above. The domain of the logarithmic presentation of the channel characteristics function is:
+6 dB > Hlog > (6 - ((210) - 1) /10)
The lower bound of that domain is, thus, -96.3.
-
Thanks - looks like a useful reference! I had to look up most of the terms quoted though :) Is my laymans interpretation below on the right lines?
Hlog displayed as -96.3 dB means no measurement (explaining why it does not appear at all on the graph), due to one of:
- Outside of PSD mask passband (power spectral density - most mentions of this seem to refer to a profile applied to DSLAM to prevent interference with ADSL lines)
- In the blackout set (marked as unusable by the DSLAM due to radio frequency interference)
- Attenuation is out of range (signal loss due to length/condition/material of cable)
-
Yes! I'm happy to agree with your synopsis. :)
The channel characteristics function, H, is a complex amalgam of a number of physical parameters, all frequency dependent. It can be presented in a number of ways, both logarithmic and linearly.
The simplest is the logarithmic presentation, Hlog. Which, fortunately, is the one we regularly use. In terms of interpreting a plot of Hlog v Sub-carrier Index, the more positive the value (at any one frequency) the better.
As an example of a good plot, I've attached (below) one that I had prepared earlier.
-
Been running a 35 mbps speed cap on the Zyxel for a bit now - down from a line speed of ~44-45 mbps. This raises my SNR margin from around 3 dB to 6.4-6.8 dB.
I'm still seeing short-lived 1-2 dB drops in SNR margin most days, but these are no longer sufficient to knock out the connection and I've managed to maintain sync for almost 11 days straight since capping.
Thinking of raising the cap to 40 mbps, which I suspect will be the balance between speed and stability - DSLstats has never shown the max attainable speed drop below 40, and hopefully will leave me with enough SNRM to absorb the dips without losing sync.
@burakkucat - If I was interested in determining which of those three causes were the most likely for my connection, what would I be looking for? Appreciate that I can't actually change anything as they're all on the Openreach side - just as an exercise for my brain!
Regarding your example plot, presumably that is for a very good line close to the cabinet? Assuming that my dropoff as frequency increases is due to distance, although the upper ~1000 tones seem to vary quite randomly compared to the smooth dropoff of lower tones.
-
It’s a shame that more individual parameters can’t be controlled. With mere old-fashioned ADSL2 and A&A’s features, I can set target SNRM and interleave values.
Why do we thing it is that the connection is dropping as opposed to hanging on in there? If it’s a very short-term blip then interleave should handle it, so perhaps interleave is set too low, or perhaps the blip is quite long in duration, and too long to handle. G.INP would help a lot.
My modems hardly ever drop the connection, not unless there’s some work being carried out. That’s even at a mere 3dB downstream target SNRM and 6dB upstream and is in spite of the extreme length of my lines at ~7300m. I’m assuming that G.INP (recte PhyR) is responsible for the high reliability.
-
@burakkucat - If I was interested in determining which of those three causes were the most likely for my connection, what would I be looking for? Appreciate that I can't actually change anything as they're all on the Openreach side - just as an exercise for my brain!
If you really "tweak my tail", I would say that I suspect that it is probably a mixture of bullet points one and three. (Outside of the PSD mask passband and "out of range" attenuation for the pair.)
Regarding your example plot, presumably that is for a very good line close to the cabinet?
It's better than that, as both the VTU-C and VTU-R are located in The Cattery and were configured for some experiments. :D
Assuming that my dropoff as frequency increases is due to distance, although the upper ~1000 tones seem to vary quite randomly compared to the smooth dropoff of lower tones.
<Nods.> A distance and, thus, attenuation effect. The overall look of the plot for your line is more or less that of the average for the UK. (On average, everything is . . . er . . . average.)