Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: GigabitEthernet on May 28, 2015, 12:47:41 PM
-
These threads are becoming quite common on here, aren't they. :no:
We've only had FTTC a few days but we've already had several issues. Connection instability, hugely decreasing SNR on the upstream coupled with a low upstream sync, lots of errors on the connection.
I have reported one of these issues on the TalkTalk Forum and I have got back this response today:
I'm sorry for the delay in responding. I've completed a line test which has detected a potential fault and the connection looks unstable.
Are you experiencing any issues with the voice service such as no dial tone or any noise on the line as this can affect the broadband connection and we would need to look into this first.
Thanks
It looks there is a potential fault therefore. I don't believe we're having any phone issues but I'll check again to be sure.
What I'll do is to put the HG612 back onto the line in order to do some constant stats monitoring (TalkTalk's Super Router makes this very tricky), to see if I can track down this SNR issue. The SNR issue is just like the one we had a year or so ago but it affected the downstream. Openreach eventually got their REIN team on the case and fixed the issue. This time the issue is affecting the upstream, meaning we get a lower sync than I think we should.
Essentially what happens is that the upstream SNR will drop from 6dB to 4dB or less in the space of a few seconds. It will remain at the lower level for sometime before gradually moving back up to 6dB. I am not 100% confident on this so hopefully the stats monitoring will help with that.
I suspect eventually an OR engineer will be sent out but the only thing that worries me is we only went live this time last week so will OR accept a fault yet? In addition, we do have an OR engineer coming to move the master socket but I am guessing this would be a PSTN engineer as opposed to a broadband engineer, if not I suppose both could be done at the same time.
Any advice, etc. would be greatly appreciated. Hopefully we can get this sorted out. :)
-
As mentioned in the other thread, logging of your linestats would be the most useful so that we can see what is going on.
-
Attached are my first set of graphs just a bit after a resync.
-
Id also be watching for any changes in SNRm. It may be easier to use DSLstats for that. Both programs can be used together, but just make sure that you set DSLstats to run in compatibility mode. The setting is under Configuration > Misc.
-
At a very quick glance, it appears that Alec's circuit is operating quite well up to about tone 1950 but it then rapidly degrades into "nothingness". The Hlog plot shows up the problem quite well.
If they were graphs produced for my circuit, I would be carefully scrutinising all of the wiring that I could reach. (Including the service feed to the NTE5/A.)
-
The NTE5 has the MK3 faceplate on it so all the extensions are filtered. I shall try the test socket but in the meantime may I enquire as to what the HLog should look like?
-
Here is an example of a "good" Hlog plot. (Please ignore the "down-up" at the transitions between the sections of the graph.) Essentially you should see a smooth decline in the curve when going from low to high frequencies.
-
So am I to infer that my line should be using all of those tones?
-
Not necessarily, due to line length from the DSLAM.
However, what the connection is capable of using at all should be displayed as smooth downward curves as attenuation increases to the point where it cannot be used for anything.
(See the attached example from my connection).
-
If it was a perfect circuit, with a short length between modem and DSLAM, then yes.
When the Hlog plot for your circuit is considered then clearly something is amiss. Up to approximately tone 1950 the curve is as expected. Then suddenly it just "falls off a cliff".
-
Despite my line not being error-free and only being stable for just over a day, DLM has decided to remove all interleaving and put me back on fastpath.
-
How do I graph the SNRM over time with the HG612 modem stats programs?
I've attached the dslstats version anyway.
Edit: I didn't realise the SNRM wasn't graphed unless you were graphing the ongoing stats. That's one issue solved anyway :)
Edit 2: I've attached the full monty ongoing stats for your enjoyment :lol:
-
If I were you (and in the interest of science!), I'd pop over to http://www.mydslwebstats.co.uk/Container.htm
It's a bit fiddly to signup/get the stats prog working but once you get it all working it's pretty cool.
If you get your stats program to upload every minute, you'll get your history over time (e.g. SNRM margin) plus you'll be able to compare your line with others (that way you can tell if there's something "wrong")...
-
Thank you for your response.
I had forgotten that I had previously registered for this fantastic website :)
-
Thank you for your response.
I had forgotten that I had previously registered for this fantastic website :)
Just looked at your stats and checked MDWS. What's the weather like at the moment? Is it raining?
-
From a quick look at the aforementioned website, my line would appear to be running at an appropriate speed for its length, however that is using approximately half the tones that it should be.
So in that respect, my line should, when it is running properly perform above average?
-
From a quick look at the aforementioned website, my line would appear to be running at an appropriate speed for its length, however that is using approximately half the tones that it should be.
So in that respect, my line should, when it is running properly perform above average?
The missing tones may indicate a problem either interference or a fault.
-
Thank you for your response.
I had forgotten that I had previously registered for this fantastic website :)
Just looked at your stats and checked MDWS. What's the weather like at the moment? Is it raining?
No it is not.
Why haven't some of the graphs uploaded (e.g. the Hlog)? Does that happen overtime perhaps?
-
HLOG, Quiet Line etc normally get sent each resync - depending on what you're using to upload the stats you might need to check some boxes to upload the additional info.
(I switched over to using the Raspberry Pi the other day and had to check some additional boxes from memory)
Just found your stats and have compared with mine - there's something very odd about how you line just drops off after a certain frequency (as others have pointed out).
I then checked some people close to you in terms of down/up speeds (HyssSnake and digginsa) and if you check their HLOG and Bits/Tone graphs you'll notice theirs tail-off gradually - yours ends abruptly.
Soooo....
Either there's something wrong with your line (outside the house) - perhaps you've got a lot of neighbours/crosstalk, perhaps you're close to a AM radio transmitter - or there's something wrong inside your house (most likely).
I read on your other thread that you didn't want to move the master socket, and there's some extension wiring in the house - that's probably the starting point for diagnosis. On top of this you might have duff filter/filters, crappy modem lead or crappy modem... or your modem is sat on top of a microwave oven (or something else which generates a lot of noise).
I'll have a read through your other posts and see if there's anything that jumps out...
*Edit*
So a quick look at your stats so far (and you need to keep these running for a couple of days really) is that you're currently in pole position in terms of CRC errors out of everyone else actively uploading stats right now (and many of those have longer lines/worse speeds). [OK, this keeps changing, but you're always in the top 3!]
This really does point to you needing to check over your extensions/wiring/filters. :(
-
I've been plugged into the test socket since the last resync :(
-
Ah.
Bugger. :(
Are you using a microfilter then? Possibly an idea to try another?
Is your mastersocket the entry point for the cable in to the house, or has it been moved? They can go wrong (just like a microfilter), but I guess we're in to fault raising territory now.
In one of your other posts you mentioned the cables all (well nearly all) being over head - I guess it's possible there's a fault there?
You also mention being 750M-ish from the cab, so you're probably doing a lot better than you ought to be - with that level of CRCs and you still don't have interleaving. This is really quite puzzling... :shrug2:
-
Are you using a microfilter then? Possibly an idea to try another?
The NTE5 has a MK3 faceplate on it currently; I was only using a filter for the test socket test. Previously I used a MK2 faceplate with FTTC and the line was identical.
Is your mastersocket the entry point for the cable in to the house, or has it been moved? They can go wrong (just like a microfilter), but I guess we're in to fault raising territory now.
It is the entry point. It hasn't been moved (yet).
In one of your other posts you mentioned the cables all (well nearly all) being over head - I guess it's possible there's a fault there?
The line to the house was (as I recall) replaced a few years ago but I don't think the line between the cabinet and the pole has ever been changed (must be 20 or more years old now: I do believe it is all copper however).
You also mention being 750M-ish from the cab, so you're probably doing a lot better than you ought to be - with that level of CRCs and you still don't have interleaving. This is really quite puzzling... :shrug2:
The weird thing is that DLM turned on interleaving and the line was still erroring like crazy, so I was very surprised this morning to discover that it had turned it off! :no:
Are OR going to accept a fault if the line is running as it should be? With only half the tones being used, might I expect that the speed should actually be better? I do recall one user on here getting 70Mb downstream on a nearly identical line length to mine but that's very rare.
-
Are OR going to accept a fault if the line is running as it should be? With only half the tones being used, might I expect that the speed should actually be better? I do recall one user on here getting 70Mb downstream on a nearly identical line length to mine but that's very rare.
OR will accept a fault if the speeds are lower than the minimum impacted speed - that can be found on the BT Wholesale checker (use address for TalkTalk). https://www.btwholesale.com/includes/adsl/main.html (https://www.btwholesale.com/includes/adsl/main.html)
They will also accept a fault I believe if there's lots of resyncs or there's a voice fault. The nitty gritty we all know about here doesn't normally constitute OR accepting a fault (or TalkTalk's tech support understanding what it even means). They usually run the line test, if it passes then nothing can be done as far as OR is concerned.
-
Well luckily for me TalkTalk's OCEs ran a line test and it is indicating a fault.
-
Hmmm... your SNRM is fluctuating wildly - in the minute or so I composed the attached image you went from 6.1 > 7.0 > 5.0... it shouldn't be doing that!
You've got a lot more bits per tone (on the tones that work), which is interesting.
I'll be honest, if I were sitting there next to your master socket I'd have a phone plugged in - I'd then unscrew the socket so I could see the wires going on the back and then give them a wiggle with phone off the hook and listen for crackles. I'd probably attempt to refix the wires if they were loose and crackly (with nothing connected to the socket).
...but...
...that SNRM... is it windy where you are today?! That could the overhead cables blowing about... (just thinking out loud).
-
Well luckily for me TalkTalk's OCEs ran a line test and it is indicating a fault.
Progress!!! ;D
-
Not very windy here today. DSLstats confirms that the SNRM is fluctuating like crazy :-\
-
How do I graph the SNRM over time with the HG612 modem stats programs?
Edit 2: I've attached the full monty ongoing stats for your enjoyment :lol:
Big increase in ES & CRC/OHFErr, as expected when being switched back to fastpath.
All the graphs are created individually & you can go back in time if you wish to focus on a particular element.
The examples I have attached are for the last 4 days from my own connection.
(I entered 4 d when running graphpd.exe).
-
Just a quick comment.
Looking at Alec's QLN plot makes me wonder if the circuit has poor AC balance. :-\ That graph does show a lot of extraneous RF ingress . . .
-
No reply from the TalkTalk OCEs today.
What we need basically is an OR engineer who will look at my graphs, which I suspect may be quite difficult? :-\
-
hmmm Ive just had a quick look at your graphs - not a pretty sight. What's your internal wiring like irrc didnt you need the master socket moving or something but ended up with self install? Is there a long run of extension cable.. I'll agree with b*cat theres a lot of what looks like RF ingress.
-
We've got an NTE5 with MK3 faceplate, so the extensions are all filtered. The HG612 goes directly into that: the modem cable is very short and I have changed it more than once with no change :(
-
@Alec - so you're back on interleaved (quelle surprise) and the CRCs have all but been eliminated...
Looking at your SNRM graph now shows an interesting pattern (ignoring the rapidly changing aspect) - an exaggerated dip over night.
Any progress on the line fault? Since Kitz and BC have pointed out "RF ingress", have you done the AM radio trick to look for local interference?
-
We had REIN issues on ADSL and Openreach got their REIN team involved. There was quite a lot of interference at one point but I believe they solved the issue.
That was only a year or so ago so I wouldn't think things would change that much in that time? We're in a fairly rural area with nothing that would cause interference between us and the cabinet, I believe.
I also believe we're the only live line on our cabinet thus far.
-
Got a reply back from the TalkTalk OCEs today, not good news :(
I'm sorry for the delay. I've re-run the line test which is now clear and the connection looks stable. The line is also in sync at 44.9mb which looks good in relation to the predicted speed for the line.
I can't see any recent speed test results. Could you run some more speed tests in a wired state so we can see how your speeds compare. Are you also using the Super Router or the BTOR modem and separate router?
For reference, the TalkTalk Community thread is located here (http://community.talktalk.co.uk/t5/Superpowered-Fibre-Broadband/Very-poor-speed-on-Fibre-Large-PLEASE-DO-NOT-POST-IN-THIS-THREAD/td-p/1678261/jump-to/first-unread-message).
Edit:
Looking at other peoples' graphs (this cannot be healthy :lol:) it seems to be that the SNRM on my line is dropping a lot more than anyone else's, at night. Now I understand that it would be considered normal for this to happen but surely it dropping so much on my line may further indicate a poor AC balance which bk* alluded to before?
-
As I expected, they won't do anything unless a line test fails :no:
However, the line does not look at all healthy, B*cat does point out the dip overnight, does indicate some form of possible interference.
REIN could be an issue, as for AC balance, I assume a line test picks this up if it were a problem? Although B*cat would have to correct me if I'm wrong on this as I'm not sure :)
-
The weird thing is TalkTalk's first line test said there was a fault. Literally nothing changed in two days so I don't understand why it's now coming back clear.
-
The weird thing is TalkTalk's first line test said there was a fault. Literally nothing changed in two days so I don't understand why it's now coming back clear.
An intermittent line fault would do just that. Test the circuit on one day: "Ah, yes, there's a fault", test the circuit two days later: "I do not see a fault. LTOK".
-
. . . as for AC balance, I assume a line test picks this up if it were a problem? Although B*cat would have to correct me if I'm wrong on this as I'm not sure :)
As xDSL operates in differential mode then part of the technique to prevent spurious RF ingress is to ensure that the pair of wires (of which the circuit comprises) is electrically balanced. The test for AC balance is one of the menu options on an Openreach technician's HHT.
The fundamental faults for which Alec could check are (in no particular order) --
- All internal wiring is with CW1308 specification cable (or greater).
- All circuits are using twisted pairs and that there are no split legs.
- There are no "dead ended" cables that have been left connected.
- There are no "cross links" between two separate branches of the wiring.
- That the service feed to the NTE5/A does not include any non-twisted cable, such as the figure-of-eight cross-section cable which was typically installed in the 1960s - 1970s.
-
We can tick off any extension problems surely as we're connected directly to the MK3 faceplate via a short DSL cable?
The line to the NTE5/A was only replaced five or so years ago so I don't think it will contain any non-twisted cable?
-
No reply from TalkTalk today, thus far.
I wonder if I can force through an engineer visit...
-
We can tick off any extension problems surely as we're connected directly to the MK3 faceplate via a short DSL cable?
The line to the NTE5/A was only replaced five or so years ago so I don't think it will contain any non-twisted cable?
Not wishing to be provocative but both of your above questions are based on assumptions. How difficult would it be for you to actually check?
You have a Mk 3 SSFP fitted at the NTE5/A. As a temporary test, power down the modem, remove the lower front plate of the NTE5/A to disconnect all extension wiring and connect a wired telephone to the socket so exposed. (The socket in the SSFP.) Once 30 minutes have elapsed since the time that the modem was powered off, then re-energise it. Harvest a set of snapshot graphs (Bit loading, Hlog, QLN & SNR).
Whilst waiting for the 30 minutes to expire, check that each and every telephone extension socket is not "live". Look to see if there are any long forgotten junction boxes. If your service is an aerial feed then check (with binoculars) that the drop from the pole-top DP to the premises is contiguous. Check where it runs down the exterior of the building for any joins.
You will now know the condition of the wiring, within and without. :)
-
As the sync speed is within the predicted speeds, we are unable to raise a slow sync speed fault to BT Openreach.
We can send a replacement router (Super Router) to see how the connection compares. Would you like us to arrange this?
???
-
As the sync speed is within the predicted speeds, we are unable to raise a slow sync speed fault to BT Openreach.
We can send a replacement router (Super Router) to see how the connection compares. Would you like us to arrange this?
???
As i expected :(
-
Looks like upstream interleaving has been enabled but the SNRM has plummeted...
-
Looks like upstream interleaving has been enabled but the SNRM has plummeted...
Looks like your stats have been down since around midday Alec?
-
Back online now - take another look :)
-
SNRM is still stuck at 4dB...
-
:hmm: Hmm . . . There definitely is something wrong with your circuit. :-X The problem is being able to point a paw towards the defect. I think you are going to need considerable patience and maintain a close watch on the circuit's performance. :(
-
TalkTalk are refusing to raise a fault with Openreach because the circuit is supposedly operating at advertised speeds. However, as I have tried to point out to them, the issue is the significant noise ingress and poor AC balance of the line.
To that they replied:
Can you run at least 3 speed tests at different times of day on the following speed tester, with PC connected to router by Ethernet cable.
http://www.supportal-test.co.uk/
Can you also please run 3 sets of pings and 3 sets of trace routes to www.google.co.uk and can you post the results
Did they even read what I wrote? >:(
-
Here are a couple of linked suggestions to contemplate --
- Terminate the contract with TT as unfit for purpose.
- Migrate the service to A&A and invite them to enjoy getting the circuit fixed.
-
On the phone with TalkTalk "technical" support.
-
Right I give up. An email is on its way to the CEO office.
-
Progress!
A fault has been raised with the Networks Team.
-
Progress!
A fault has been raised with the Networks Team.
:thumbs:
-
Glad to see that TalkTalk's Twitter team aren't useless. They're willing to add my graphs/data to the fault notes.
I'm not an expert on such things so would somebody suggest which graphs to send and a brief description of what is wrong in each? :)
-
I would suggest these:-
An ongoing FULL__MONTY montage for the last 6 days (plus possibly one for each day)
Snapshot montages from each resync
A copy of RESYNC.LOG with a manually added reason for each resync (if you know the reason)
An explanation for any gaps in the graphs.
Have you not been logging the stats 24/7?
It may also be worth including individual graphs from HG612 Modem Stats and/or MDWS for anything that needs particular focus (e.g. overall SNRM & SNRM per band).
I'm sure some of us would take a look and offer advice/suggestions if you were to post some/all of those in this thread.
-
I've recently migrated to a new system so the logs are split up but attached is one full monty.
Any large gaps will be when the system was turned off.
-
Snapshot graphs in order attached over the next few posts.
The last couple will be when TalkTalk asked me to do some tests in the test socket, a couple other may be when I was changing ADSL cables, etc.
To be honest, the connection has actually stayed up for quite long periods it just errors like crazy and the SNRM fluctuates a lot.
-
And more...
-
Yet more...
-
I don't know what others think but to me your really odd graph is SNR over time. The 5 day MyDSLWebStats of snr may be worth high lighting.
-
Thanks les-70. I have sent that graph to TalkTalk.
-
Some strange behaviour I have noticed is that as the downstream SNRM decreases, the upstream SNRM increases. Very odd.
-
I have collated the various snapshot montages into an animated gif file to see what has been changing.
A copy is attached for reference.
Your ongoing SNRM changes over the period plotted in the FULL__Monty montage is very concerning.
As are the Hlog changes.
Regardless of sync speeds/SNR/SNRM etc, Hlog data shouldn't really change much (unless there is some sort of line problem - possibly an intermittent HR issue?).
See the attached Hlog graphs from my connection.
The important parts (where attenuation isn't too high for my connection to use) have hardly changed in 3 years.
Ignore the absence of US data from the 2012 graph.
That was from an older modem firmware version that didn't actually report US Hlog data.
You have a reasonably highish DS interleaving depth & for US, the depth of over 180 is VERY high.
Would you mind zipping a copy of your modem_stats.log & posting it here for me to examine (if it's not already too large for a zipped copy to be uploaded)?
-
Thanks BE, much appreciated :)
I've got two modem stats logs, as like I say, I migrated to a new system. There might be some overlap or gaps therefore. Please find the most recent one attached.
Regarding the upstream, I'm getting SES on it so that may explain the high interleaving?
-
And here (http://www.filedropper.com/modemstatslog) is the earlier log.
-
Looking at your raw data log made me realise that the wrong data was being plotted for upstream SES.
I have corrected that now & attach an updated version of graphpd.exe
This version also now includes the DS & US SES data in the FULL__MONTY montage.
(See the attached).
Something seemed to have gone wrong with the times in parts of the log in that some of it included data supposedly from the previous hour.
This caused some 'spurious' spikes in the graphs & showing more than 60 minutes per hour for a short period, which I removed by manually editing my copy of your log.
Did you change PCs or synchronise the PC's time during the period you have been logging the data?
I'll have a proper look at the raw data after work tonight to see if I can spot anything particular that might point to the cause of your issues.
-
Yes I did change PCs. Sorry about that.
-
OR came to move the master socket today.
I think the Hlog is perhaps slightly better but not much.
-
That still doesn't look 'right'.
If everything is indeed O.K. internally, it does suggest some sort of external cabling issue.
Do you know if your D-side includes any aluminium.
Regarding detecting patterns of interference, it's hard to spot any due to the number of recent resyncs & intermittent logging.
Would it be at all possible to not force any resyncs & leave the logging running 24/7 for say 8 days in order to obtain a full set of stats?
FWIW, I have attached one of your SNRM graphs for approximately 3.5 hours back in May 2012.
It didn't look too great back then either.
-
Computer is now being left on as requested. Will not toifh the the modem either :)
-
TalkTalk wish to send out another BT Openreach engineer. Is this a good move?
-
I guess it may help. If your lucky they check everything. To some degree engineers differ in their response and another won't do any harm.
I remain puzzled by your stats. To me the Hlog variations are minor and may just reflect the small changes in the reported attenuation. That attenuation is probably based on Hlog. The actual Hlog plots vanish when they reach the upstream tones that don't have any bit loading and then reappear -but only show noise- on the downstream tones that also don't have bit loading. Maybe the upstream tones simply report differently? The changes in attenuation or Hlog look much too small to account for the SNRM changes which are I think are the main issue.
As noted early on by burakkucat I would be suspicious about the AC balance. My limited impression is that either engineers or Openreach don't like dealing with or raising AC balance faults and only do so if your line gets a definite fail for AC balance on their tests. I suspect dealing with such faults can be a lot of work and a pair swap will be the solution if it is available.
-
Got many days of stats recorded now. Would some graphs be useful? :)
-
Notably theres a decrease overnight quite substantially of the SNR margin. Which indicates an RFI related issue.
The ES count is low though, so DLM won't be likely to intervene. As for what's causing it, not sure? One of the others will I'm sure spot something soon.
-
Some graphs may be useful for a quick look.
What I have seen on MDWS recently seems to suggest quite a SNRM disturbance, generally peaking at around 22:00 each evening.
Any idea if anything in your own home could be the cause?
Could you upload your most recent modem_stats.log somewhere (or email it to me)?
Then could you please upload it again when it has at least 8 days of 24/7 logging in it?
-
http://www.filedropper.com/modemstats :)
-
http://www.filedropper.com/modemstats :)
Sorry but I will not be signing up to some other site just to download your log file. :no:
-
http://www.filedropper.com/modemstats (http://www.filedropper.com/modemstats) :)
Sorry but I will not be signing up to some other site just to download your log file. :no:
? You don't need to, select Download This File, then enter the Captcha and hit Download Now....
-
Using the log you uploaded (no signup required, b*cat), I have attached a montage for your connection, covering the last 6 days.
As SNRM is of most concern, I have also attached a higher resolution image of combined DS/US SNRM for the same period that can be zoomed in to in order to see finer details.
We can now see a general pattern for the timing of the issue, with the increases in error counts being the result of the reduced SNR/SNRM.
From memory, NewtonStar had/has a similar issue during the evenings.
His QLN graph indicates the frequencies being affected are those used by Radio China (or some other radio station(s).
This is not particularly unusual overnight, as you may/may not have noticed when scrolling through Medium Wave/AM radio stations during hours of darkness.
A lot of foreign stations can be clearly heard that are simply not heard during daylight hours.
Whereabouts are you located?
Someone else may be able to suggest which radio stations might be having this effect upon your connection.
My own connection doesn't appear to be too affected by this phenomenon, but I can clearly hear a Spanish radio station from around 20:00 each night.
I do also have some slight concerns regarding the appearance of your Hlog graphs that you have posted previously.
There is SOME indication of a possible HR issue at the higher frequencies that you connection can use.
There may be some mileage in rebooting the modem at around 22:00 or 23:00 one night (when SNRM generally seems to be at its worst), just to see what difference it makes to your QLN graph.
Doing this would no doubt result in lower sync speeds, so another reboot during daylight hours may restore the sync speed, but re-introduce increased error counts during the evenings.
What I have mentioned above could all be a red herring, but if not, it appears you would be unable to do much about it.
-
Rebooted just now. Hlog and QLN graphs attached.
-
Unfortunately, the 22:05 timing for that modem reboot couldn't have been much worse (as far as the experiment was concerned) as SNRM was actually at its highest levels (see the attached graph).
A few minutes earlier or a few minutes later would have been a different story.
I wouldn't recommend you keep rebooting the modem too often as DLM is likely to somewhat aggressive action.
If you do intend to try it again, I would suggest that you watch MDWS updating every minute & choose a time when SNRM is particularly low (around 4 dB or so).
-
Oh dear.
TalkTalk still wish to send an engineer. Should we go ahead with this?
-
Oh dear.
TalkTalk still wish to send an engineer. Should we go ahead with this?
Depends, double check its not a "Bright"spark ::) engineer and it is actually an Openreach engineer.
-
If TalkTalk are still seeing indications of a 'fault', it may be worth arranging the engineer's visit.
However, depending on what time he/she arrived, your connection could appear to be 'operating within acceptable limits' when tested on site.
See the attached graphs for the period between 06:01 12th June & 06:00 13th.
A line test between 11:00 & 13:00 on the 12th wouldn't really have identified a problem.
A TDR line test to identify potential causes of the 'issue' shown in your Hlog graph probably wouldn't have been conducted.
The Hlog graph does show that 'something' isn't quite right, but it COULD just be that the connection struggles to make use of those higher tones/frequencies, using what it can in a bit of a 'hit & miss' manner.
The disturbance at those higher frequencies is quite slight, but the fact that it cuts off suddenly does seem to indicate (to me) that some sort of physical 'issue' is present.
Between 22:00 & 23:00 on 12th would have been an ideal time for an engineer to conduct physical line tests whilst on site etc, but I can't see much scope for an engineer to be visiting user premises at that time of night.
Not all engineers are interested in looking at users' own graphs and/or listening to user anecdotes etc, so it could be the luck of the draw regarding the type of engineer that attends.
Your Interleaving depths & INP values do indicate that DLM took action due to seeing sufficient errors.
Whether or not BTOR would class that as a fault & fully investigate is questionable as many users' connections do need old fashioned Interleaving or G.INP to be applied to provide reasonable levels of stability/speed.
Have TalkTalk actually confirmed with you what type of 'fault' they are/were seeing?
-
They said they were unable to find a fault on the last test they did but on the previous one they did.
This is coming from the CEO's office.
-
What I would like to know is if losing 10Mb in one sync would be considered a fault?
The SNRM got stuck at 4dB for two days. The connection eventually dropped and since then the connection has been 10Mb slower.
-
Anyone fancy summarising this? :D
-
What I would like to know is if losing 10Mb in one sync would be considered a fault?
The SNRM got stuck at 4dB for two days. The connection eventually dropped and since then the connection has been 10Mb slower.
I lost approx 20Mb the line was holding on at 1-2db it finally dropped. My best guess is crosstalk as it drops a further 1 or 2Mb every so often. The 20Mb drop I assume was a major disturber.
-
It's a rural area, I think there is one other line enabled on the cabinet. I doubt it is crosstalk.
Bald_Eagle, is that event in the graphs you've generated for me?
-
From what I have read, depending where the pair is located in the bundle from the cabinet, a single crosstalk disturber can cause a loss of sync speed by up to 30%
Rural areas sometimes = electric fences, which can cause interference, possibly increasing when an animal touches one of them?
To which event do you refer?
If you mean when the other line was connected, do you have a rough idea when that was?
Do you have any idea what might have caused any of yesterday's disturbances? (See the attached MDWS graph).
-
No idea I am afraid.
It is weird though that it seems to sometimes affect the upstream and at other times, the downstream.
Perhaps this interference is the reason for my rather poor (IMO) upstream sync?
-
Engineer arriving on Monday between 8 and 1.
What should I be asking them?
-
DLM has removed upstream interleaving for no apparent reason.
-
According to MDWS, G.INP is off completely
-
It's very odd why DLM decided to remove interleaving when the upstream wasn't error-free but oh well.
SNRM is still going up and down like a yo-yo.
Which graphs should I be showing the engineer and what should I be asking for?
-
A user on MDWS, craigv, seems to have a very similar looking line to mine:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FTi1lrG3.png&hash=1e5110eabf709f6984311df339d6a5536f035f19)
-
Another thing I've noticed: my attenuation has gradually got bigger?
It's gone from 23dB up to 23.3dB in the last 20 days or so. Surely that's not right?
-
I am still not sure that anything is amiss in your Hlog. Looking at all the people with syncs of about 38Mb/s it seems normal for the upstream values to only be shown when an upstream tone achieves a bit loading. You have just picked one such example.
It is also normal for attenuation to rise as the weather gets warmer and wire resistance increases, your increase could be just that.
Has an engineer measured your lines AC balance and advised on how it compares to good/fault values. I remain of the view that the fluctuations in snrm are to only clearly unusual feature of your stats. That odd behavior may be a bad and changing noise background on a good line or more average noise aggravated by a line with poor AC balance.
If it just noise it is possible that an RF3 might help. It will loose you about 1Mb/s but help IF the noise is common mode. Usually it is not common mode and it does not help but it is worth a try. If you have one or get one is it best to wire it up into a RJ11 cable so it trivial to insert and remove. ahead of the modem
-
Another thing I've noticed: my attenuation has gradually got bigger?
It's gone from 23dB up to 23.3dB in the last 20 days or so. Surely that's not right?
My attenuation fluctuates from time to time, seems to be nothing to worry about. When my HR fault was repaired, Attenuation didn't change
-
I'm getting conflicting views here.
Is my line faulty or not? :)
-
Hi Alec - see you're on Plusnet and ThinkBroadband as well...
I'd say there was a problem owing to the wild fluctuations in your SNRM, I don't think attenuation changing as per JIDs comment is much to worry about. Everything is supposed to change over time depending on the temperature, or at night when your line acts as a large radio antenna - your line is made of metal so resistance etc will change depending on various factors.
It just shouldn't change as wildly as yours does - that's indicative of a dodgy joint or some kind of electrical interference.
-
^ Thank you :) That is what I thought, I just wanted confirmation that I'm not going crazy! ::)
Is the engineer likely to look at my graphs if he sees that they come from a "hacked" HG612?
-
Is the engineer likely to look at my graphs if he sees that they come from a "hacked" HG612?
From experience, some engineers will be keen to look some won't even realise you can hack the HG612.
The engineer I last had was great, he saw the MDWS graphs and said something looked wrong and off he went, however in the past I've had an OR engineer who didn't understand the graphs at all :-[
All depends on the engineer you get
-
Is the engineer likely to look at my graphs if he sees that they come from a "hacked" HG612?
From experience, some engineers will be keen to look some won't even realise you can hack the HG612.
The engineer I last had was great, he saw the MDWS graphs and said something looked wrong and off he went, however in the past I've had an OR engineer who didn't understand the graphs at all :-[
All depends on the engineer you get
That's exactly what I found when I had numerous engineer visits until my intermittent HR fault was finally found & permanently repaired.
Since I had FTTC installed back in 2011, I have noticed that attenuation gradually increases (with lower sync speeds) during summertime & decreases (with higher sync speeds) in winter.
It's currently on the increase (see attached).
It is usually at its highest in August & at its lowest in January/February.
Your fluctuating SNRM, Sync & Attainable rates, Errored Seconds & other error counts over a long period would be the ones to show the engineer (if he/she is interested).
I'm not sure that your intermittent logging will have captured all the relevant details, but there should be sufficient to get a 'feel' for how your connection performs.
I did notice previously that you had one or 2 large/spurious spikes in your graphs due to intermittent logging that masked the underlying issue to an extent.
If you wished to upload a copy of your modem_stats.log again I could manually edit those spikes out for you.
-
New modem_stats.log: http://www.filedropper.com/modemstats
-
I'm getting conflicting views here.
Is my line faulty or not? :)
On the evidence available I would say that your line is probably is faulty but not definitely faulty. The SNRM variations look to be noise and not varying attenuation. If the engineer makes a full line test including AC balance and a TDR check he ought to see any actual faults. As I said before assuming it is a noise problem it could be due to poor AC balance or just the bad luck of a noisy environment. If the AC balance is measured and shows a fault condition the engineer will do something. If it is just poor and not bad enough to qualify as fault only some engineers will respond. The same with the TDR results.
-
Is the engineer likely to look at my graphs if he sees that they come from a "hacked" HG612?
I doubt he/she will care. But, being honest, just make sure you've got graphs to back up your claim (of a noisy line/poor SNRM) to hand. My general experience is that they're all good guys, just all in a rush (so make it easy for them).
The SNRM is probably the most useful, since it shows something an engineer might be familiar with.
Just remember it took Bald Eagle a while to get his line sorted; just stick with it... 😉
-
New modem_stats.log: http://www.filedropper.com/modemstats
FWIW, I have attached ongoing montages for the last 2, 4 & 18 days for your connection.
Could you possibly post Plink logs from before & after you lost any valid US SNRM data for the U2 band?
i.e. before 21:40 20th June & after.
There is no evidence in modem_stats.log that the connection resynced at that time.
Could you also post a copy of your RESYNC.LOG for reference?
-
Just remember it took Bald Eagle a while to get his line sorted; just stick with it... 😉
That 'while' was almost 11 months !!! :'(
They do say that "patience is a virtue" :angel:
-
So I don't know what's happened but my SNRM is now negative...
-
Temporarily it looks like I had quite a number of available tones.
-
SNR graph...
-
Did you initiate this morning's resync?
We had a power cut in the early hours this morning & my attainable rate had shot up by around 7 Mbps when the connection modem resynced.
SNRM was low by the time I got up though, no doubt due to 'other' connections gradually resyncing, so I manually resynced the connection & normal SNRM/attainable rates etc. were restored.
-
No that was not my doing!
The SNRM instantly dropped upon the resync, it was at about 6dB just prior.
-
Possibly BTOR testing/messing with the connection then in readiness for today's visit?
Or (hopefully) further evidence of a line fault that might be easy to track down?
-
Engineer is here.
AC balance was fine, all tests on his JDSU passed, so he's trying to build a REIN case.
-
Engineer unfortunately couldn't do a lot (he tried very hard to be fair to him) as all his tests came back clear so there was very little to go on.
He said just keep the graphs going for now.
-
The engineer did say he had re-made the connections in the cabinet and on the face of it, this appears to have reduce the SNRM drop overnight.
However, the Hlog still looks odd.
-
Engineer is here.
AC balance was fine, all tests on his JDSU passed, so he's trying to build a REIN case.
What was the figure?
-
What was the figure?
59 I think?
-
I just had a thought: if I purchase a JDSU I could constantly monitor the connection and then that might help in the fault diagnosis? :)
-
You could, but wouldn't you want to use your internet connection?
-
I've got a backup 4G connection :)
I'd just like to know if it would work?
-
However, the Hlog still looks odd.
Howdy - scraped some numbers from MDWS and put together this little graph, comparing your HLOG with a couple of others (hope BE1 and Kitz don't mind me picking on them!).
The "problem" with the graphs on MDWS is that if you flick between users and compare, they're not on the same scale.
By picking people with different attainable speeds (forgetting interleaving etc), you can see (hopefully) that this probably shows where the useful tones are. What you really want is a continuous line (like Kitz) - where it starts to look "spotty" they're probably tones that cannot be used.
So, in a round about way, your HLOG isn't really odd it just shows you have a longer line than Kitz or me, and a shorter line than BE1 (or at least that's how I read it).
-
Given that your line passed tests I don't think you would learn much that can't seen from running and using your connection. The SNRM is giving an indications of the varying noise and any attenuation changes can be seen. Bitswaps per tone in DSlstats are a guide to troublesome frequencies.
As I mentioned before you could try using an RF3 to see if that helps. If the noise is common mode noise it will give some improvement through noise reduction. If the noise is differential mode then there will be no improvement and all it will do is cost you about 1Mb/s. Some engineers would have fitted one in case it helped.
-
Les, looking at the graph I posted, do you know what the "cut off" dB would be for HLOG/useful tones?
I suspect that the modem is super sensitive and can register things below -80dB but there's insufficient headroom to do anything useful at those frequencies.
In which case we should discount anything below the -80dB line - and then it doesn't look noisy as such, it's just a long line.
Can anyone else shed any light on this?
*edit*
Just checked the bit loading vs dB on the HLOG. It seems that (dependent upon frequency) the cut off for getting a "bit" per tone seems to be in the region -65 (higher tone) to -68dB (lower tone).
-
Is 750m considered long?
-
I'm not sure if 750M is long or not - but it's longer than (say) Kitz's or my line (about 500-600M). Everything is relative and speeds tend to "fall off" the longer the line more quickly than with ADSL.
I might be wrong, but I seem to recall BE1 is about 1200M from the cabinet.
-
Oh I see, yes that makes sense then.
I think what I'll do is to get another modem (Billion 8800NL I think) to see if that handles the noise any better and perhaps I'll consider getting the JDSU, just out of curiosity really :)
-
I just had a thought: if I purchase a JDSU I could constantly monitor the connection and then that might help in the fault diagnosis? :)
You could. A JDSU HST-3000c can be configured to act in place of the CPE (modem) and with two Ethernet patch cables you would be able to use the service whilst monitoring it. (I believe the same is true for an Exfo AXS-200/635.)
However are you prepared to pay £thousands for a new device or a significant number of £hundreds for a used device via, say, eBay? :o
An example: Exfo AXS-200/635 (http://www.ebay.co.uk/itm/111695969080). Three examples: JDSU HST-3000c, No 1 (http://www.ebay.co.uk/itm/331568174210), JDSU HST-3000c, No 2 (http://www.ebay.co.uk/itm/321774405016) and JDSU HST-3000c, No 3 (http://www.ebay.co.uk/itm/391173224533). :swoon:
-
Does this look okay, burakkucat?
http://www.ebay.co.uk/itm/jdsu-hst-3000-Bt-Telecom-Tester-/271894200837
-
Does this look okay, burakkucat?
http://www.ebay.co.uk/itm/jdsu-hst-3000-Bt-Telecom-Tester-/271894200837
At a quick glance and without sight of any precise details other than "Used for copper and fibre installs" (there is no mention of which SIM is included) I will tentatively say "Yes".
-
Sorry, SIM?
-
Sorry, SIM?
Service Iterface Module. :)
-
*edit*
Just checked the bit loading vs dB on the HLOG. It seems that (dependent upon frequency) the cut off for getting a "bit" per tone seems to be in the region -65 (higher tone) to -68dB (lower tone).
I would concur with those suggested values.
FWIW, my line is around 1100m (confirmed exact route, physically measured with a trundle wheel & allowing for down one pole and any 'slack' within joint chambers etc.).
I initially thought it was shorter than that, but I am now aware that it doubles back on itself in 2 places, adding approximately 200m to its 'real' length.
The 1100m is also confirmed by a visiting engineer's JDSU readout (see attached).
-
Sync has dropped another 5Mb today at 9AM this morning, to 31852 Kbps.
The minimum we're supposed to get it 25.7 so we're getting closer and closer to that...
-
RF3 should be arriving at some point today, I've also got a much higher quality VDSL cable (Cat 6 cable) installed.
-
Sync has dropped another 5Mb today at 9AM this morning, to 31852 Kbps.
That's the kind of drop I had when my neighbour got fibre... >:(
-
SNRM is reducing less at night, by the looks of it?
-
Don't really know what to do with this now.
-
Don't really know what to do with this now.
Tell TalkTalk that their service is unfit for use?
Migrate to A&A and invite them to enjoy having your service operating correctly?
:shrug2:
Sorry Alec but it is your decision as to what you now do. But please keep us updated . . . :)
-
The issue is, A&A don't support the use of the landline for anytime calls, they're also outrageously expensive.
-
I can't see any drop in your attainable in last few days and otherwise things look a but more stable. I remain of the view that a noisy line of your length can look like yours. The RF3 may help.
What you do really depends on what you use the line for. For my use I would cap the speed down to about 3Mb/s and hope that with the reduced errors, interleaving would be removed (after up to 3 or 4 weeks) and if it is enabled on your DSLAM you may just get just G.INP which would probably be ideal. If interleaving is removed you could cap the speed at a higher level similar to one that interleaving currently gives in order to keep it stable.. The speed won't be the best but for me fast path always feels better even when just using the web.
You could also consider a move the Plusnet or ZEN in order to get the fast DLM profile (and different support team). This would allow twice as many errors per day before interleaving hit. I am with TTB and cap my speed to ensure fast path. Without the cap it can be fine for month then one big noise burst will cause interleaving.
-
I did try the RF3 but I couldn't get the HG612 to sync with it :(
Can you just confirm the correct way to wire it?
-
I did try the RF3 but I couldn't get the HG612 to sync with it :(
Can you just confirm the correct way to wire it?
As a result of a fellow Kitizen's trouble in wiring a BT80B-RF3, a brief guide (http://forum.kitz.co.uk/index.php/topic,13976.0.html) was written and Eric deemed it should have "sticky status". ;)
-
May I ask, does the incoming wire go into the screw terminals or the IDC terminals?
-
I think they are usually wired -screw in- for the drop wire side and -IDC- out to house/modem. I don't think it actually maters which way round it is used. I think the choke response should be symmetric. If you ease the pcb out of the case the devices circuit is fairly clear.
-
Connection has now been up for ten days so at least it's stable.
SNRM seems to be dropping less than previously but I cannot help but feel disappointed in the performance :(
-
Talking to TalkTalk's CEO office (even them) is a recipe in difficulty.
None of them seem to understand my graphs! :(
-
I trust you marked them; Top, Bottom; Left, Right. ;D
-
I'm just wondering if the sync speed on my line is likely to improve when the fault is "fixed" because otherwise this whole process seems a bit pointless...
-
Just had a random resync?
-
TalkTalk's CEO office have been firmly told to not send another engineer unless they send one with local knowledge, knowledge of HR faults and knowledge of my graphs :)
-
Another engineer is scheduled for Monday. I can't help but think that this isn't going to result in much.
-
Is anyone going to offer input on this or am I on my own now?
-
What do you want to know before the engineer's visit?
-
Well I'd like to know if it's even worth having an engineer's visit...
-
Well I'd like to know if it's even worth having an engineer's visit...
Yes it is as long as you don't get charged, make sure the issue is not in your premises and make sure any broadband DIY cable jobs look good that's all i can tell you as have only had one BTOR Engineer visit my premises since Broadband/Internet was born.
-
Here's my SNRM for instance over several weeks:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FLGomWUk.png&hash=986d63b3d393bc2ddccdd9c19140270bf8e6639a)
I just cannot believe that is normal?
The other thing I have noticed is my Hlog graph has changed from this:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FzrYcHuR.png&hash=0ee498c40492852cc6c7f74b2e8778af5fca3734)
To this:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2F1AUgBa7.png&hash=dd575af4f58bc4c5e73719c67e8d9cc194e7e0bf)
-
Yes SNRM changes all the time by small amounts on noisy lines 0.5 to 1.5 i don't like the SNRM large swings of SNRM from 7.0 to 3.5 dB but the BTOR Engineer need to see this happen in realtime with his JDSU.
My experince with showing modem stats graphs to engineer was a waste of ink he did not understand and did not want to understand it's a pity but some just see it as a job and not hobby.
-
:hmm: It will be no solace to you but looking at the latest details you have offered up for inspection it is clear, to me, that your circuit is rather unwell. Unfortunately your CP is a "bargain basement" provider. :-X
-
I have not read all posts, but given what you described in post 1 that is an issue.
Whether its a faulty line tho is another matter, I suspect any fault or source of interference would be hard to get tracked down if exists. A pair swap may improve things but now days they need a reason to do one, not just because a customer isnt happy.
Talktalk seem willing to send you engineers so not sure if plusnet would help you more there other than been on the speed DLM profile.
-
Further to what Chrysalis is saying a pair swap is normally only done with a reason, I had a pair swap when the line was dropping all the time.
Engineer did say though there needs to be an actual fault to do one as I did ask him at first and he needed to take the jdsu along the line to trace a very faint HR fault.
-
How do they connect the JDSU to the line when they're tracing a fault a long a line? I've always wondered this.
-
I want this line! :(
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FrTgOfIr.png&hash=b970144ad86b2bde4c5a67e6bc36d7c0cf8e05ea)
-
How do they connect the JDSU to the line when they're tracing a fault a long a line? I've always wondered this.
Via the Master Socket thats all it's supposed to connect to :-\
-
Via the Master Socket thats all it's supposed to connect to :-\
No I meant if they're out repairing a fault can they not connect equipment to the line at a joint or something?
-
Via the Master Socket thats all it's supposed to connect to :-\
No I meant if they're out repairing a fault can they not connect equipment to the line at a joint or something?
As far as i can see the JDSU will show a fault on the line when connected to your master socket it should show where on the circuit be it 0.5 meters or 1km away and further.
-
And how does it do that? :)
-
And how does it do that? :)
Reflected Pulse you need to talk to Burakkucat for more information :)
-
I know FECs aren't important in terms of DLM but I'm wondering if the amount on my line might be yet another indication of an underlying issue?
Is 348514 FECs in nearly 9 hours excessive? In that time we've also had 76 CRCs and 28 ES - this is on the downstream.
The upstream reports 76221 FECs in the same time period.
-
I remain of the view that it is hard to be sure whether your line has a mild fault that Openreach has not picked up or whether you just have a rather noisy environment influencing the line. Could you post the bit loading per tone when the SNRM is a max - typically in the day and also when it is a minimum say ~21:00 in the evening. I am wondering whether it is possible to spot any signature in the change in bits per tone.
It would also be good to see what happens if you use the RF3 and what difference, if any, it makes. From my own experience i suspect that you won't be able to better the HG612 for error rates. Other modems may give a better sync but they can also give higher error rates.
-
The thing is that we're in a very quiet semi-rural area.
There is nothing between us and the cabinet that immediately pops out as being a source of interference. There is a pub but since the interference appears to be there all the time, not just when the pub is open, would seem to indicate that that isn't the cause.
The fact that previous fault tests have picked up a seemingly intermittent fault that magically goes away would seem to indicate an issue of some kind. The telephone line has been crackly in the past (I didn't actually know about this but other family members have indicated this) so this would seem to indicate some external issue.
I remain puzzled by the missing upstream tones because as has been said by others, the graph is looking quite healthy when suddenly all the tones just vanish.
-
Could you post the bit loading per tone when the SNRM is a max - typically in the day and also when it is a minimum say ~21:00 in the evening. I am wondering whether it is possible to spot any signature in the change in bits per tone.
Here you go .. anyone can do this if they want....
-
The strange thing about my line is that with only half (?) the tones for the upstream being available, the upstream is still syncing at almost 8Mb.
Looking at other lines with similar attenuations, some achieve lower upstream syncs with more tones available.
Can the modem dedicate more power to the tones that are available? I remember previously it was stated that the bitloading is better on the tones that are available.
-
Tony's helpful addition has both educated me and answered my question - thanks Tony. Looking at the bits per tone it looks like it is the higher frequency band that being hit most in the evening and with a dip towards the highest frequencies that are used. That does make it look like RF noise but an indication of such noise can mean lots of noise about or a line which is prone to picking what ever noise there is. Usually indicated by poor AC balance -- which the engineer ruled out.
As you say the absence of any bit loading at all in the higher frequency upstream band is odd given the preceding bit loading in the downstream band.
Not much help I am afraid but the slow drifts in SNRM up and down do seem to be RF noise and not cross talk. If and it is a big if, the noise is common mode, the RF3 should help but often the noise is not common mode.
-
I still couldn't get the RF3 to work and I tried multiple cables :(
I'll see if I can get the engineer to fit one on Monday.
-
Usually indicated by poor AC balance -- which the engineer ruled out.
The particular test he ran passed yes but the issue I believe to be intermittent (TalkTalk did have one failed line test for instance, as did Plusnet a few years ago).
I'm just going to try my best to get the engineer to do a D-side change which he may or may not do ???
-
isnt a mk3 the same as a rf3? but just tidier and easier to install?
-
Maybe that's why it didn't work on my line...
-
I still couldn't get the RF3 to work and I tried multiple cables :(
I'll see if I can get the engineer to fit one on Monday.
TBH AlecR i gave up the hunt to cure RFI and also used the RF3 my RFI is coming in from Radio stations thousands of miles away during late evening, the DS SNRM decreases and chucks of tones disapear around 7300 Khz or tones 1674 to 1690.
Just stick with the SSFP MK3 if you have one fitted.
-
I still find it hard to believe that RFI is a major issue around here, like I say it's a very quiet semi-rural area.
I just cannot believe there isn't some kind of issue with the line.
-
I just cannot believe there isn't some kind of issue with the line.
This is the way i look at it the longer the D-Side there is more RFI that's being picked up, think of it like a big aerial, the guys close to the cabinet have small aerial's so less RFI being picked up.
-
No I fully understand that - I'm not arguing against that! :)
What I'm attempting to argue against is that my line is somehow performing "as it should".
-
What I'm attempting to argue against is that my line is somehow performing "as it should".
To say your line is performing as it should you would need to know the D-Side distance to PCP cabinet the quality of the pairs and and condition of joints there a loads of variables in just those three parameters that ends at the modem and then displays stats for your circuit.
-
The Hlog alone appears to show issues.
-
The Hlog alone appears to show issues.
I've looked at it twice and it's good, has a nice gradual curve and no large lumps & bumps during it's course.
-
And the Hlog seems to have lost all tones on the upper end now:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FxtWYy6m.png&hash=9c9997f1156ae0e6e9b5a6fa4efb950dd46ce0f3) (http://imgur.com/xtWYy6m)
Edit: and my attenuation has dropped to 21dB. I've never seen it that low before.
-
And the Hlog seems to have lost all tones on the upper end now:
Edit: and my attenuation has dropped to 21dB. I've never seen it that low before.
The Hlog curve continues to be a puzzle. We can "see" where is should lay above approximately tone no. 2000.
As for the attenuation, lower is better.
-
I've just never seen it vary that much before, burakkucat. It might vary 0.1 or 0.2dB but never this much.
Am I right to assume that an HR fault might cause this sudden loss of all available frequencies?
-
The MK3 SSFP has a weak version of a common mode filter set so as not to damage 80/20 speeds. The RF3 is much stronger and if there is no RFI rejection benefit it may take about 1mb/s off a 40mb/s sync. I would not get the engineer to fit one permanently as if it does not help you may be stuck with it. Can you post a picture of your wiring of the RF3 it is very unusual for one not to work unless it is incorrectly wired.
The Hlog for upstream tones is simply not shown unless there is a bit loading. For downstream I think Hlog appears anyway except that if it is very small I don't think it gets plotted. The higher frequencies may not be shown now due to increasing cross talk or noise.
-
But the question remains: why is there no bitloading when the line appears to be working quite nicely until, as burakkucat says, it falls off a cliff...
-
As for the attenuation, lower is better.
Have a memory during the time around Febuary a small Upstream U2 band developed the attenuation was lower due to colder temperatures and then disappeared late march as the attenuation started to rise due to warmer temperatures.
-
But a loss of 2dB in one go? Is that normal? I must confess I don't know.
-
I agree that that the bit loading is very odd and I don't understand it. I have often noticed that upstream bit loadings on vdsl bands look odd though. My upper two bands show about the same bit loading and don't match what you would expect at all.
Your apparent drop in attenuation may just be due to the total drop of any bit loading in the higher frequency downstream band. If you look at the attenuation per band you can see the sudden change.
-
I agree that that the bit loading is very odd and I don't understand it. I have often noticed that upstream bit loadings on vdsl bands look odd though. My upper two bands show about the same bit loading and don't match what you would expect at all.
First of all, I would like to say thank you as this is definitely making it easier for me to understand what's going on here :)
The thing that is strange about my line is that if you take a look at some (but not all) similar attenuated lines, if they do show most of the bits for the upstream, the upstream sync is still very similar to my line.
But I am only using half of the available tones...
-
Indeed have had a look at your attenuation is has dropped by 2dB that is odd and very uncommon you my see 0.1dB + & - during a resync of modem.
Maybe a long modem power off period for 8 hours could help here and if you have still a BTOR visit booked from monday then i would do as much as you can internally and tick the boxes.
-
I cannot really turn off the modem for too long - the family want to use the Internet all the time :(
-
I cannot really turn off the modem for too long - the family want to use the Internet all the time :(
they all must need to go to bed at some time ! 3am to 11am just tell them the broadband line is down and curse your ISP ;)
-
I don't think they'd believe me I'm afraid :(
I might be able to make it to four hours tomorrow whilst everyone is out?
-
I don't think they'd believe me I'm afraid :(
I might be able to make it to four hours tomorrow whilst everyone is out?
It's up to you sometimes the modem gets odd info and there is no way you moved say 130 meters closer to the cabinet as shown by your attenuation unless your in a caravan.
Or Just wait until monday for the OR engineer to survey your line
-
I'm hoping this engineer might actually do some line repairs if I can convince him of the HR fault.
How does an overheard D-side change work? Am I right in saying that there will be multiple lines in the cable?
-
How does an overheard D-side change work? Am I right in saying that there will be multiple lines in the cable?
In the words of manuel (Fawlty towers) "Hii knoow nooothing"
-
Your apparent drop in attenuation may just be due to the total drop of any bit loading in the higher frequency downstream band. If you look at the attenuation per band you can see the sudden change.
Do look at the attenuation per band I mentioned before. The attenuation on the used bands has not changed. A value for the higher frequency has just vanished probably due to no bit loading. The overall attenuation is somehow based on all three values so the change is a change in bit loading and the calculation and in not in attenuation.
-
Regarding Winter/summer attenuation changes, take a look at the example from my connection from January.
I do see increased attenuation, lower attainable rates & lower sync speeds every summer.
Since I started logging my stats back in 2011, August has always shown the highest attenuation.
Also, remember that some stats such as QLN & Hlog only update when the connection retrains.
It is feasible that conditions can change fairly significantly between resyncs/retrains.
If SNR/SNRM have also reduced due to increased crosstalk and/or increased RFI (maybe increased 'skip' propagation etc.), it can effectively rule out any use of the next higher band altogether and/or only be able to use a few tones from it.
-
These attached examples demonstrate the loss of tones available for bitloading since G.INP was activated in March.
The reduction has been gradual though, in line with the attenuation increases from my previous message.
-
Do look at the lines of Bald_eagle1, Steveh and nstar, they have exactly the same bit loadings as you do as do others with similar sync. I conclude that your cliff edges and bit loadings are normal for your sync. Those lines also don't show attenuation for the D3 band with no bit loading so your change in attenuation must be just due due to the loss of your tiny bit loading in that band.
I really think your issue is just a noisy line. If your line still passes all the tests a pair swap would be worthwhile and should help if there is real underlying fault.
-
Also see the increase in attenuation as depicted by my Hlog graphs from March & today.
There is currently no sign of anything at all in the D3 band.
Based on previous years stats, I expect things will gradually improve between September & February.
-
Just for interest, see the attached for an example of a Hlog graph that really shows some physical problems (most probably bridged taps on the internal wiring arrangement).
-
I was under the impression that it wasn't normal for the Hlog to just "fall off a cliff". I'm so very confused :no:
-
If you could generate or post a recent Plink log I'll have a look at the raw data.
It might be later on today before I can get round to it though.
The attached example from your connection from 14th June definitely doesn't look quite right.
-
Here (http://www.filedropper.com/plink20150719-0600) you are :)
-
Just had another unexplained resync.
I've had a few of these recently - could this link to the fault?
Edit:
New Hlog:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FLxud8Sx.png&hash=94c493f0e53014a1a5bff2f29d0708ec578885a3) (http://imgur.com/Lxud8Sx)
-
It looks like attenuation has increased slightly and SNR is now too low to use the U2 band.
(see attached)
Do you still have the Plink log from 14th June that you could post for comparison purposes?
-
Just had another unexplained resync.
I've had a few of these recently - could this link to the fault?
Quite possibly.
Does SNR/SNRM take a big, sudden hit (or even cause a resync) when dialling out from your landline?
If so, does it suddenly improve when dialling in?
-
Do you still have the Plink log from 14th June that you could post for comparison purposes?
Here (http://www.filedropper.com/plink20150614-0900) is the Plink log from the 14th June at 0900 :)
-
The attached example from your connection from 14th June definitely doesn't look quite right.
I believe that is the plot which prompted me to utter the "falling off a cliff" description.
-
I believe that is the plot which prompted me to utter the "falling off a cliff" description.
Is that still your belief for the newer Hlogs? :)
-
Is that still your belief for the newer Hlogs? :)
At a first glance they would cause a concerned second look. But if you refer back to what les-70 has suggested (about there not being sufficient tones with bits loaded for an entire band to be present and used) then they are less disconcerting.
Do look at the lines of Bald_eagle1, Steveh and nstar, they have exactly the same bit loadings as you do as do others with similar sync. I conclude that your cliff edges and bit loadings are normal for your sync. Those lines also don't show attenuation for the D3 band with no bit loading so your change in attenuation must be just due due to the loss of your tiny bit loading in that band.
-
I did take a look and yes I agree however the question remains: why can those tones not be used?
-
Because the line attenuation is too high at 90.3 dB
-
But why suddenly is it too high when the previous tones are loading just fine?
-
It's not suddenly too high, it's rising with frequency.
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 8.9 42.2 64.6 N/A N/A 18.0 51.6 90.3
-
So why have I raised a fault then - *sigh*
-
As I said a long while ago you may just have a noisy line. My own view is that if an engineer is on their way then just focus on the variations in SNRM, mention the the odd resyncs and suggest that your seeing more RFI pick up than you think is normal. However note that the RFI seems to be in the evenings so the engineer won't see it.
A pair swap might help but if it is noise source and not a line fault the new pair may be better or worse. Your line attenuation is very steady so I doubt there is an HR fault. As I mentioned the recent drop in overall attenuation is only a side effect of a minor loss of D3 tones.
My line is noisy but I cap the sync speed to the speed levels which occur with interleaving and this avoids interleaving occurring due to odd noise bursts. It annoys me that an event which does not occur most weeks is enough to keep me interleaved unless I cap the speed to soften the impact. Maybe G.INP will help when/if it gets to my ECI cab.
-
That's the sort of thing that a line fault, e.g. corrosion, can do.
-
Well no the RFI would appear to be all the time wouldn't it, hence the reduced bitloading?
-
This line for instance:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FNHKvqkh.png&hash=b16dbd7574541dbc03e77ecaeb2a22b5f6b5e14c) (http://imgur.com/NHKvqkh)
It shows most of the tones available for the upstream (and the downstream) and yet only manages an upstream sync not faster than mine.
How is my line able to achieve the same sync but with only half the tones being used? It would seem to indicate that the tones that are being used are of a higher quality and so if we could get those other tones to be used also, this might increase the upstream sync?
-
I've just remembered about the time when I had a powercut and the connection came up first before the other lines, resulting in a 10Mb gain in sync. This was presumably due to all outside sources of interference being temporarily removed.
The Hlog and QLN graphs still looked the same however.
This would seem to imply that there must be another issue?
-
This pair swap thing let me see if i am correct lines have three pairs the 1st pair is the A & B connected to PCP cabinet and terminated to Master Socket A & B the second pair is A & B but not connected at PCP cabinet or Master Socket the third pair is the bellwire and earth.
What happens if the 2nd pair is worse than the original 1st pair ?
-
This pair swap thing let me see if i am correct lines have three pairs the 1st pair is the A & B connected to PCP cabinet and terminated to Master Socket A & B the second pair is A & B but not connected at PCP cabinet or Master Socket the third pair is the bellwire and earth.
What happens if the 2nd pair is worse than the original 1st pair ?
You only have ONE external pair from the Cab to your premises (unless you have a multi-line installation). The older internal wiring has THREE pairs, but they will only travel as far as the internal wiring travels. The bell-wire is not necessary on most modern phones, and the micro-filters have a ringing capacitor in-situ to ensure the older type phones ring without the need for the bell-wire.
There is no 'Earth' on any other pair of wires other than the 'feed' pair. :)
-
BS, could you explain the process of a D-side change?
If the cable is overheard like my line is, there are multiple lines in one cable so to change the whole cable would take other customers offline too?
Thanks again as always my friend :)
-
You only have ONE external pair from the Cab to your premises (unless you have a multi-:)
There was me thinking it was like a Cat5 cable with 3 pairs.
What is a pair swap when you are still using the same pairs as you did before ?
-
You only have ONE external pair from the Cab to your premises (unless you have a multi-:)
There was me thinking it was like a Cat5 cable with 3 pairs.
What is a pair swap when you are still using the same pairs as you did before ?
Underground D-side cables have a variety of sizes ...... from 1pr to 100pr. Ideally, if there is a fault identified on the UG cable it should be located and repaired if possible, however it depends on the visiting engineers skill-set as to whether this will be done. I'm not going into the why's and where-for's but it is suggested that a 'pair change' is carried out with some skill-sets. This means putting the circuit through a different pair from Exchange to Cab, or Cab to DP. Of course, the new pair has to test ok before this is done.
Of course, there is a an acceptable argument that if one pair has gone faulty, then others will as well in time. But the business has obviously done a costing exercise on this and deemed 'pair changes' to be acceptable.
So, to answer your question, you are not using the same pair as before from the Cab to the DP / Exchange to Cab. You are still using the same pair in the internal cable though.
-
So, to answer your question, you are not using the same pair as before from the Cab to the DP / Exchange to Cab. You are still using the same pair in the internal cable though.
But From the DP to premises it's still using the original pairs (Drop Wire) to your premises is that right :-\
-
But From the DP to premises it's still using the original pairs (Drop Wire) to your premises is that right :-\
Absolutely correct. :)
And testing the pair in that cable would be the easiest task.
I've attached a page, below, showing the typical specification of a two pair drop-cable.
-
So the physical cable between the cabinet and the DP is never actually changed?
-
So the physical cable between the cabinet and the DP is never actually changed?
No not the underground cable as it looks like there are plenty of cores (pairs) in the cable for pair swaps :)
-
So the physical cable between the cabinet and the DP is never actually changed?
Not unless it develops a fault 'in length'. Most cables will be approx. 100/200mtrs in length ........... therefore every 100/200mtrs there will be a cable joint. It's usually at the joint that faults will exist (corrosion etc). However, every now and again there will be faults developing in the actual cable length, via rope-burn (pulling another cable/sub-duct through the same duct), or rats having a chomp.
-
Most cables will be approx. 100/200mtrs in length ........... therefore every 100/200mtrs there will be a cable joint
Could i ask at these joints is there a manhole cover for easy access ?
-
Most cables will be approx. 100/200mtrs in length ........... therefore every 100/200mtrs there will be a cable joint
Could i ask at these joints is there a manhole cover for easy access ?
Yes, there is. :)
-
Most cables will be approx. 100/200mtrs in length ........... therefore every 100/200mtrs there will be a cable joint
Could i ask at these joints is there a manhole cover for easy access ?
Yes, there is. :)
This is great information B*CAT so an HR fault is most likely be at the joints and each join has predetermine length with access at each that's good to know and the reason why a reflected pluse will show as a HR fault in a join and the engineer knows exactly which manhole cover to inspect ;D
-
I'm talking about overheard cable though :)
-
I'm talking about overheard cable though :)
The Engineer will be with you to-morrow so ask him all these question and remember he has only a two hour slot and offer him tea or coffee and enjoy :)
-
I'm talking about overheard cable though :)
So you have an aerial D-side?
If the answer is yes, then there will still be joints at similar distances as B*Sheep has mentioned, above. The difference being that the joints will be located on the carrier poles. I like to think of the typical joint closures as a "giant's thimble". Take a look up at a few of the poles when you next have the time. I suspect you will see a couple of loops of cable that drop down from the pole top and then enter the joint closure from below. I've tried to take an image (from Google Map's Street View) to illustrate the type of joint closure -- see below.
Also attached, below, is the specification for one type of aerial distribution cable that is used.
[attachment deleted by admin]
-
Do you still have the Plink log from 14th June that you could post for comparison purposes?
Here (http://www.filedropper.com/plink20150614-0900) is the Plink log from the 14th June at 0900 :)
See the attached animated gif for your connection.
This portrays the slight changes (deterioration) in attenuation, Hlog, QLN, SNR & therefore bitloading.
The increase in attenuation COULD be temperature related & the decreased SNR COULD be a result of that.
From studying various connection stats, it appears that SNR has to be around 10dB or more per tone for bitloading etc. to take place and the US attenuation cut-off point seems to be around 65dB or so.
Your U2 Line attenuation has increased from 64.6dB to 66.7dB.
That could explain the previous 'dodgy' looking Hlog graph as it was right on the edge of being able to make use of some of the tones or not.
Now that attenuation in the U2 band has increased slightly & noise levels have increased slightly (possibly temperature related and/or increased crosstalk), none of the band is now able to be used.
Resyncing the connection at a time when SNR/SNRM are at their peak may provide a temporary improvement, but as SNR/SNRM decrease during normal daily fluctuations, this would no doubt cause an increase in errors & DLM may have already determined a 'suitable' balance between stability & speed from its constant monitoring.
If there are no physical line issues such as HR faults etc., you may either be permanently stuck with lower sync speeds or as per my connection, you may see a slight improvement during winter.
As my line's attenuation is slightly worse than yours, I can't ever use the U2 band & I see the seasonal reduced bitloading effect etc. in the D2 band.
-
TalkTalk sent a voice engineer :wall:
-
I've this afternoon received a call from a very nice man in Liverpool, one of TalkTalk's UK engineers.
A broadband engineer is being sent tomorrow and I have been asked for him to call TalkTalk - they will tell him what to do :)
-
TalkTalk sent a voice engineer :wall:
D'oh! :doh:
-
Just had G.INP enabled.
-
On upstream as well as downstream
-
On upstream as well as downstream
Is that important?
-
Interleaving depth has reduced significantly so we're now getting sub-10ms pings. That's good I suppose.
-
This engineer's tests passed and so as is becoming a pattern, he couldn't really do anything :no:
We now have an unhacked HG612 though! ;D
-
On upstream as well as downstream
Is that important?
Yes, it means your upstream will benefit from G.INP too, making your connection faster and more stable.
-
Upstream G.INP is turned off by default now though
-
Oh well mine was definitely turned on.
-
By default, downstream G.INP is on and upstream G.INP is off - this explains why you were asked about it in the thread earlier. It would be a surprise if you are G.INP enabled on both the upstream and downstream
-
54 on the downstream and 42 on the upstream :)
-
I hope that it helps with stability for you as having read through the many pages of this thread it isn't 100% conclusive that there is a fault (probably why the engineers have been of little help) and you may just have a crappy line.
I know first hand how disappointing it can be when a line doesn't live up to expectations, and hopefully the FTTP on demand prices will come down to realistic levels soon so that you can have some guaranteed performance :)
-
Well if I have a crappy line I'm sure with enough pressure OR will eventually change it all! :)
-
Was the engineer able to tell you the distance from your Master Socket to the cabinet via his/her JDSU ?
-
My JDSU says 850m.
-
By default, downstream G.INP is on and upstream G.INP is off - this explains why you were asked about it in the thread earlier. It would be a surprise if you are G.INP enabled on both the upstream and downstream
There have been recent reports of some users who had initially G.INP Mk1 applied (DS & US), then having US G.INP removed (Mk 2) & very recently having it applied to US again (Mk 3?).
I didn't realise that AlecR was still using SP10.
It seems that was finally updated (probably to SP08) to allow G.INP, but his new SP06 modem needs unlocking in order to see the stats.
I believe that G.INP can actually be active on SP06 HG12s.
If I'm not mistaken, WWWombat, for example, has G.INP active on his SP06 HG612.
-
I went live with FTTC in June, the cabinet had only been alive for a week or so. I believe I was the first line on the cabinet to be enabled.
I have never had G.INP and I don't believe the cabinet ever did either.
This morning my connection dropped and G.INP had been enabled. I could see this because my HG612 (purchased from eBay) had been hacked and was running (I am fairly sure) the B030SP08 firmware from Howlingwolf.
Looking at the INP levels on MyDSLWebStats, we can see 54.00 for the downstream and 42.00 for the upstream. So it looks like I have it on both - this is not supposed to happen is it?
The Openreach engineer today replaced that hacked modem with another HG612 ("...to make it look like I've done something...") which, from looking at the bottom, is running SP06 firmware. I believe my hacked HG612 was originally running SP10 firmware.
Do I need to do anything now? I'm going to put the Billion 8800NL (replacement) back on in a day or so anyway probably as I miss being able to see the stats :(
-
My JDSU says 850m.
You have your own JDSU?
Can we see some photos/screenshots of its stats?
Does it have the TDR function that might identify line 'faults' (& their location)?
-
My JDSU says 850m.
Your on a long line then your current stats on MDWS looks ok and a sync of 40000kbps is nothing to sniffed at.
Clould you recap on what the issue is again as your thread is quite large.
-
You have your own JDSU?
Yes, it's an ex-Openreach JDSU by the looks of it.
Can we see some photos/screenshots of its stats?
I would take some but I've already had at least four connection drops today so I'd rather not upset DLM any further today :)
Does it have the TDR function that might identify line 'faults' (& their location)?
I don't know how to access that nor how to use it :(
-
Your on a long line then your current stats on MDWS looks ok and a sync of 40000kbps is nothing to sniffed at.
It is when I know lines of this length can get 50Mb or higher (which I did).
It's the upstream that is most annoying. I was hoping for closer to 15Mb which hopefully with a pair change I might get :)
In fact I'm not sure that the line is even that long you see another engineer said it was closer to 750m which, looking at the route the line takes, would seem to support that.
-
Do I need to do anything now? I'm going to put the Billion 8800NL (replacement) back on in a day or so anyway probably as I miss being able to see the stats :(
Personally, I would have unlocked the replacement modem with Wolfy's SP08 firmware as soon as the engineer had left.
(either the 'unlocked' version - telnet access to stats but no GUI or the 'webgui' version - telnet access and GUI)
-
It's the upstream that is most annoying. I was hoping for closer to 15Mb which hopefully with a pair change I might get :)
That's going to be difficult as you would need well over half of the Upstream U2 band to be active and you only a few small tones in the U2 band active at the moment.
-
But as I've said already, the strange thing about my line is that if you look at similar length lines, the bitloading is much worse in the first upstream band.
I'm getting the same sync speed as some lines using almost one and a half bands. If I could use the second band I could easily hit 15Mb I think?
-
I wonder if there is a way for you to learn how to use your JDSU to diagnose the problem.
-
I would be careful what you wish for. Your line passes tests and it is there most unlikely you will get a pair swap. Given that your line passes tests a new pair could easily be worse. I would just get on and use the line.
You say others have similar speeds in similar circumstances but some do better. As well as noise pick up, actual speeds depend on amount of cross talk which is highly dependent on take up of FTTC down the run of your line. That will vary a lot between people and could easily account for any band utilization differences.
As for the JDSU I believe some of the key test require access to the cab and only an engineer can do them.
-
Alec, Out of the six HST-3000 User Guides that I have provided, I would recommend that you spend some time reading through --
- 201304_HST-3000_Base_Unit_Users_Guide.pdf
- 201304_HST-3000_Copper_Testing_Users_Guide.pdf
- 201105_HST-3000_VDSL_Testing_Users_Guide.pdf
With the instrument by your side for consultation of the menus, you should be able to gain sufficient knowledge to enable you to perform basic tests.
-
So we're in agreement there is no fault.
Therefore I think it is best to close it with TalkTalk?
-
So we're in agreement there is no fault.
Therefore I think it is best to close it with TalkTalk?
I would go with what your JDSU says :hmm:
-
Am I right in saying that I can pay for an SFI2 to come and change the line?
-
Is it normal to lose so much between the discovery and medley phases of pbParams?
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 9484 Kbps, Downstream rate = 42476 Kbps
Bearer: 0, Upstream rate = 9263 Kbps, Downstream rate = 41248 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) (1972,2050)
DS: (33,859) (1216,1961)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 9484 kbps 42476 kbps
Actual Aggregate Tx Power: 3.4 dBm 12.1 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 9.1 42.7 66.3 N/A N/A 18.5 51.9 89.4
Signal Attenuation(dB): 9.1 41.8 N/A N/A N/A 28.1 51.5 N/A
SNR Margin(dB): 6.4 6.5 N/A N/A N/A 6.5 6.5 N/A
TX Power(dBm): 0.2 0.3 -11.8 N/A N/A 10.0 7.9 N/A
-
Is it normal to lose so much between the discovery and medley phases of pbParams?
For some of us on longer/poorer connections, yes:-
xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 3827 Kbps, Downstream rate = 21384 Kbps
Bearer: 0, Upstream rate = 3717 Kbps, Downstream rate = 21811 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,3970)
Medley Phase (Final) Band Plan
US: (7,32) (871,1196)
DS: (33,859) (1216,1646)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 3827 kbps 21384 kbps
Actual Aggregate Tx Power: 7.0 dBm 12.5 dBm
=========================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 8.3 55.9 N/A N/A N/A 22.1 68.9 N/A
Signal Attenuation(dB): 8.3 55.2 N/A N/A N/A 31.5 68.8 N/A
SNR Margin(dB): 6.6 6.4 N/A N/A N/A 6.3 6.3 N/A
TX Power(dBm): 0.4 5.9 N/A N/A N/A 11.5 5.4 N/A
-
Just had another unexplained resync...
-
You might try bending the dsl and modem power cables about for a while to check that the resyncs are not due to a dodgy cable.
-
I'm on my third DSL cable :)
-
Just had another unexplained resync...
I think you should consider plugging in the JDSU
-
What tests should I run?
-
Since yesterday's SNRM drop to 5dB and it getting stuck there, the connection has resynced again today and the
downstream upstream sync has dropped a Mb to 8682 Kbps.
-
Thats not what i see your DS sync has increased by 525 Kbps from 41248 on the 22/7/2015 to 41773 on the 25/7/2015 and your SNRM is at 6.4dB you lost 0.2dB.
Why don't you leave MDWS to monitor 24/7 ?
-
My apologies, I meant upstream :)
-
My apologies, I meant upstream :)
I can't make any judgement you keep turning off MDWS we can't fill in the blanks.
-
TalkTalk haven't called me back and since I cannot call them I'm once again trapped in limbo :(
-
It turns out my last TalkTalk contact was hospitalised so I've got a new one.
Had a long chat with him tonight and he's sending out a new router which after some discussion we agreed was pointless - oh well.
He said he would get Openreach to do a lift and shift but the engineer would come to my house first - I thought the engineer went to the cabinet.
He said he would discuss with his colleagues, a pair change.
Progress I suppose.
-
They have to swap both ends for a pair change ;)
-
They have to swap both ends for a pair change ;)
Want I meant was, for a lift and shift the engineer only goes to the cabinet, am I right?
For a pair change a whole new pair would be allocated so yes they would have to change both ends - I understand that :)
-
Your SNRM seems to be in resonable shape you have not had any resyncs most of them are O loss of service (user turning off modem for 30 minutes) your errored seconds both up and down are showing ZERO if I was your ISP or OR engineer you would get a clean bill of health from what i see and can't see your woes sorry :-\
-
I agree that AlecR's connection looks fine. A lift and shlft and/or pair swap may be as likely to make things worse as it is to make things better.
-
And now G.INP has been completely disabled on my line - what is going on :(
-
Has your DLM been reset? That will disable G.INP
-
Lift and Shift has been done - made absolutely zero difference.
The connection has dropped three times since it was done.
-
I don't think so.
Interleaving went straight up to over 700 when G.INP was disabled. If it was a DLM reset wouldn't it sart at 1?
-
You had a lift and shift not a DLM reset :P
-
You said I had a DLM reset. I never said I did...
-
You said I had a DLM reset.
No I didn't. Did you expect that the lift and shift would turn off G.INP?
-
G.INP was removed before the lift and shift occured.
I don't want G.INP turned off - it reduced the errors and let me have low pings! :(
-
The Engineer after doing the lift and shift would have reset your line, this will remove G.INP and you may get G.INP enabled on your line after 48 hours.
-
The Engineer after doing the lift and shift would have reset your line, this will remove G.INP and you may get G.INP enabled on your line after 48 hours.
G.INP was removed before the lift and shift occured.
He didn't reset DLM when the reset occured as the line's interleaving and depth is identical to before and after the lift and shift.
-
He didn't reset DLM when the reset occured as the line's interleaving and depth is identical to before and after the lift and shift.
The Engineer can reset the DLM before they start work on your line or after they finish the work it's up to the Engineer which he/she decides.
PS you have thread already open http://forum.kitz.co.uk/index.php/topic,15524.285.html (http://forum.kitz.co.uk/index.php/topic,15524.285.html) would that not be the place to ask questions
-
If a 'Lift & Shift' is performed ............. the circuit automatically reverts to full default settings (40-2, 40-10, 80-20) as it is a brand new port, so the engineer doesn't need to do a reset.
-
If a 'Lift & Shift' is performed ............. the circuit automatically reverts to full default settings (40-2, 40-10, 80-20) as it is a brand new port, so the engineer doesn't need to do a reset.
Then you can Help AlecR and please use his thread as seen above.
-
I've spoken with Alec about this, and there's not much input I can give other than what I've already said. :)
-
I've spoken with Alec about this, and there's not much input I can give other than what I've already said. :)
Did you explain the US upstream tones and the reason why he can't get 15Mbps on the upstream ::)
-
BS, the interleaving depth is identical to what it was before G.INP was enabled and as a result sync has dropped to under 40Mb.
With no interleaving I'd be expecting a 45Mb sync so humbly I am going to suggest that DLM has not been reset?
-
if g.inp is gone, and what BS said, we can conclude DLM has been reset.
You seem to be over fussy about your line, is it really in a fault status?
-
I noticed this, this morning just as I was about to go out and didnt have time to comment. I'm a bit confused at what has happened on this line because it appears to have had some sort of reset but not. ???
If it had a full DLM reset then that line should now be running on open profile for 2 days - which it clearly isnt because it has an interleaving delay of 8.
What ever has been done today has removed g.inp but the removal of g.inp has taken his DLM profile back to what it was prior to g.inp being applied.
This isnt something that Ive seen before, the nearest I can equate it to is someone having g.inp Mk1 applied and then the EU putting on a g.inpless modem.
I dont have a clue whats going on here Im afraid. The DLM profile appears to be set similar to what was happening for those EU's with an ECI modem & Mk1 g.inp.
Perhaps it may settle in a couple of days such as those who had an ECI and switched to a HG612 if the line was banded - it took a couple of days for DLM to recognise the correct equipment in the case of lines which previously had a line rate banding.
-
I've split several posts away from the main G.INP thread and merged them over to here, so all the info about Alec's line is together.
Please play nicely.
-
Just lock the thread Kitz. It's not helping me nor anyone else at this point.
-
Ive not examined Alecs line in minute detail nor read all the posts in this thread as I missed quite a lot during the period when I wasn't around so apologies if Ive missed something important.
However, from what Ive seen, there does appear to be something strange. Remember that the DLM had to intervene at one point because irrc the line was dropping sync a few times a day. Applying G.INP appeared to mostly correct things and g.inp had the effect of masking what was going on. If this is the case then the line possibly had some noise which g.inp sorted. Once g.inp was applied I couldn't see anything obviously wrong with the line.
It is rather strange though why DLM hasn't today done a total refresh and reset everything back to zero. I am hoping that DLM will soon realise that a g.inp modem is in place and will apply the correct profile :fingers:
-
Just lock the thread Kitz. It's not helping me nor anyone else at this point.
You posted as I was making my post above.
Im keeping this open, because I would be interested to see if the DLM does realise that it should be applying g.inp.
-
Well can you lock it and then reply when something happens please.
I'm fed up with this thread now and I regret ever making it as I see I'm just being accused of doing this on purpose and I don't need this in my life right now.
This is the last time I ask for help on this forum.
-
Just relax mate, your famous ;)
-
:(
Locked as requested by OP.
I certainly would have been interested to see what happens with the DLM and how it handles the lift and shift situation.
-
Perhaps it may settle in a couple of days such as those who had an ECI and switched to a HG612 if the line was banded
../..
I am hoping that DLM will soon realise that a g.inp modem is in place and will apply the correct profile
../..
I would be interested to see if the DLM does realise that it should be applying g.inp
Looks like DLM has done so this morning :)