Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: jelv on December 10, 2018, 11:58:39 AM
-
Looks like I am on a similar timescale as I incurred the wrath of DLM due to many reboots reconfiguring my setup to use an HG612 with the Zyzel VMG1312 B10D demoted to router only mode. The many reboots were largely due to this: https://forum.kitz.co.uk/index.php/topic,22792.msg387507.html
My stats can be seen here: https://www.elvin.me.uk/DSLstats/index.htm (history not working due to the way I am configured) and https://www.elvin.me.uk/DSLstats/Stats.php
Any suggestions or am I just going to have to be patient?
---
Admin - Topic split off from here (https://forum.kitz.co.uk/index.php/topic,22714.0.html) at OP's request.
-
@jelv
Not directly relevant to your current query, noticed that you are running the kitz and broadstairs DSLStats utilities on your web site and you mention having issues with the history content with the kitz interface.
I currently use the same setup, I think we may well have the same web host provider, John (d2d4J), wondering if you have noticed this post and subsequent responses,
https://forum.kitz.co.uk/index.php/topic,21237.msg387371.html#msg387371
and could it be relevent to your "history not working" issue within the kitz interface.
If this is not the case please disregard.
-
A bit worse for you jelv it looks like DLM has banded you at 74Mb.
If it doesn't bother you too much you could try waiting a few weeks and seeing if it removes itself.
Failing that ask AAISP if they are able to request DLM resets yet.
-
My stats can be seen here: https://www.elvin.me.uk/DSLstats/index.htm . . .
Obviously there is some reason why you have used green for both the DS & US (perhaps there is some difference in shade but to those with visual difficulties it is just one green colour).
However there is currently a definite and significant flaw with your circuit. I went to the Line Health (https://www.elvin.me.uk/DSLstats/line.htm) tab and first considered the QLN plot. My reaction was "Yuck" . . . the average noise floor, by eye, is significantly elevated. On looking at the Hlog plot the reason became very apparent . . . you have a very nasty bridging tap present. Your circuit's performance is going to remain sub-optimal until that wiring flaw is traced and then eradicated.
-
Thanks for that.
Time for some experiments. My office is upstairs and the master downstairs with no easy route between. I'm currently using an extension socket in the office (1 of 7 - yes SEVEN) and while the max was above 80000 I was content to run like that - I started at well over 100000 - but I was the first FTTC user on the cabinet.
-
Time for some experiments. My office is upstairs and the master downstairs with no easy route between. I'm currently using an extension socket in the office (1 of 7 - yes SEVEN) . . .
Ah, that goes some way to explaining the origin of the problem! :-X
If you would like to start a new thread of your own and post (within [code][/code] tags) the Hlog data, we should be able to (manually) calculate the length of the bridging tap. Also, boozy (https://forum.kitz.co.uk/index.php?action=profile;u=10482) may be able to use the data-set with some diagnostic software that he has recently written.
-
Could you take a look now please?
-
Could you take a look now please?
Certainly. :) I now see red for DS, blue for US and no change in the condition of the circuit with respect to the bridging tap.
-
Thanks. I've put the filtered face plate back in and plugged modem and router into that.
-
Your SNRM has increased along with your attainable by a few Mb.
Hlog still shows a bridge tap present.
Line remains banded at 74Mb.
-
When I tried to post the HLOG data it was too long! I think https://www.elvin.me.uk/DSLstats/temp/HLog-2018-12-10-23.47.30.txt (https://www.elvin.me.uk/DSLstats/temp/HLog-2018-12-10-23.47.30.txt) is what you wanted to see.
-
If someone wants to attach something to a forum post, can it hit a size limit? Could zip it up though, no? Kitz accepts .zip extensions on attachments.
(Assuming one does not want to avoid the issue by parking the data elsewhere and linking to it, as jelv did later.)
-
Yes I could have attached it but doing it as I have made it easier for others as they can view it directly without having to download and extract from a zip.
See attached regarding maximum size.
-
From the AAISP trouble reports log:
BT Test E2E Access Test/DCN:Inconclusive OR test pass. Unable to find the fault. Down:73.9 (73.9/73.9/74.0) Up:20.0 (20.0/20.0/20.0) 2018-11-28T08:30:00 0.128M-74M Downstream, Retransmission High - 0.128M-20M Upstream, Retransmission Low In Sync Pass:GTC_FTTC_SERVICE_0000 GEA service test completed and no fault found .
-
"Retransmission high" so there goes another 5 or 6% or whatever it is. (Is that right, when dreaming sync rate to real IP PDU throughput? I think Kitz guide to real speeds and overhead mentions something like that?)
-
- Could someone explain why my HLOG suggests a bridge tap please.
- Now the modem is plugged in to the data socket on the filtered face plate, could an internal issue due to the ridiculous number of extension sockets still be causing bridge tap issues on the data side?
-
1. Those dips / bumps suggest a bridged tap. It should be a fairly flat line, one smooth curve.
2. If all the extension sockets are dead when the faceplate is removed, then I think the number of sockets won't be the issue. Probably the best thing to do would be to take a full snapshot of the stats, including HLog, with only the modem connected to the test socket, and all the extension wiring disconnected.
-
Taking the Hlog values provided above, a quick plot of those values produced the attached (crude but usable) graph.
With that visual reference, I note that there are six minima present. The third, reading from left to right, appears to be the most significant (in terms of attenuation).
Attempting to smooth the curve by eye is somewhat awkward . . . I suggest taking the values at sub-carriers 8 & 3959 and join them by a smoothly declining curve not a straight line.
Considering the data that results in the plot, I have extracted the following as representing the six minima --
332 -20.1875 . <Minimum: sub-carrier 332, frequency 1432 kHz
1060 -28.5000 . <Minimum: sub-carrier 1060, frequency 4571 kHz
1781 -42.0000 . <Minimum: sub-carrier 1781, frequency 7681 kHz
2508 -28.7500 . <Minimum: sub-carrier 2708, frequency 11678 kHz
3236 -29.3750 . <Minimum: sub-carrier 3236, frequency 13955 kHz
3912 -28.5625 . <Minimum: sub-carrier 3912, frequency 16870 kHz
At this point, my evening meal takes priority. So the calculations will have to wait . . . unless j0hn or boozy completes the task. ;)
-
Hi jelv,
The tap is around 30-35m and probably just on one wire out of the pair.
Hope that narrows it down a bit.
-
Calculating the length of the bridge tap is over my head.
My advice is connect the modem directly to the test socket of the Master Socket with the use of a "rat tail" filter, even if this isn't practical for future use.
Gather a set of stats via DslStats and post Hlog/QLN images and a paste of the Hlog data.
35m distance calculated by boozy would suggest the bridge tap is external to the property.
With 7 extensions inside the property I would strongly advise making use of the test socket and repeating the above tests.
-
Weird, weird and ever weirder and totally confusing. :'( For some reason the HLOG doesn't change immediately you disconnect and reconnect* the modem. :wall:
The last time I resynced was at 22:35 last night. I haven't touched the modem or anything to do with the phones since.
I've attached two saved images of today's (2018-12-11) HLOG graphs from https://www.elvin.me.uk/DSLstats/Stats.php (https://www.elvin.me.uk/DSLstats/Stats.php) for the hours 16 and 17.
They look just a little bit different!
Why the delay?
Edit: * disconnect/reconnect after powering it all down upstairs, taking it all downstairs, finding the cables I needed and finally powering up again about half an hour or more later
-
I would strongly agree with j0hn about using the test socket.
I mentioned the single wire being likely (the dips aren't really low) because if only one wire was connected behind the master socket going to extensions it would only need 16 or 17m of internal wiring to cause the bridge tap to appear 35m. Likely to be external, but not definitely.
And since 17:44 you appear to have no tap anymore. It takes until the next DSLstats period to change for snapshots (2 hours usually), as that's went it actually saves the file. I never panic about things fixing themselves - but I would keep an eye on it
-
As the HLog now looks normal and I'm using the filtered face plate with all the extension sockets connected to the front plate plugged in to that I'm pretty sure the bridge tap is internal.
I was looking at the HLog in the DSLstats interface (not the data/files uploaded to my webserver) - surely I shouldn't be seeing the delay in there?
17:44 is nearly 19 hours since anything was changed!
-
Something very weird is occurring with that circuit. ???
Using the table (attached) taken from a JDSU Application Note, titled "Detecting Bridged Tap and Noise Interference in VDSL2 Access Networks using the JDSU SmartClassTM TPS", dated May 2011, and extrapolating I determined the tap to have a length of about 32 to 34 metres.
-
Was that analysis on the original I linked or data since I moved to the master socket?
I've uploaded an HLog file from this morning here: https://www.elvin.me.uk/DSLstats/temp/HLog-2018-12-12-08.59.13.txt (https://www.elvin.me.uk/DSLstats/temp/HLog-2018-12-12-08.59.13.txt)
-
I know DslStats used to upload Hlog to MDWS once an hour? but I thought it measured it more than that.
The bridge tap was internal then, and using the master socket has cured it.
Did you use a wired telephone from the same socket as the modem upstairs?
If not, leave the filtered faceplate on the master socket.
Connect the extension that you wish to use for VDSL2 upstairs to the A&B ports on the rear of the filtered faceplate.
This should send only data to the extension upstairs where you want the modem. No filter will be needed here.
Connect up the rest of the extensions you need at the master socket.
-
I wish it was so simple!
There is only one connection from the back of the removable front plate on the master socket. However one of the seven extension sockets could only be described as a rat's nest so the extension wiring is a mixture of daisy chain and star wiring. The master socket is in an unsuitable place for the phone base station/answer phone and I do use the socket in the office for a wired handset as well so we still have a phone in the event of a power cut.
At the moment the modem and router are downstairs and I am using homeplugs for the rest of the house. That means the modem and router are not on the UPS (they shared by NAS box UPS). I don't want to move the NAS downstairs as it and my main PC a connected using a gig switch.
Somehow I am going to have to get a cable from the master socket to a new data socket in the office, but I haven't a clue how!
-
Was that analysis on the original I linked . . .
Yes, I worked on the original data-set that you provided. The one which had the 10th Dec 2018, 23:47, date & time stamp.
-
My stats can be seen here: https://www.elvin.me.uk/DSLstats/index.htm (https://www.elvin.me.uk/DSLstats/index.htm) (history not working due to the way I am configured) and https://www.elvin.me.uk/DSLstats/Stats.php (https://www.elvin.me.uk/DSLstats/Stats.php)
History is now fully working on the Kitz custom interface (https://www.elvin.me.uk/DSLstats/history.php).
While the causes of my drop from 800000 to 740000 are fully understood and AAISP have acknowledged that they have been completely resolved, they are refusing to ask for the banding to be removed, telling me instead:
Your profile is capped at >74Mb/s down but think DLM (line management software) is doing what it is designed for.
-
It is indeed, but I don't think it was designed to NEVER remove banding, which happens more often than not.
-
Just to wrap this up: after someone else got involved AAISP did request the DLM reset which got me back some speed. DLM a couple of days later gave me back G.INP and it's been sat rock solid on 79999 sync with a healthy SNRM of over 7.5 ever since.
-
It's good to know that a satisfactory conclusion has been achieved.
-
Stage 2 will probably commence late January, but I have some investigation to do first. I'm thinking of having the master socket moved to a different room downstairs. It's a room that could be used as an office. It's also directly below the room I currently use and I think I may be able to get a cable from one to the other without too much difficulty.
-
Oh goodness banding, that takes me back.
I had it on my line for 6+ months, it never got removed, despite 30+ days of continuous connection - I think I got up to 70 days at one point. Luckily when I swapped provider from TalkTalk to BT, I got a new line and thus I didn't have the issue anymore. This was a year or so ago, I don't know if things have improved since.
-
My line was banded 74Meg on the 26th November 2017 and never removed off until 29th January 2018 with request dlm reset by plusnet staff to BTw and the line finally restored back to 80Meg on the 1st February 2018 after 67 days in total.