Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: b4z on March 19, 2018, 12:17:28 PM
-
Question to you guys, what could be the cause of this rather large Downstream rate drop?
Same address.
Same line.
Same hardware. [HG612]
No changes.
August 2016
ISP: BT Broadband [55/10]
Max: Upstream rate = 32727 Kbps, Downstream rate = 93504 Kbps
Bearer: 0, Upstream rate = 9999 Kbps, Downstream rate = 55000 Kbps
Down Up
SNR (dB): 17.3 22.9
Attn(dB): 10.8 0.0
Pwr(dBm): 13.5 -3.4
March 2018
ISP: Vodafone [80/20]
Max: Upstream rate = 31589 Kbps, Downstream rate = 68376 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 68654 Kbps
Down Up
SNR (dB): 6.3 13.4
Attn(dB): 10.5 0.0
Pwr(dBm): 13.4 -4.3
So i contact Vodafone, ask them to contact Openreach to perform a 'Remote DLM Reset' as per;
https://www.ispreview.co.uk/index.php/2018/02/ability-reset-openreach-fttc-broadband-dlm-profiles-arrives.html
Openreach tells Vodafone to tell me to, and i quote, "unplug the cable from the master socket to the modem/router, then plug it back in" and that should work.
I find that suggestion to be total nonsense, lazy and disingenuous.
And so I have filed a complaint with Openreach via their website.
As per the article above, the process seems to be as follows: ISP submits lines to be reset, Openreach compiles them into a list, and at 00:00 that evening all the lines on the list get a remote dlm reset.
Openreach are seemingly refusing to cooperate with Vodafone on a process (they have just made available) that saves them time/money/engineer visits etc.
[Update: See further down the thread - Vodafone lied to me/fobbed me off, Openreach are not at fault/responsible]
-
One idea that comes to mind is crosstalk, however with so little stats to work on it's hard to say :(. Maybe someone else here has a better idea. Looking at what you've posted I don't believe a DLM reset will achieve anything as your downstream sync speed is already around the maximum attainable speed for the downstream and so Openreach would probably reject it.
It may be a good idea to post your current full stats assuming that's possible, as well as a Hlog and QLN graph.
-
Openreach tells Vodafone to tell me to, and i quote, "unplug the cable from the master socket to the modem/router, then plug it back in" and that should work.
That doesn't sound quite right to me.
Procedure is that the ISP must perform some basic tests before submitting a call out to Openreach. It sounds more like one of Vodafones suggestions that go in the same category as "Are you connecting to the master socket". If Vodafone placed a fault report with Openreach, then an Openreach wouldn't sent that message back.. they'd send out an Engineer.
There is also a strict criteria which must apply before your ISP can request a reset. One of them being the ISP must check that there would be an improvement on the line of 'x' amount.. your's doesnt have any room for improvement.
Finally.. the reset proceedure is a "One Shot attempt". Openreach never give any feed-back to the ISP... ever.
So i contact Vodafone, ask them to contact Openreach to perform a 'Remote DLM Reset' as per;
Not sure if a reset would achieve anything.
- Your SNRM is 6.3dB - which is the standard Target SNRM and there is nothing left in the line to give you any more speed.
- You're syncing at 68654 and max is 68376... therefore it doesnt look like the line is interleaved.
Thus all indications are that DLM is running at the standard profile without any action that could benefit you if the line is reset.
In fact performing a DLM reset may see your line-speed drop further... as default profile after a reset would apply interleaving.
what could be the cause of this rather large Downstream rate drop?
As Ixel has already mentioned... it will be cross-talk. Most of us have lost large amounts of speed over the past few years due to cross-talk.
I've lost nrly 40Mbps from my headline speed since I first got VDSL. A loss of 20-30 Mbps is the norm.
-
And so I have filed a complaint with Openreach via their website.
Which in a way is unfair. Because it honestly does not sound like the sort of thing which Openreach would have done
DLM reset requests don't work that way. Your name gets added to a list, which gets emailed to Openreach and the reset gets done or it doesnt.
Even if it doesn't get done, then there is no feed back at all to the ISP.
Sounds more like something Vodafone have come up with.. but Vodafone should have checked first to see if a reset would improve the line whilst you were on the phone with them.
One of the concerns about making info such as the DLM reset being available was that EU's would start insisting on them for no benefit ... or that ISP's would start abusing the reset as a 'magic fix' which wouldn't actually achieve anything. :(
If I were to guess what really happened is I'd say that either
1) Whoever you requested the reset from said OK, then someone higher up at Vodafone spotted that there wasn't anything more in the line, so Voda concocted this story to feed back to you OR
2) The request was passed on to Openreach, who would have just dropped it because it didn't fall within the improvement criteria. A few days later someone at vodafone noticed nothing had been done and then realised it didnt fall within criteria and made up a convo to feed back to yourself. :(
How soon did they report back to you supposedly what Openreach said to you? That should give an indication of which scenario occurred.
-
Looks like crosstalk to me.
A DLM reset will make no difference. There appears to be no DLM restrictions in place that are limiting the line.
Vodafone sound line they are fobbing you off with the message they gave you. A DLM reset really will make no difference though. The only thing that could help is an on site engineer checking the line, perhaps a doing a pair swap. An engineer won't do this without a specific request from the ISP though.
Has the drop been gradual, or all at once? Looks to big a drop to be a single crosstalker. It's well within the range of multiple crosstalkers over a period of time.
It's just the nature of the technology and nothing that can be done without vectoring.
-
The initial enounter i was describing: It was on a live phone call with Vodafone. I was on hold for over 30 minutes whilst he tried to contact Openreach.
So i guess i am to assume the Vodafone representative just concocted that story and didn't even get in touch with them.
Unbelievable if so...
It is only recently within the past 1 month or so that the "Attainable Rate" has dropped significantly. Before that it was above 80000 kbps.
I think the line is interleaved as per the HG612 Modem Stats screenshot from today attached.
I have also attached the line stats from 16:00 today.
I can provide more information if helpful/necessary.
Thank you
UPDATE:
I decided to recontact Vodafone, i encountered a more helpful and useful person this time from "First Line Support" they ran a test and told me this is what returned;
Red Flagged, "Network Capacity Error", Openreach Engineer Required
They have referred me to "Second Line Support" (more advanced diagnostics) who will conduct further tests and contact me within 48 hours. They will notify me if an Engineer appointment is booked etc.
So my next question is what defines a "Network Capacity Error"
-
Let's just back up a bit. Are you having an issue with your actual download speed being a lot slower than your current 68654 Kbps sync speed, and is that what caused you to investigate and post the data in your initial post?
-
I am just trying to find out the reason why my line was capable of an Attainable Rate of 93504~ Kbps but is now (supposedly) only capable of 68376~ Kbps and seemingly keeps degrading.
I had a Sync Rate of 79999 only a month or two ago. I can remember that much from when i was looking via the dslstats software.
Could this simply be because of Interleaving?
Could the Interleaving be enabled because of some issue at the Cabinet or Exchange?
-
You lines stats indicate you have G.INP (and its insignificant amount of interleaving that is used with G.INP on Huawei cabinets), you don't have any significant amount of interleaving.
The non-G.INP interleaving tends to make the attainable rate calculated significantly higher than the actual rate possible. You don't have that issue.
-
If you are not seeing actual speeds reduced I'm struggling to understand the relevance of
Red Flagged, "Network Capacity Error", Openreach Engineer Required
-
If you are not seeing actual speeds reduced I'm struggling to understand the relevance of
Red Flagged, "Network Capacity Error", Openreach Engineer Required
Me too. I don't even know what that term relates to either, in this particular instance ?? Is it a posh way of saying, 'crosstalk' ??
-
Me too. I don't even know what that term relates to either, in this particular instance ?? Is it a posh way of saying, 'crosstalk' ??
No. Network Capacity Error is congestion. It looks like Vodafones equivalent to a BTw Hot VP/SVLAN.
I'm therefore puzzled why or how Network Capacity could be fixed by an Openreach Engineer. :-\
-
No. Network Capacity Error is congestion. It looks like Vodafones equivalent to a BTw Hot VP/SVLAN.
I'm therefore puzzled why or how Network Capacity could be fixed by an Openreach Engineer. :-\
Yeah, that's my point exactly, kitz ............ that's why I wondered if, (bizarrely) they might have similar wording for 'crosstalk' with the mention of an OR engineer ????
Cable-fill = Network capacity error ....... obviously, this was an extremely long shot. ;) :) :)
-
I'm seriously beginning to doubt that they know what you are requesting with a DLM reset.
---
What you were told the first time around doesnt make sense to me, the fact that you were on hold while they tried to contact Openreach I'm afraid does not ring true. They cannot contact Openreach to have a telephone conversation with them like that.
DLM reset requests are only currently done by e-mail to a specific department. Openreach just will not enter into any correspondence, nvm telephone call about DLM resets. I'm afraid it really does look like the first person fobbed you off and tried to put the blame on Openreach. :(
You were possibly kept on hold whilst they tried to find out what it was you were requesting.
---
The second response doesnt make sense either.
Sounds like 'First Line Support' ran diagnostics and it flagged up on their system there is a capacity error on their backhaul. That red flag is supposed to be there so that if the EU is complaining of slow speeds then they know its likely down to capacity issues on their backhaul.
-------
I'm beginning to have a niggling doubt over this, because they really don't appear to understand what you are asking for.
AIUI 1st stage trialists were Sky & TT - I dropped plenty of hints last year that it was just a couple of GEA SPs.
Last month it was extended to BT Wholesale... and therefore now included ISPs such as BTr, Plusnet, AAISP etc.
Has anyone ever seen a Vodafone customer get an FTTC DLM reset? Are Vodafone actually partaking in the interim solution yet?
If they are... then someone @ Vodafone should have spotted straight away that your line doesnt meet the criteria for a DLM reset (as there is insufficient room for improvement based on your linestats.)
-
I suppose the OR Engineer could do one of those pair swaps to remove possible crosstalk for a short period, until a new customer come online then crosstalk on to that new pair.
-
I suppose the OR Engineer could do one of those pair swaps to remove possible crosstalk for a short period, until a new customer come online then crosstalk on to that new pair.
Not something that is in our remit, I'm afraid NS.
I'm sure you can appreciate how this could turn into a never-ending story ....... cue the music. ;) :)
-
Could this simply be because of Interleaving?
No - your line isn't Interleaved as such. Your line has G.INP (http://www.kitz.co.uk/adsl/retransmission.htm). Traditional Interleaving (http://www.kitz.co.uk/adsl/interleaving.htm) causes Delay. Your Delay is 0 - so no additional latency which is associated with Interleaving.
INP 50 is G.INP
INP 3 - 4.5 uses Interleaving with Delay.
Whilst G.INP does use a tiny bit of Interleaving, its not using it with RS encoding to add overheads. I was able to clearly see from the first set of stats that you do not have traditional Interleaving applied for the reasons explained by ejs, because the actual sync and max sync were similar figures.
As far a the DLM is concerned it doesnt call this Interleaving in your DLM line profile and class it as retransmission (http://www.kitz.co.uk/adsl/retransmission.htm#retransmission-benefits).
Could the Interleaving be enabled because of some issue at the Cabinet or Exchange?
No.
Aside from the fact that you have G.INP and not Interleaving.. its applied on individual line characteristics.
Your line is on the standard profile. A DLM reset wont make things better.. it will make things worse, because you will then actually go into a period of having old style Interleaving applied.
I am just trying to find out the reason why my line was capable of an Attainable Rate of 93504~ Kbps but is now (supposedly) only capable of 68376~ Kbps and seemingly keeps degrading.
Unless there is a physical line fault - which would show other symptoms.. then it is likely to be crosstalk.
Mine started at ~110 Mbps.. its now only capable of 72Mbps or ~67Mbps when interleaved.
Your line will have several crosstalkers to varying extents, we only tend to notice the large ones. Although rarer, there's been a couple of people on this forum who have taken >20Mbps in a single hit from one disturber. :'(
-
What does the BTw checker say that it estimates your linespeed should be?
-
I've taken a look at the snapshot graphs, shown earlier.
The Hlog plot is essentially perfect. (If konrado5 see this, I would expect him to download a copy for future reference.)
The QLN plot shows the characteristic DSPBO and reading across, left to right (low to high frequencies), appears to show the effect of some cross-talk.
That said, I would jealously guard the pair and would not wish for a pair-swap. In terms of metallic pathways, the one we are looking at is nearly as good as one can get.
-
b4z: Could you attach your Hlog per tones 0-511 ? I'd like to save this perfect Hlog for future reference.
-
I really appreciate everyones replies.
(If i had realised Vodafone had been lieing and fobbing me off, i would not have raised an issue with Openreach.)
Here is a speedtest from December 2017
https://www.thinkbroadband.com/speedtest/1512665404646700355
Here is a speedtest from January 2018
https://www.thinkbroadband.com/speedtest/1514810011590397255
And here is a speedtest from March 2018
https://www.thinkbroadband.com/speedtest/1521541809889097655
So it seems i have lost 10 Meg~ during that 2-3 month period.
Can anything be done the crosstalk interference that you guys propose is causing this?
---------------------
My thought process was fairly simple: my internet connection seems to be getting progressively slower, and it used to be capable of a lot more (80000 kbps~ solid sync rate and much higher attainable rate). So i wanted to know why, then i tried to do some reading on it, from this website and others, and my guess about it being DLM or Interleaving was incorrect, i theorised that it might be incorrectly adjusting my line unnecessarily aggressively, but clearly i didn't understand well enough.
Before i had this connection, i spent quite a bit of time reading this website and forum trying to absorb everything i needed to optimise the connection. The Cabinet is 150metres away, and is Huawei. The wire from the telephone pole (which is 5metres outside my house) was brand newly installed in 2016. I bought and flashed an HG612. The master socket was a new NTE5A MK3 socket the Engineer to put in. And the cable from the master socket to the modem is a very short, high quality, twisted pair cable as is advised, and is as clear as possible of any electrical interference. The reason i say all this is because I tried to do everything in my power to make sure the connection would be good. And so now i am just disappointed that the speed seems to keep dropping.
-----------------------
I have attached the BTw checker as kitz requested.
And here is the Hlog that konrado5/burakkucat requested.
xdslcmd info --Hlog
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 31517 Kbps, Downstream rate = 68400 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 68872 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Tone number Hlog
0 -96.0000
1 -96.0000
2 -96.0000
3 -96.0000
4 -96.0000
5 -96.0000
6 -96.0000
7 -96.2500
8 -7.2500
9 -7.2500
10 -7.2500
11 -7.2500
12 -7.2500
13 -7.2500
14 -7.2500
15 -7.2500
16 -3.7500
17 -3.7500
18 -3.7500
19 -3.7500
20 -3.7500
21 -3.7500
22 -3.7500
23 -3.7500
24 -3.5625
25 -3.5625
26 -3.5625
27 -3.5625
28 -3.5625
29 -3.5625
30 -3.5625
31 -3.5625
32 -3.7500
33 -96.2500
34 -96.2500
35 -96.2500
36 -96.2500
37 -96.2500
38 -96.2500
39 -96.2500
40 -3.1875
41 -3.1875
42 -3.1875
43 -3.1875
44 -3.1875
45 -3.1875
46 -3.1875
47 -3.1875
48 -2.5625
49 -2.5625
50 -2.5625
51 -2.5625
52 -2.5625
53 -2.5625
54 -2.5625
55 -2.5625
56 -2.5000
57 -2.5000
58 -2.5000
59 -2.5000
60 -2.5000
61 -2.5000
62 -2.5000
63 -2.5000
64 -2.5000
65 -2.5000
66 -2.5000
67 -2.5000
68 -2.5000
69 -2.5000
70 -2.5000
71 -2.5000
72 -2.6875
73 -2.6875
74 -2.6875
75 -2.6875
76 -2.6875
77 -2.6875
78 -2.6875
79 -2.6875
80 -2.8750
81 -2.8750
82 -2.8750
83 -2.8750
84 -2.8750
85 -2.8750
86 -2.8750
87 -2.8750
88 -3.0000
89 -3.0000
90 -3.0000
91 -3.0000
92 -3.0000
93 -3.0000
94 -3.0000
95 -3.0000
96 -3.0625
97 -3.0625
98 -3.0625
99 -3.0625
100 -3.0625
101 -3.0625
102 -3.0625
103 -3.0625
104 -3.0625
105 -3.0625
106 -3.0625
107 -3.0625
108 -3.0625
109 -3.0625
110 -3.0625
111 -3.0625
112 -3.2500
113 -3.2500
114 -3.2500
115 -3.2500
116 -3.2500
117 -3.2500
118 -3.2500
119 -3.2500
120 -3.5000
121 -3.5000
122 -3.5000
123 -3.5000
124 -3.5000
125 -3.5000
126 -3.5000
127 -3.5000
128 -3.6875
129 -3.6875
130 -3.6875
131 -3.6875
132 -3.6875
133 -3.6875
134 -3.6875
135 -3.6875
136 -3.6875
137 -3.6875
138 -3.6875
139 -3.6875
140 -3.6875
141 -3.6875
142 -3.6875
143 -3.6875
144 -3.7500
145 -3.7500
146 -3.7500
147 -3.7500
148 -3.7500
149 -3.7500
150 -3.7500
151 -3.7500
152 -3.7500
153 -3.7500
154 -3.7500
155 -3.7500
156 -3.7500
157 -3.7500
158 -3.7500
159 -3.7500
160 -3.7500
161 -3.7500
162 -3.7500
163 -3.7500
164 -3.7500
165 -3.7500
166 -3.7500
167 -3.7500
168 -4.0625
169 -4.0625
170 -4.0625
171 -4.0625
172 -4.0625
173 -4.0625
174 -4.0625
175 -4.0625
176 -4.1875
177 -4.1875
178 -4.1875
179 -4.1875
180 -4.1875
181 -4.1875
182 -4.1875
183 -4.1875
184 -4.5000
185 -4.5000
186 -4.5000
187 -4.5000
188 -4.5000
189 -4.5000
190 -4.5000
191 -4.5000
192 -4.0625
193 -4.0625
194 -4.0625
195 -4.0625
196 -4.0625
197 -4.0625
198 -4.0625
199 -4.0625
200 -4.2500
201 -4.2500
202 -4.2500
203 -4.2500
204 -4.2500
205 -4.2500
206 -4.2500
207 -4.2500
208 -4.3750
209 -4.3750
210 -4.3750
211 -4.3750
212 -4.3750
213 -4.3750
214 -4.3750
215 -4.3750
216 -4.7500
217 -4.7500
218 -4.7500
219 -4.7500
220 -4.7500
221 -4.7500
222 -4.7500
223 -4.7500
224 -5.3750
225 -5.3750
226 -5.3750
227 -5.3750
228 -5.3750
229 -5.3750
230 -5.3750
231 -5.3750
232 -4.6875
233 -4.6875
234 -4.6875
235 -4.6875
236 -4.6875
237 -4.6875
238 -4.6875
239 -4.6875
240 -4.5625
241 -4.5625
242 -4.5625
243 -4.5625
244 -4.5625
245 -4.5625
246 -4.5625
247 -4.5625
248 -4.8750
249 -4.8750
250 -4.8750
251 -4.8750
252 -4.8750
253 -4.8750
254 -4.8750
255 -4.8750
256 -5.1875
257 -5.1875
258 -5.1875
259 -5.1875
260 -5.1875
261 -5.1875
262 -5.1875
263 -5.1875
264 -5.2500
265 -5.2500
266 -5.2500
267 -5.2500
268 -5.2500
269 -5.2500
270 -5.2500
271 -5.2500
272 -5.5000
273 -5.5000
274 -5.5000
275 -5.5000
276 -5.5000
277 -5.5000
278 -5.5000
279 -5.5000
280 -5.5625
281 -5.5625
282 -5.5625
283 -5.5625
284 -5.5625
285 -5.5625
286 -5.5625
287 -5.5625
288 -5.5000
289 -5.5000
290 -5.5000
291 -5.5000
292 -5.5000
293 -5.5000
294 -5.5000
295 -5.5000
296 -5.5625
297 -5.5625
298 -5.5625
299 -5.5625
300 -5.5625
301 -5.5625
302 -5.5625
303 -5.5625
304 -5.5000
305 -5.5000
306 -5.5000
307 -5.5000
308 -5.5000
309 -5.5000
310 -5.5000
311 -5.5000
312 -5.6875
313 -5.6875
314 -5.6875
315 -5.6875
316 -5.6875
317 -5.6875
318 -5.6875
319 -5.6875
320 -5.7500
321 -5.7500
322 -5.7500
323 -5.7500
324 -5.7500
325 -5.7500
326 -5.7500
327 -5.7500
328 -5.8750
329 -5.8750
330 -5.8750
331 -5.8750
332 -5.8750
333 -5.8750
334 -5.8750
335 -5.8750
336 -5.8750
337 -5.8750
338 -5.8750
339 -5.8750
340 -5.8750
341 -5.8750
342 -5.8750
343 -5.8750
344 -6.0000
345 -6.0000
346 -6.0000
347 -6.0000
348 -6.0000
349 -6.0000
350 -6.0000
351 -6.0000
352 -6.0625
353 -6.0625
354 -6.0625
355 -6.0625
356 -6.0625
357 -6.0625
358 -6.0625
359 -6.0625
360 -6.0625
361 -6.0625
362 -6.0625
363 -6.0625
364 -6.0625
365 -6.0625
366 -6.0625
367 -6.0625
368 -6.2500
369 -6.2500
370 -6.2500
371 -6.2500
372 -6.2500
373 -6.2500
374 -6.2500
375 -6.2500
376 -6.2500
377 -6.2500
378 -6.2500
379 -6.2500
380 -6.2500
381 -6.2500
382 -6.2500
383 -6.2500
384 -6.3750
385 -6.3750
386 -6.3750
387 -6.3750
388 -6.3750
389 -6.3750
390 -6.3750
391 -6.3750
392 -6.5000
393 -6.5000
394 -6.5000
395 -6.5000
396 -6.5000
397 -6.5000
398 -6.5000
399 -6.5000
400 -6.5000
401 -6.5000
402 -6.5000
403 -6.5000
404 -6.5000
405 -6.5000
406 -6.5000
407 -6.5000
408 -6.5625
409 -6.5625
410 -6.5625
411 -6.5625
412 -6.5625
413 -6.5625
414 -6.5625
415 -6.5625
416 -6.6875
417 -6.6875
418 -6.6875
419 -6.6875
420 -6.6875
421 -6.6875
422 -6.6875
423 -6.6875
424 -6.6875
425 -6.6875
426 -6.6875
427 -6.6875
428 -6.6875
429 -6.6875
430 -6.6875
431 -6.6875
432 -6.7500
433 -6.7500
434 -6.7500
435 -6.7500
436 -6.7500
437 -6.7500
438 -6.7500
439 -6.7500
440 -6.7500
441 -6.7500
442 -6.7500
443 -6.7500
444 -6.7500
445 -6.7500
446 -6.7500
447 -6.7500
448 -6.7500
449 -6.7500
450 -6.7500
451 -6.7500
452 -6.7500
453 -6.7500
454 -6.7500
455 -6.7500
456 -6.8750
457 -6.8750
458 -6.8750
459 -6.8750
460 -6.8750
461 -6.8750
462 -6.8750
463 -6.8750
464 -6.8750
465 -6.8750
466 -6.8750
467 -6.8750
468 -6.8750
469 -6.8750
470 -6.8750
471 -6.8750
472 -7.0000
473 -7.0000
474 -7.0000
475 -7.0000
476 -7.0000
477 -7.0000
478 -7.0000
479 -7.0000
480 -7.0000
481 -7.0000
482 -7.0000
483 -7.0000
484 -7.0000
485 -7.0000
486 -7.0000
487 -7.0000
488 -7.0625
489 -7.0625
490 -7.0625
491 -7.0625
492 -7.0625
493 -7.0625
494 -7.0625
495 -7.0625
496 -7.1875
497 -7.1875
498 -7.1875
499 -7.1875
500 -7.1875
501 -7.1875
502 -7.1875
503 -7.1875
504 -7.1875
505 -7.1875
506 -7.1875
507 -7.1875
508 -7.1875
509 -7.1875
510 -7.1875
511 -7.1875
-
b4z: Thank you very much.
I see some dip about tone 250.
-
Can anything be done the crosstalk interference that you guys propose is causing this?
The short answer is no.
Crosstalk is the noise generated by lines within the same multi-pair cable as your own line. As your cabinet isn't full yet, it could get worse unfortunately.
I've seen lines lose considerably more than your own.
Vectoring is the only thing that could help here. Openreach aren't deploying it on many cabinets though. Only a select few BDUK funded cabinets have Vectoring.
-
I was lucky once upon a time to get 80mb sync.. now 3 years on I have attainable 6mb under my current sync of 70... next resync or power drop that's a total overall loss of 16mb all through cross talkers.. managed to hold on for about 77 days but snr is way under target 6..
-
I have attached the BTw checker as kitz requested.
Cheers. The figures I wanted to see were these
VDSL RANGE A 80 71.9 20 19
As you are syncing at 68376.. then you may have a chance of approaching Vodafone as a fault due to the line syncing below the min figure.
Be aware though, that this figure does change over time to take into account the effects of crosstalk. I've seen it reduce on my own line a few weeks after a new cross-talker affects my line.
Re swapping pair.. not really recommended. 1) as already mentioned Openreach cant just do this unless their is a fault present. 2) You could end up on a worse line - Ive had that happen too. I had a genuine HR fault and engineer swapped the line to another pair. That pair was about 2-3Mbps worse than the original.. but at least it didn't cause the line to drop when my phone rang.
I forgot to look at the graphs the other night - more from habit now that MDWS has gone as I'd normally go there to look. As b*cat says the hlog indicates a nice healthy physical line.
QLN is quite interesting.. although I see several points where FEXT (crosstalk) is problematic.. when I view the QLN in conjuction with SNR ratio, I'm seeing noise ingression possibly EMI/RFI.
Alan can you take a look and see what you think please... Im not just seeing typical nice smooth what I call seagull wings when looking at QLN. When viewed with SNR its looking a wee bit messy.
FEXT is definitely in evidence it the latter parts of D2 and another few spots such as mid D2, but it is hard to see when looking at SNR where I'd expect to see a nice shallow bowl effect if it was just FEXT alone. Thoughts and 2nd opinion anyone?
-
I see some dip about tone 250.
That is miniscule in the grand scheme of things and bordering on OCD. That is in the adsl tone range.. which on VDSL is subject to pretty heavy PSD masking anyhow. VDSL uses >4000 tones and the OP's floor level is sufficiently good enough not to be affected when it comes to bit load. It's not equating to any loss in SNR so isnt even causing 1 bit of data loss :/ Its about as near perfect as you are going to get for a VDSL line. The QLN at those tones has something else going on from EMI/RFI in the adsl range.. rather than the physical line being any problem.
Even if the dip took that tone out completely and it was a total drop to nothing, because of the VDSL PSD mask at that frequency.. then it would equate to a loss of 4kbps of speed.
-
QLN is quite interesting.. although I see several points where FEXT (crosstalk) is problematic.. when I view the QLN in conjuction with SNR ratio, I'm seeing noise ingression possibly EMI/RFI.
I don't think we can suggest RFI as a result of poor AC balance, I'm more inclined to accept multiple cross-talkers across the entire bandwidth. Obviously there is the (to be expected) evidence of RFI between sub-carriers 100 - 300, with the usual broadcast transmitters making their presence known.
Im not just seeing typical nice smooth what I call seagull wings when looking at QLN. When viewed with SNR its looking a wee bit messy.
Yes, I would agree with both of your comments. But I feel that the messiness is the result of multiple cross-talkers adding up to wide-band FEXT.
FEXT is definitely in evidence it the latter parts of D2 and another few spots such as mid D2, but it is hard to see when looking at SNR where I'd expect to see a nice shallow bowl effect if it was just FEXT alone.
That is where your experience comes to the fore; I would normally look at the Hlog and QLN plots to gauge the quality of the metallic pathway -- leaving the specifics for others to analyse.
[off topic]
I had to download the landscape montage, above, and cut it into the eight component images. Then shuffle them around and view the QLN - SNR pair in a looping slide-show.
Why? Because MDWS is no more. :(
[/off topic]
-
I see some dip about tone 250.
However you must remember that you have taken a sub-set (of the full 4096 sub-carriers) and then plotted it across the width in which we would normally see the full data set. Notice how the granularity of the data has thus become visible?
I appreciate that your interest is with the Hlog plots of G.992.1, G.992.3 and G.992.5 services . . . but you cannot take the data from a G.993.2 service and truncate it to range of your interest. View the entire range of the 4096 sub-carriers and note how smooth is the overall gradual decline with frequency, note how the total drop (from 0 on the Y-axis) is quite small. The smaller the area between the curve and the 0 point line (on the Y-axis) then the better quality that circuit is experiencing.
-
There was a Resync @ 01:11:48
Retrain Reason: 1 (What does this mean?)
Downstream
Sync: 69009
Attainable: 67740
Shouldn't the Attainable rate be higher than the Sync rate? Or is it more complicated than that
Upstream seems to have changed:
Interleaving: Off (1) [before it was On (8)]
INP : 0 [before it was 47]
(What does that mean?)
Attached Images: Last night @ 19:00 before resync vs This morning @ 08:00 after resync
A Vodafone 'senior technical support' staff is supposedly contacting me within 24 hours. But if this is a crosstalk issue (like you guys propose) then i guess there is nothing they can do. (And i am wasting everybodys time :()
(I have this bee in my bonnet that this line IS capable of 79,999/19,999 and i think there is something else going on. Of course i could be an uneducated and delusional idiot!)
Again, thank you for any help you can give.
-
The upstream changes are retransmission (G.INP) being disabled. It's normal behaviour as retransmission is enabled on the downstream only by default. It is usually enabled on the upstream after a period of upstream errors. It is removed again when the upstream errors recede.
(I have this bee in my bonnet that this line IS capable of 79,999/19,999 and i think there is something else going on. Of course i could be an uneducated and delusional idiot!)
It IS capable of the full 80Mb. Every line suffers from crosstalk though, and your line isn't any different.
We can see from your Hlog that there are no defects on your copper pair. The QLN plot shows the usual signs of crosstalk interference.
If your neighbours all cancelled their broadband tomorrow you would get the 79,999Kbps sync back. Without that unlikely scenario or OpenReach deploying a Vectoring module on your cabinet, you probably won't see 80Mb again.
As your cabinet isn't full yet it may even get worse.
As to the attainable being lower than the sync... The attainable is the estimate that your line can achieve at that exact moment in time. This can fluctuate up and down by a few Mb over the course of the day. It also goes up and down if your crosstalkers turn their modems off.
Your line has probably resynced at a time when the attainable if at its highest, and it has since dropped a couple Mb. If you resynced at a time when the attainable was lower then your sync would reduce.
-
Unrelated to the OP...
Viewing this thread on Chrome on 2 different Android phones completely freezes the browser. This even happens in incognito mode when not signed in. It's page 2 that causes Chrome to freeze.
Can anyone else with an Android phone running the Chrome browser try viewing page 2 of this thread and see if they get the same as me? Not sure if it's an attachment or something else that's causing it.
-
Can anyone else with an Android phone running the Chrome browser try viewing page 2 of this thread and see if they get the same as me? Not sure if it's an attachment or something else that's causing it.
Seems ok here.
Tried both viewing as guest and logged in.
S5neo
----
ETA
Attachments seem ok here too. Just opened them all for viewing.
-
I'm only seeing one page for this topic, but it displays OK using Chrome on Oreo.
-
Shouldn't the Attainable rate be higher than the Sync rate? Or is it more complicated than that
Depends upon your current SNR Margin. Target SNRM is 6.3dB, so if your SNRM deviates from 6.3dB then it will affect your max sync. There's also a couple of other things that can affect this such as traditional interleaving due to RS overheads, but n/a in your case as you have G.INP.
It IS capable of the full 80Mb. Every line suffers from crosstalk though, and your line isn't any different.
To further expand on j0hns answer I show below something that happened on my line last night.
At 2am this morning my DSLAM had what may have been some sort of remote update/fix. It forced all lines to disconnect. My modem managed to resync before one of my FEXT distrubers did and note the effects it had on my line.
I sync'd at 78650 with an SNRM of 6.3dB.
A minute later one of my disturbers came back up. Look what happened next to my line.
My SNRM dropped to 4.6dB and my max attainable sync speed immediately dropped to 73553.
That means if I were to resync now, then I would only get 73.5 Mbps. Thus this particular crosstalker is costing me 5Mbps. I do have others that I see from time to time. Some are more, some are less. You can always spot when they resync because your SNRM will momenatarily increase.
My line is well capable of 80Mbps.. I sync'd at 80Mbps for >3yrs.. but as more people joined the cab it slowly eroded my max attainable of 110 Mbps down to more like 70Mbps
----------
PS
I'm not quite sure what they were doing - at spot on 1am I lost internet connectivity for a while and couldnt use the internet despite having sync. I tried dropping my PPP session but couldn't get an IP address. Then at ~2am it looks like it forced all lines to resync.
@B*cat & anyone else that's interested. Note how I kept my increased upstream SNRM. I suspect this is down to DSM which will have been calculated before my disturber came on board. But look how nicely my SNRM is playing on this particular profile and no spikes. You know how I've always maintained that I can't do anything to get rid of the oscillations and how they are always triggered by a remote reset of my line from the DSLAM end.
I'm beginning to wonder if its anything to do with one of the DSM profiles I may get allocated. Which DSM profile I get will depend upon which of my disturbers are connected at the time that I resync.
Arggh I want to type more on this, the theory is there in the back of my head re Power profiles and I know what I want to say.. but communication fails and my fingers refuse to co-operate any more (its taken over an hour to type just this), so Im done with long posts for the day other than saying it may explain why if I resync myself I cant get rid of the crappy oscillations sometimes.
-
Re. Kitz' comment. If you hadn't drawn my attention to your SNRM plot I probably would not have made any deduction on the absence of the typical oscillations that you experience in such circumstances.
Whether it was cabinet work, work on the fibre back-haul to the fibre head-end exchange or work at the fibre head-end exchange, the timing, etc, has all the hallmarks of planned engineering works. The fact that all circuits terminated on the DSLAM were triggered to perform a re-train seems to suggest that there might have been a software upgrade during the service outage.
[wishful thinking]
Could G.998.4 have been rolled out to your cabinet's ECI M41? :-X
[/wishful thinking]
-
Apologies to the OP for this being OT but I couldn't see an easy way to split the thread without making some replies nonsensical. It was purely to show b4z an example of how FEXT affects a line that I posted my stats. Then it was only because I did this... that I happened to notice the changes in my power profiles last night.
Re. Kitz' comment. If you hadn't drawn my attention to your SNRM plot I probably would not have made any deduction on the absence of the typical oscillations that you experience in such circumstances.
I appear to have picked up a different PSD mask with different power levels. It is at this point I miss the demise of MDWS so you can see some stats which dont appear on DSLstats. I've noticed for a while that since the advent of Dynamic Spectral Management (DSM) that on occasion users can be allocated different power profiles. On certain profiles my line seems to behave better when it comes to my 'familiar' oscillations. I've also noticed that users can be allocated higher power levels if they sync before their disturber comes on line and this profile will stick even when the disturber comes online until you next resync.
What I was trying to say is that quite often lines (not just mine) can on occasion see a boost in power levels depending what disturbers are online at the time of EU's sync. Past experience has taught me that if I resync now, then not only will I lose the increased sync speed from the SNRM, but I will lose my existing power profile and upstream power will reduce back down again.
If it is the case that DSM controls your power profile (which by all accounts it should do... and awaiting any feedback from ejs) then that may explain why I can't seem to shift the oscillations unless its a remote sync which also knocks my disturber off line.
Whether it was cabinet work, work on the fibre back-haul to the fibre head-end exchange or work at the fibre head-end exchange, the timing, etc, has all the hallmarks of planned engineering works. The fact that all circuits terminated on the DSLAM were triggered to perform a re-train seems to suggest that there might have been a software upgrade during the service outage.
I can't see any evidence of a software update to the line card. But this is the 2nd time in the past 2-3 weeks that I've lost some sort of (BTw) backhaul connectivity followed by a DSLAM initiated resync. Whatever it is will cause internet interruption between the point of DSLAM and my ISP. A tracert on both occasions stopped before I could reach my ISP yet I would have sync. If I tried to force my router to do a PPP reconnect it would fail to pick up an IP and return 0.0.0.0. It's my understanding from theory learnt in days of old that if it was an ISP failure you would at least be allocated with an internal BTw IP address even though your routing wouldn't go anywhere near the Internet this BT internal address would at least allow you to perform certain diagnostics such as reach the BT digital realm test sites* The fact that I couldnt even pick up a BTw based IP leads me to think the point of failure was before the bRAS and therefore between the DSLAM and head-end exchange.
[wishful thinking]
Could G.998.4 have been rolled out to your cabinet's ECI M41? :-X
[/wishful thinking]
Wishful thinking indeed. G.INP is and always has been a 2 step process.
1.) DSLAM configuration changes - These are DLM profiles which are set on the DSLAM and not any f/w upgrade.
2.) EU DLM profile roll out which are applied to the individual line profile. Historically on Huawei cabs & the botched ECI roll outs 1) always happens a few weeks/month before 2).
-------
*It's because BT use an internal IP that is in the same range as supposedly used by the CIA, that started conspiracy theorists down a rabbit hole.
I know for a fact that BTw has always used this specific range of IPs if for some reason you cant get internet connectivity to your ISP. It was built like this since at least 2003 that I have seen, so that you can at least access the BTw digital realm for tests and start-up domains if connection to your ISP fails and the bRAS can't pass you on to your ISPrealm.
iirc AAISP RevK also confirmed this more recently. But I definitely remember 10+ years ago when Plusnet had their Broadband plus accounts and BTw policing the central capacity EU numbers, so that users would find themselves unable to connect to a PN central and end up on the BTw realm with one of their IPs.
-
Apologies to the OP for this being OT but I couldn't see an easy way to split the thread without making some replies nonsensical.
And I have to echo your apologies, for I had a moment pondering how to respond and decided it would have to go OT, for the very same reason that you have stated.
-
Well that didn't last very long. :'(
My SNRM was rock steady nice straight line at 4.6dB for 30+ hrs without even a 0.1dB flicker. Zero oscillations. Line was holding great at 78650 kbps.
Until I got my usual morning spike of errors... and then the DSLstats alert on my phone went crazy. Yup today was one of the days when my CRCs decided to stick. I had no alternative but to resync my modem whilst my cross-talker is online. Now syncing at 72820 kbps and tiny oscillations are back. :(
I'm not sure what my Err/Sec total is as I'd not updated DSL stats to the latest pre-release version which gives a figure, but hopefully I managed to resync the line before too much damage was done.. looking at what data I do have the 14 mins before I could resync my modem produced circa 845 Err/Sec.