Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: sotonsam on April 18, 2018, 08:26:49 PM
-
A little bit of history - I'm around 200m away from my local FTTC cab (ECI - sad times) which was enabled back in 2013. I've been a subscriber since 2013, I have always been on the Infinity 2 product and at the start used to achieve at least 75mb downstream.
Obviously more and more people have come online over time and introduced crosstalk, so I've lost around 15mb over the last 2 years in particular - I'm down to around 61/62mb now. Is that a common experience for most?
My modem is plugged straight into a new MK4 master socket, no extensions, just wires a and b terminated. I now have a new HG612 modem (unlocked) so I'm able to grab my stats.
(https://image.ibb.co/en4AMn/line_stats_P_20180418_1835.png)
Thoughts on these? Anything exceptional or something showing big problems? I'm not massively experienced on reading the attenuation levels and what is good/what isn't, and if it's acceptable for me etc...
Cheers,
-
My line is pretty much the exact same electrical length more or less I have also had FTTC since it was available in 2013, and had the top speeds back in the good old days.
Your stats look good to me the only thing that's notable is the higher noise floor on the QLN graph which shows that allot of cross-talk is in play, i'm also highly effected by crosstalk as uptake is high.
I'll attach my stats so you can compare.
If ECI wasnt terrible then we'd probably get some of the lost speed back with 3db and g.inp but thats not to be....
Only thing of note other than that is 14.3db is ~320-350m line length as far as I am aware which it the tail end of G.Fast doing anything which is rather annoying.
-
A little bit of history - I'm around 200m away from my local FTTC cab (ECI - sad times) which was enabled back in 2013. I've been a subscriber since 2013, I have always been on the Infinity 2 product and at the start used to achieve at least 75mb downstream.
I would say that 14.3 dB attenuation is either somewhat more than around 200m or using cabling subject to attenuation such as aluminium and/or 0.4mm gauge copper (or maybe even 0.4mm aluminium, which is the worst of both worlds). Like with @S.Stephenson's example, your line is probably closer to 350m (in terms of attenuated distance, though it could a bit longer or shorter).
Obviously more and more people have come online over time and introduced crosstalk, so I've lost around 15mb over the last 2 years in particular - I'm down to around 61/62mb now. Is that a common experience for most?
Short answer: yes.
Long answer:
When more subscribers are added to a cabinet, it is not unusual to lose 10-15+ Mbps on the downstream (or even more if you were one of the first subscribers on a heavily subscribed cabinet). Though, it does ultimately depend on so many different factors beyond the amount of subscribers. If you were one of the first subscribers on the cabinet then 15 Mbps is not too bad but perhaps you should clarify what you mean by achieving 75 Mbps; was this as throughput (the speed seen when downloading, speedtesting, etc.) or as synchronisation speed? Since sync != throughput as there is a small overhead.
With people within 200m or so of the cabinet, it is not usual for them to see any speed loss as they are close enough for their margins to drop while still being able to retain full sync (unless there is a fault, bridge tap, a LOT of crosstalk or low gauge cabling susceptible to attenuation). Though a lot of us under 200m that have access to stats will see our "max" (or "attainable") speed drop dramatically as subscribers are added to the cabinet. If I recall correctly, the original (first) line in the property started off with an attainable of something like 100/35 Mbps (DS/US) but now it is something like 85/25 Mbps with the actual sync at max 80/20 with G.INP and maybe a target SNR of 4 or 5 dB on the downstream. Even still, that is an attainable loss of about 15 Mbps on the downstream and 10 Mbps on the upstream (and I imagine the impact on this figures would be a bit more in the absence of G.INP).
Thoughts on these? Anything exceptional or something showing big problems? I'm not massively experienced on reading the attenuation levels and what is good/what isn't, and if it's acceptable for me etc...
The stats seem OK. Nothing is showing out of the ordinary for what the line is.
I do remember that you created a topic about G.fast that I particpated in, and these stats do give us some insight into what you could expect when it is rolled out. The good news is that you should almost certainly get around or over 100 Mbps on G.fast at your distance; the estimates seem to be fairly accurate based on your stats and approximate length based on attenuation, perhaps a bit overzealous but you'll never know until it is activated. Though I cannot comment on the upstream, though it seems like the estimates would point to some loss in that respect.
Edit:
When I say good news, perhaps it's not such good news for yourself as you expected better from G.fast considering your physical distance from the cabinet.
-
my line originally (first on cabinet) was 110/36 :) and thats on a 360m line with 50m of ali. (yes I believe BS was joking about the no ali part).
attenuation as reported on modem of 15db so higher than the OP.
Its been up and down, but the attainable sync originally only stayed above 80 for a few weeks, it nosedived extremely quickly. It hit a low of under 60mbit DS, but openreach and CP recognised that as faulty and it triggered a pair swap, since last august up until a couple of weeks ago it was synced at full 80/20 and during a power fault in cabinet last august I could see attainable regularly hitting mid 90s, right now its synced at just under 74 and 20 up, attainable is about 76/27.
This huge variance in performance has largely been down to crosstalk with 'maybe' the exception of that sub 60 sync that triggered a pair swap.
-
@Chrysalis: it would be interesting to see the attenuation for the individual bands since that seems a pretty decent sync speed for the stated distance. It's possible the OP could be in a similar position as you were before when your sync dropped but OR probably won't fix it in this case because "if it ain't broke ..." and they have had virtually the same sync since sign up (so the DSL Checker probably shows estimates on par with the sync).
@sotonsam: I cannot remember if you posted anything in relation to your VDSL estimates in your other thread (and a quick scan through didn't pick up anything). Maybe you could show your clean and impacted estimates?
-
re0 compared to international vdsl testing data my speeds are nothing special. In fact the speeds I have seen on this line when its below 70 are actually poor compared to international testing data, the reason is the reported levels of crosstalk reported on openreach copper/ali has been on the high side of expected levels of crosstalk.
By the time my line dropped below 60% it has lost circa 50% of potential line speed to crosstalk, that is most definitely on the high side.
here is what you asked for
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fteam-rebellion.net%2FChris%2Fhlog.png&hash=ce3f92033f78b07c1da88daa6355d712fd9f0fa6)
However on the flipside compared to others around me I am now faring well which is another interesting story in itself.
Right now my clean low estimate is in the low 60s (20th percentile of lines on my pole?)
The handback is barely above 50 (10th percentile for lines on my pole?)
Yet my current attainable is just over 75mbit.
So on that basis i am doing well.
However before my cabinet fault last august, my clean low estimate was alot higher at close to 70mbit, and my line was not much above it. The lottery got rerolled when tie pairs had to be redone, I came out a winner, but also the losers had noticeably worse performance than the losers had before the tie pairs were done hence the estimates plunging.
That was when I also realised a big part of crosstalk is close to the cabinet even at the tie pairs themselves, I also remembered when black sheep told us when they did thermal imaging of tie pairs showing the levels of crosstalk at that point. Given a port swap involves changing tie pairs (engineers cant go in a vdsl cabinet, so to change a port they simply swap tie pairs) I now understand why port swaps can fix problems people have.
-
Thanks for everyone’s input and replies so far, appreciated.
Thanks (I think??) for the corrections on my line length :( It must go some weird route, as I can see the cab over the road from my window. Never mind.
When I first ordered FTTC it was in its infancy when you had either Opeanreach of Kelly's guys coming to your house to fit a SSFP etc. They used their testers on the socket and my line was easily getting a sync speed of 75. This was echoed by the speed tests when I was fully online - so when I said 75, that was the 'sync' profile on my line - I got about 73mb in throughput.
I think my general expectation now with G.Fast is that it will probably equal minimal improvements for me, and if as suggested below I'd actually get a hit on my upload then I probably won't bother. Upload is the key bit for me, so I was hoping I'd get a boost to that as well! Virgin Media is looking more likely by the day in my quest for speed..!
So here are my estimations based on my line, so based on that I'm probably doing ok - I'd say I'm probably as low on clean as possible. Unless my stats suggested I'm impacted?
(https://image.ibb.co/mDGq6n/acceptables.jpg)
-
@Chrysalis: I cannot say I am aware of what specifications they abide by when doing the VDSL testing (in reference to international VDSL testing, as you mentioned). Perhaps you could provide a source that you used for me to read into? Though, there will always be people below and above the bar (average) just as variation ... which is typical in every scenario. :)
On your graph, there is a bit of a dropoff at the higher frequencies, but that could be quite normal - and, for myself, since I have changed my modem I have noticed that some of the higher frequencies seem a bit more impacted compared to the previous one (though it does perform the same with virtually the same attenuation and attainable overall). But yes, compared to some in similar circumstances you are certainly receiving more.
@sotonsam: The information that we provided are not necessarily "corrections", but rather what we can make of the information you have provided. As I said in one of my posts, I implied the line is attenuated to the point where it is behaving or has the characteristics equivalent to something that is about 350m of length (from the cabinet). In reality, however, the line could be a lot shorter but impaired by a lot of crosstalk and/or a lot of aluminium with a small gauge was employed - or perhaps it is just a longer line due to routing. Only Openreach can know.
The impacted range applies to lines which have wiring issues (including Bridge Taps, etc.), while the clean range is a line free of any of the aforementioned issues. On the DSL Checker, there is some information under "Premise environment" which shows information regarding the line such as Bridge Taps and VRI. ISPReview (https://www.ispreview.co.uk/index.php/2017/07/bt-wholesale-broadband-checker-adds-options-vri-ntefaceplate.html (https://www.ispreview.co.uk/index.php/2017/07/bt-wholesale-broadband-checker-adds-options-vri-ntefaceplate.html)) has some helpful information regarding this and what the information means.
I can agree that the G.fast is showing minimal improvements, but we can't know it until it ACTUALLY becomes available and you have the service activated with your ISP of choice. But I don't think you could expect any more than the 20 Mbps you are receiving now.
As always: estimates are estimates. Yes, it seems you are at the lower end. But by any means, it seems like the speed you have lost over the period of time was because of crosstalk and you are within the estimates provided. Though one thing I would like to ask, if you know, what was the estimate/guarantee that the ISP provided you with when you signed up/regraded?
-
On your graph, there is a bit of a dropoff at the higher frequencies, but that could be quite normal . . .
I call that the "tail end droop" and it can be seen, to a greater or lesser extent, on all circuits connected to an ECI Hi-FOCuS M41 DSLAM.
-
Big thing with G.fast right now is i'm pretty sure they only have rev2 gear out in the field unless i'm mistaken.
So G.fast speeds could be more impressive at the line length you have.
Im seeing a potential ECI type situation with rev2 vs 3 Openreach isn't one for replacing inferior gear if they can help it.
The rev3 stuff should have more ports and increase the range and speeds.
-
re0 they estimated 67mbit and guarantee I think low 60s.
If I ever get a speed related fault, I will hold them to what was given to me at signup, I dont know if sky will ever try to push this handback rubbish on me, I hope I dont need to find out.
When I used to watch sky support forums on fiber pro, they honoured signup estimates.
The fault back in august was for loss of service so speed was never a part of that discussion.
I most definitely do not consider my line faulty right now tho, what I mentioned here is just providing information for others to read.
-
@sotonsam: The information that we provided are not necessarily "corrections", but rather what we can make of the information you have provided. As I said in one of my posts, I implied the line is attenuated to the point where it is behaving or has the characteristics equivalent to something that is about 350m of length (from the cabinet). In reality, however, the line could be a lot shorter but impaired by a lot of crosstalk and/or a lot of aluminium with a small gauge was employed - or perhaps it is just a longer line due to routing. Only Openreach can know.
The impacted range applies to lines which have wiring issues (including Bridge Taps, etc.), while the clean range is a line free of any of the aforementioned issues. On the DSL Checker, there is some information under "Premise environment" which shows information regarding the line such as Bridge Taps and VRI. ISPReview (https://www.ispreview.co.uk/index.php/2017/07/bt-wholesale-broadband-checker-adds-options-vri-ntefaceplate.html (https://www.ispreview.co.uk/index.php/2017/07/bt-wholesale-broadband-checker-adds-options-vri-ntefaceplate.html)) has some helpful information regarding this and what the information means.
I can agree that the G.fast is showing minimal improvements, but we can't know it until it ACTUALLY becomes available and you have the service activated with your ISP of choice. But I don't think you could expect any more than the 20 Mbps you are receiving now.
As always: estimates are estimates. Yes, it seems you are at the lower end. But by any means, it seems like the speed you have lost over the period of time was because of crosstalk and you are within the estimates provided. Though one thing I would like to ask, if you know, what was the estimate/guarantee that the ISP provided you with when you signed up/regraded?
I wish I could remember what my sign up estimations were. I've drilled through my emails and order forms from 2013 and cannot find anything. I don't think I'd have much to stand on anyway, like you say it does look as if my sync is influenced by crosstalk more than anything else. At least my stats look pretty much spot on for my line. The new modem has certainly improved my latency though, that's something I've noticed. Not sure if that's a common find with the HG modems over the ECI?
-
yeah your stats are not the best for the attenuation but I have also seen worse, the QLN is pretty high so I believe its likely to be crosstalk related which is nothing you can do about it.
We know the line is reasonably stable as you on fast path. :)
-
yeah your stats are not the best for the attenuation but I have also seen worse, the QLN is pretty high so I believe its likely to be crosstalk related which is nothing you can do about it.
We know the line is reasonably stable as you on fast path. :)
Out of interest, what shows that I'm on fast path on the stats?
My line has always been pretty stable to be honest, it maybe rsyncs without my input once every 4/5 months. This is why I'm pulled between this and VM, as VM would lose sync once or twice a week and I could be without it days at a time sometimes. At least I get an always on connection here and I guess it's sometimes a case of the grass isn't always greener! Back in the days of ADSL2+ I was with BE (amazing ISP for the techy types!) Having the ability to alter your SNR/Fast path via the control panel was epic, something I don't think is avaliable out there anymore?
One thing I've always wondered about is DLM and what forces this to kick in - i.e. if I manually restart my modem a couple of times a week, would that force it to kick in?
-
I wish I could remember what my sign up estimations were. I've drilled through my emails and order forms from 2013 and cannot find anything.
Perhaps you could find the estimates in your account?
I don't think I'd have much to stand on anyway, like you say it does look as if my sync is influenced by crosstalk more than anything else.
If it is below the estimates or minimum guarantee then you would have a leg to stand on, though they may only offer to release you from your contract (if you are in one still) without penalty. But if it is believed that significant improvements can be made or if the line is deemed to have a fault then an engineer could be sent out. But I should say that it doesn't seem there is a fault.
The new modem has certainly improved my latency though, that's something I've noticed. Not sure if that's a common find with the HG modems over the ECI?
I personally don't know if there would be any significant differences between using the ECI and the HG612 modem in reference to latency, especially without any stats from each of the two devices. Though, the differences in latency could be contributed to from your ISP routing perhaps taking a different path (because you have been given a different gateway for your PPP session)? It is not unusual for major ISPs to have multiple gateways that have varying latencies, though most are probably within a couple of milliseconds of each other.
Out of interest, what shows that I'm on fast path on the stats?
I know that if Bearer: 0 exists alone then it is in the absence of G.INP (which is to be expected on ECI), but I cannot see anything in your stats that would imply you are on fastpath (your stats are truncated, so I can't see what the delay is). Though, on FTTC, it is a bit different compared to ADSL in the sense that you can still have interleaving in the form of G.INP on Bearer 1 but the delay on the main Bearer can still be set to 0 (no delay).
Back in the days of ADSL2+ I was with BE (amazing ISP for the techy types!) Having the ability to alter your SNR/Fast path via the control panel was epic, something I don't think is avaliable out there anymore?
On FTTC, no. If I recall correctly, the closest you can get to this is with TalkTalk's LLU ADSL2+ broadband where you can register and request specific profiles and the disabling of the DLM.
One thing I've always wondered about is DLM and what forces this to kick in - i.e. if I manually restart my modem a couple of times a week, would that force it to kick in?
The DLM records data over a 24h period. From that data, it decides on whether it needs to make positive, negative or no changes at all. There is quite a bit of information relating to the DLM on the kitz site (http://www.kitz.co.uk/adsl/DLM.htm (http://www.kitz.co.uk/adsl/DLM.htm)) which outline the thresholds. To put it simply, there are defined thresholds which allow the DLM to categorise the line through the Mean Time Between Errors (MTBE) and Mean Time Between Resyncs (MTBR) that depend on the stability profile set by the ISP. Amber just signifies no changes, while green and red will allow for positive and negative changes likewise. Changes typically take place early hours in the morning (I believe somewhere around 4am usually).
To answer your hypothetical question above, restarting your modem a couple of times a week wouldn't make any difference at all since on the Speed DLM profile (as an example) the MTBR would have to drop below 4200 seconds (or 70 minutes) so you would be able to restart the modem up to around 20 times a day in theory without any impact (though I wouldn't try it). I should go on to say that there's a chance restarting a modem may not be treated the same as a link drop because of something to do with a "dying gasp" ... perhaps b*cat or some other experienced person could confirm.
-
I got the fast path status from this line
D 1 1
-
I should go on to say that there's a chance restarting a modem may not be treated the same as a link drop because of something to do with a "dying gasp" ... perhaps b*cat or some other experienced person could confirm.
The "dying gasp" concept is a quite simple process. It is not an absolute requirement but almost all modem manufacturers do follow the recommendation. When the processor senses that its power has been lost (and is essentially operating off the energy stored in the smoothing capacitors of the power supply circuitry) it stops all normal activity and sends a loss-of-power message to its upstream peer (at the highest, emergency, priority). Upstream, the DSLAM or MSAN will note the loss-of-power message and will then not increment its error counters.
The important rule is to remember to power off the modem before disconnecting the xDSL patch lead. It is worthwhile following that rule, regardless of the type of service being received.
However with the current FTTC service, making use of a G.993.2 link over a metallic pathway, the DLM process does not consider the DSLAM's non-incrementing error counters when deciding whether to intervene and what action to take! :doh:
-
I got the fast path status from this line
D 1 1
D'oh. :doh: I blame the alcohol content for missing that. :drunk: :P Back to the apple juice this morning, so accuracy and quality posting should ensue.
However with the current FTTC service, making use of a G.993.2 link over a metallic pathway, the DLM process does not consider the DSLAM's non-incrementing error counters when deciding whether to intervene and what action to take! :doh:
Just so I understand, rather than it being a stupid question with a blatant answer, does the DLM essentially discard the "non-incrementing" error counters?
-
Thanks for everyones input on this, I've learnt a lot!
I'll see how things pan out over the coming months in terms of G.Fast, as I said if the increase is likley to be minimal (or non-existant on upstream) then it certainly won't be worth paying the extra $$ it will cost.
If only I could wake up one day to see them building a new cab just over the road from me...(which would still probably take a tour of southampton before landing at my house!)
-
Just so I understand, rather than it being a stupid question with a blatant answer, does the DLM essentially discard the "non-incrementing" error counters?
My understanding, based on Kitz' analysis of the DLM mode of action, is that it (the DLM process) only takes notice of a small subset of the parameters which a DSLAM/MSAN will collect for each (end-user) circuit.
The actual mode of operation of the DLM process (for GEA G.993.2 based services) has not been publicly disclosed.
-
I'll see how things pan out over the coming months in terms of G.Fast, as I said if the increase is likley to be minimal (or non-existant on upstream) then it certainly won't be worth paying the extra $$ it will cost.
BT, for example, offers a lower tier 152 Mbps package with a 100 Mbps download speed guarantee. I am not aware of the complete terms surrounding this and sadly I am not aware of any gaurantee on the upstream. But perhaps it is worth a punt when it becomes available and if it does reveal any inadequacies with your line then perhaps they will "fix" it.
If only I could wake up one day to see them building a new cab just over the road from me...(which would still probably take a tour of southampton before landing at my house!)
Why wish for a new cabinet over the road when you could wish for FTTP? ;)
My understanding, based on Kitz' analysis of the DLM mode of action, is that it (the DLM process) only takes notice of a small subset of the parameters which a DSLAM/MSAN will collect for each (end-user) circuit.
The actual mode of operation of the DLM process (for GEA G.993.2 based services) has not been publicly disclosed.
Well, I was always under the impression that a lot of information on the web in relation to the DLM was based on the little documentation and "experimenting" done by "hobbyists". As per usual, information floating on the web is simply either just guidelines based on what we know (which could be outdated since revisions to underlying systems could have been made without publicly available documentation) or assumptions.
-
Both Ultrafast packages are available to me therefore I can see the small print!
Ultrafast is the only UK broadband with a 100Mb speed guarantee
Our speed guarantee is our promise that you’ll always get the download speeds you pay for – even at peak times. Ultrafast is also the only UK broadband to give you an upload speed guarantee of 10Mb.
Claim £20 if your broadband’s less than Ultrafast
We want you to feel confident Ultrafast won’t let you down, so we’ll put our money where our mouth is. You can test the speed to your hub in My BT. And claim £20 if it’s slower than it should be (you can make a claim up to four times a year).
-
BT, for example, offers a lower tier 152 Mbps package with a 100 Mbps download speed guarantee. I am not aware of the complete terms surrounding this and sadly I am not aware of any gaurantee on the upstream. But perhaps it is worth a punt when it becomes available and if it does reveal any inadequacies with your line then perhaps they will "fix" it.
Why wish for a new cabinet over the road when you could wish for FTTP? ;)
Well, I was always under the impression that a lot of information on the web in relation to the DLM was based on the little documentation and "experimenting" done by "hobbyists". As per usual, information floating on the web is simply either just guidelines based on what we know (which could be outdated since revisions to underlying systems could have been made without publicly available documentation) or assumptions.
I could wish for FTTP....but I can't imagine there's any chance of that here - well not within the next 5/6 years anyway. I was watching a Video the other day, a bloke was getting quite irate at how 'cheap' it could be for BTO to string fibre cables along the same route as your phone line (over the poles etc) rather than messing around with G.fast. Not sure BT would agree with that, but apparently lots of other European companies deploy FTTP in that way.
-
My FTTC resynced in the middle of the night last night, and I'm guessing I'm now being impact by DLM for some reason as my latency has shot up by 15ms. I must be honest, this is the highest latency I've ever had on FTTC - it's +20ms now, which is pretty naff for certain things I do.
I note from an above comment that D 1 1 demonstrated that I was on fast path. The new stats now show
D 1165 1 - what does that mean??
(https://image.ibb.co/g0qb3c/profile_20180423_2010.jpg)
-
It looks like it has applied interleaving with a depth of 1165 on the downstream. Though, upstream is still fastpath. The increase in latency would be caused by the increase in the delay on the line. But it looks like your downstream has decreased a bit with the increase in interleaving depth.
Perhaps if you have PuTTY or telnet installed on your OS, you could login into the router and then do (without the speech marks):
"sh" (to get into the shell mode)
"adsl info --stats" (to retrieve all stats)
And then, below Bitswap statistics, you should see the error counters total time, latest 15 minutes, etc. Maybe you could copy and paste that here? Furthermore, could you also copy the information for "Bearer 0" which should be just above the Bitswap as this will show delay parameters.
With the error counters, we should be able to hopefully see what the DLM (roughly) classifies your line as (information can be found out regarding the DLM at http://www.kitz.co.uk/adsl/DLM.htm (http://www.kitz.co.uk/adsl/DLM.htm)). This should give some insight to why the DLM has actioned changes.
Alternatively, if you do not want to login to the router and go through the steps, as you have HG612_Modem_Stats you could run the HG612_current_stats.exe and get the counters from a little bit down from the top of the Plink_*.log file under the Current_Stats_(date and time) folder.
-
Cheers re0 - attached is that said file.
Rather foolishly I did another reboot of the HG612 and it's degraded even further - now on an IP Profile of 57.
-
Cheers re0 - attached is that said file.
I only needed the following stats copied from the file:
Bearer 0
INP: 3.00 0.00
INPRein: 0.00 0.00
delay: 8 0
PER: 1.80 6.15
OR: 106.55 202.87
AgR: 59101.13 20203.27
and
Total time = 2 min 41 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 26 26
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 2 min 41 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 26 26
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 2 min 41 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 26 26
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 2 min 15 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Though, no biggy that you've included the whole log.
Rather foolishly I did another reboot of the HG612 and it's degraded even further - now on an IP Profile of 57.
That would explain why the counters only go back just under 3 minutes. ::) I can't make much of it until we have more information over the space of a few days to a week at least. :( I would recommend logging your line statistics over the next few days using HG612 Modem Stats (or DSLstats, if you would prefer... both are just as good as each other). Though, the downside is that you would need a machine connected and switched on without powersaving for the duration.
I can confirm that the delay has gone up by only 8 ms at link level from the cabinet; to the cabinet is still fastpath as mentioned (so no delay). If you have had an increase of 15+ ms, then some of it may be contributed by using different servers for testing latency and/or when you established PPP session (after you resynched) your ISP may have routed you differently.
-
Sorry about that!
I'll hook a laptop up by the socket and leave it running - would 72 hrs be enough to work from?
-
I should note that using HG612 Modem Stats in this occasion is not strictly necessary as we could use the stats logged on the modem. Though, it may serve us better to log using the program in case the modem is powered off (as stats on the modem are not retained after that). Plus, it is probably easier to overlook the stats in this program.
I'll hook a laptop up by the socket and leave it running - would 72 hrs be enough to work from?
It should be enough as we are not necessarily looking for a fault or inconsistency here, but rather just the general error counters in an attempt to classify the line based on the information available. Perhaps you could update the topic here after a day with the counters up until that point?
-
Attached are the four "snapshot" plots, created from that dataset (dated 2018.04.23 20:41:26).
-
Actually, come to think about it I do still have the stats from when it resyn'd (so before a reboot).
This might give a bit more to go on?
Bearer 0
INP: 3.00 0.00
INPRein: 0.00 0.00
delay: 8 0
PER: 1.78 6.15
OR: 107.53 202.87
AgR: 59645.01 20203.27
and...
Total time = 1 days 2 hours 26 min 49 sec
FEC: 6943 76
CRC: 0 5
ES: 7425 565
SES: 146 3
UAS: 62 52
LOS: 1 0
LOF: 8 0
LOM: 0 0
Latest 15 minutes time = 11 min 49 sec
FEC: 77 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 14 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 2 hours 26 min 49 sec
FEC: 627 11
CRC: 0 1
ES: 0 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 6316 65
CRC: 0 4
ES: 58 10
SES: 10 0
UAS: 36 26
LOS: 1 0
LOF: 8 0
LOM: 0 0
Since Link time = 16 hours 25 min 29 sec
FEC: 6943 76
CRC: 0 5
ES: 0 5
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
-
Bit of an update. I left a laptop running stats overnight but it crashed!! Typically my modem resync'd again last night, but as it had crashed I had no captured stats. arrgh.
I'm down to a 56.89mb line profile now! That seems way too low for a line with 14.1 attenuation in my opinion.
For what it's worth, I've dug out my original BT order and I was given an acceptable range of 63-80mb for my line (my guaranteed minimum was 57). So I'm now going down the route of BT Support, because I might as well have Infinity 1 with that line profile! To be fair, it's been degrading for a good while now...(hence why I came on here looking for ideas!)
I must admit, the HG612 modem seems to have made things a hell of a lot worse though. I did put the ECI back on, but it's made no difference.
-
Total time = 1 days 2 hours 26 min 49 sec
FEC: 6943 76
CRC: 0 5
ES: 7425 565
SES: 146 3
UAS: 62 52
LOS: 1 0
LOF: 8 0
LOM: 0 0
This may be most concerning, and would probably initiate some DLM changes considering that the space of time that this would have to occur in was small since the previous 24 hours were as follows:
ES: 58 10
SES: 10 0
Though, there is a concern for me in reference to the modem and the accuracy of the stats since I do not see CRCs logged (which are the cause of ES). And adding the latest 1 day and previous 1 day counters together shows mostly everything matches up bar ES rates. Maybe I'm missing something.
Anyway, the following information is based on the modem stats being accurate:
Please bear in mind that it is based on assumption, since there may be inaccuracies in the stats as mentioned.
There may have been a chance that the high ES/SES rates may have coincided with thunderstorms (which, for some, can cause an increase in errors and outages due to bursts of interference). From the stats we have (which does not take into account stats we don't have if the modem was rebooted/affected before that), going on the assumption it was occuring for around 2.5 hours it implies an error rate of approx. 41 ES/min and 0.3 SES/min on the downstream, and 3.1 ES/min on the upstream (no point calculating the upstream SES; it's miniscule).
Going based on the above, your MTBE (Mean Time Between Errors) over that period of time would have been approx. 1.45 (so an error every 1.45 seconds) which, I should note, is a lot lower than the MTBE red threshold (which is 30 for the Speed DLM profile, which I believe BT employ). So, it would not be unusual for the DLM to make negative changes in this scenario. It looks like the stats have been OK since, so it should recover if the line remains stable.
You can read about the DLM and tresholds at http://www.kitz.co.uk/adsl/DLM.htm (http://www.kitz.co.uk/adsl/DLM.htm).
Bit of an update. I left a laptop running stats overnight but it crashed!! Typically my modem resync'd again last night, but as it had crashed I had no captured stats. arrgh.
$#%! happens. :no:
I'm down to a 56.89mb line profile now! That seems way too low for a line with 14.1 attenuation in my opinion.
Line profile or sync speed? Just to be clear. Yes, perhaps it's a bit on the lower side for 14.1 dB attenuation but taking into account crosstalk and the fact you have ECI cabinet without support for G.INP and XdB (lower SNR, as low as 3 dB) then it is sorta expected to not be any greater.
For what it's worth, I've dug out my original BT order and I was given an acceptable range of 63-80mb for my line (my guaranteed minimum was 57). So I'm now going down the route of BT Support, because I might as well have Infinity 1 with that line profile! To be fair, it's been degrading for a good while now...(hence why I came on here looking for ideas!)
Yes, I would say that with it being below that threshold you could try and go down that route. Though, I would imagine there is not much they can do. They may choose to release you from contract (if you are still in one). Though, from what I can gather, the minimum guarantee applies to sync speed and not line profile (or throughput).
I must admit, the HG612 modem seems to have made things a hell of a lot worse though. I did put the ECI back on, but it's made no difference.
HG612 modem has made things worse? Perhaps you haven't given it enough of a chance? ;) Perhaps the line conditions have been worse in the previous few days and have tainted your opinion of the modem? :D
Either way, suddenly switching the out for the ECI will not see any immediate changes anyway, since the DLM will first need to adjust the parameters through prolonged stability.
-
Cheers for all your input in this re0, making sense of logs that don't make sense to me!
I did try to speak to BT, but you were right, they wouldn't do anything. Apparently my 'minimum' guarantee is actually 56.0Mb. But as my speed results came back as 56.89 then there was no 'issue'.
For what it's worth, since then the HG612 modem resynced again and dropped me down to a 52.10 mb line profile (only get about 48mb throughput now, and my attainable is now 56Mbps). I've ditched that and gone straight back to the ECI, something a bit dodgy with that modem I think if it's resyncing randomly like that. Before I put that on I was getting 65mb, so I've lost a good 15mb in a few days! Thought it may give me a bit of a boost, but it’s done the opposite!
Will leave this a few days and hopefully see DLM improve it, slowly....or are we looking at months and months until it improves things?
-
I did try to speak to BT, but you were right, they wouldn't do anything. Apparently my 'minimum' guarantee is actually 56.0Mb. But as my speed results came back as 56.89 then there was no 'issue'.
Looks like the minimum guarantee is based on the handback threshold for the line (which is set at 56 Mbps). Though, if you signed up and the minimum guarantee was 57 Mbps then they should honour it if you did not regrade/renew contract since the estimates were provided.
For what it's worth, since then the HG612 modem resynced again and dropped me down to a 52.10 mb line profile (only get about 48mb throughput now, and my attainable is now 56Mbps). I've ditched that and gone straight back to the ECI, something a bit dodgy with that modem I think if it's resyncing randomly like that. Before I put that on I was getting 65mb, so I've lost a good 15mb in a few days! Thought it may give me a bit of a boost, but it’s done the opposite!
There was not much you could gain from using the HG612 in terms of speed. It may have been a bit more stable on your line (though, it looks like it is the complete opposite at the moment).
Is the modem actually resynchronising or is it actually rebooting itself? Since if it is doing the latter, perhaps it is a dodgy PSU or hardware.
Will leave this a few days and hopefully see DLM improve it, slowly....or are we looking at months and months until it improves things?
As long as the line errors statisfy the thresholds, it should take a few days before improvement. It depends on whether your line has history of instability. Recovering from unusual, high error rates over short term should be fine, but if it was prolonged the DLM may be more stubborn. But not a lot is known about exactly how long it will take since not a lot of information regarding the DLM's internal processes is public.
Perhaps you could provide the last stats from the modem that you got before you switched it out?
-
As a way of an update, I ended up getting BT to pick this up as a fault as I feel below my minimum. Had one of their contractor 'CubeGB' engineers out today who rulled out anything in my house, unfortuntley he can't do anymore so it's gone back to Openreach as an esclation. When esclating it, they ran more tests over the phone and a fault was detected on the fibre side of the circuit - at the FTTC DSLAM. (maybe my port?)
So hopefully, after all these months of accepting poor speeds for a line of my quality, I may be getting somewhere... (as an asside, my attenuation has since dropped from 14.2 to 13.8, and that was just from using a twisted RJ11/RJ45 cable from the master socket and using an MK4)
I've been given a 48hr turn around, so I assume the next stage will be a port swap on the DSLAM and a subsequant DLM reset?
-
To me, it seems like it could be something to do with the DSLAM port. I do not have a lot of experience in reference to DSLAM hardware, but I am glad to see it was escalted because nothing seemed too out of place from my perspective.
The difference reported in the attenuation is insignificant, and may be partially down to different tones being allocated at different (lower, less attenuated) frequencies.
After any fault clearance, it is normal to reset the DLM. Though I am not sure of what work they will carry out. Perhaps you can find out what work they carried out after it's been done. :)
Keep us posted!
-
Yeah, it's a minimal change in attenuation, but at least it's going the right way :)
To keep BT happy, I'm having to use my HH5 as my modem atm, they kept bitching at me when I said I just had the Openreach modem. Doesn't seem too bad really, I've got a bit of a double-NAT going on as it sits in front of PfSense, but I can do everything I need.
I believe I was the first, or at least 1 of the very first two or 3 that had FTTC enabled here - I ordered on the day the cab was made live back in 2013, and had it installed a few weeks later. So by being first/second, there's every chance that I'm being penalised by crosstalk more than anyone else....(i.e. I'd have seen the biggest drop since the start)
Anyone who is knowledgeable on the port side of things, when they change your port…do they usually stick you in a less populated area which is less susceptible to crosstalk interference? (until more come online that is).
-
Anyone who is knowledgeable on the port side of things, when they change your port…do they usually stick you in a less populated area which is less susceptible to crosstalk interference? (until more come online that is).
No, nothing like that. The next free port will be allocated to your circuit. The person assigned to the task will have no say in the matter.
The physical change-over will take place at the PCP by swapping from the tie-pairs of the existing port to the tie-pairs associated with the newly allocated port. Basically: Open the cabinet; identify your circuit; snip, snip, snip & snip; take the tails of the tie-pair to the newly allocated port and crimp, crimp, crimp & crimp; done.
-
This is turning into a bit of a saga!
So, BT turned up at my property again today - luckily someone was in, as they didn't say they'd be turning up! I've not been here myself, so I'm just relaying what was told...
Basically, they had to go up on the pole over the road and they've apparently run a new cable between the pole and the PCP, as this is where the fault was. I was told that they spent all day going back and forth between the PCP and the chambers along the path…so assuming that is indeed what they’ve done. Anyone heard that being done before on a broadband sync fault? Bear in mind there has been no noise on my line.
But to cut a long story short, nothing has changed apart from my attenuation increasing and SNR increaing(I was 13.8, now I’m 14.9. SNR was 6, now 6.8). My sync speed is still a bit low for me at around 58 attainable, so only 55 throughput. I'm back on fast path though as my latency has improved...
Will my sync speed increase now over time? Otherwise I'm going to be ditching them I think and heading to Virgin. BT confirmed to me the other day that my customer point of sale figure as a bare minimum is 63 and not 58 as they initially had me believe.
-
BT should have informed you when Openreach would turn up, or at least whether it would be AM or PM. Unless they didn't need to work at the property (which seems the case here, though I cannot say why they came to the property; probably just to let you know).
Rather than running a new cable, they'd rather use an existing pair (if one is free) since it is less work. I imagine that your D-side was probably out of spec when tested (could have been something like the resistence being out of defined thresholds) and perhaps no pairs were free that were also in spec when tested so they just laid new cable. This would be done in virtually any case of there being a fault, regardless of what the fault is described as if they can measure a problem with the pair with no free pairs avaialble.
The attenuation increase may be down to quite a few more higher frequencies being used (and therefore the average attenuation is higher). The SNR should suggest that there is some more headroom over just the target 6 dB, but it can't be banding as they SHOULD have reset the DLM after the fault clearance. But I cannot tell just based on that information. It would certainly be a great help if you could post the stats graphs as you did before in your opening post so we can see if there are any noticeable differences.
-
BT should have informed you when Openreach would turn up, or at least whether it would be AM or PM. Unless they didn't need to work at the property (which seems the case here, though I cannot say why they came to the property; probably just to let you know).
Rather than running a new cable, they'd rather use an existing pair (if one is free) since it is less work. I imagine that your D-side was probably out of spec when tested (could have been something like the resistence being out of defined thresholds) and perhaps no pairs were free that were also in spec when tested so they just laid new cable. This would be done in virtually any case of there being a fault, regardless of what the fault is described as if they can measure a problem with the pair with no free pairs avaialble.
The attenuation increase may be down to quite a few more higher frequencies being used (and therefore the average attenuation is higher). The SNR should suggest that there is some more headroom over just the target 6 dB, but it can't be banding as they SHOULD have reset the DLM after the fault clearance. But I cannot tell just based on that information. It would certainly be a great help if you could post the stats graphs as you did before in your opening post so we can see if there are any noticeable differences.
There's re0. They did actually come into my property and leave their 'testers' running, so I should have been given a bit of warning at least! I've not got the HG612 running at the moment, just the Smart Hub as BT insisted I ran this or they wouldn't raise a fault - I'm a bit nervous to pull it out and put the HG612 in place atm, in case DLM is actually trying to do it's thing.
The best stats I can give you atm are - (interstingly my attenuation has dropped back down to 14)
Data rate:
20.00 kbps / 57.91 kbps
Maximum data rate:
20000 / 58914
Noise margin:
6.8 / 6.3
Line attenuation:
14
Signal attenuation:
VPI / VCI:
0/38
Modulation:
G_993_2_ANNEX_B
Latency type:
Fast Path
-
No banding present then it seems, but I would suggest running an unlocked modem (such as the HG612 you have) to get graphed stats so we can look over them. It should not impact the DLM as long as you do not exceed the MTBR thresholds defined by the stability profile, but I can certainly understand your concern.
-
No banding present then it seems, but I would suggest running an unlocked modem (such as the HG612 you have) to get graphed stats so we can look over them. It should not impact the DLM as long as you do not exceed the MTBR thresholds defined by the stability profile, but I can certainly understand your concern.
What's the 'sign' to look for if it's a banded profile?
Also, I've just got back onto BT and they're re-esclating it for me! Surprising.....thought they'd grunt and not bother! As this is still a running fault....I may chance my luck and throw my HG612 back on...
-
The usual characteristics for a banded line are:
- Surplus SNRM
- Syncing no higher than a certain rate (so you would either sync at or below that rate every time depending on conditions)
Though I cannot comment on what data rates would be typical for a banded line since I never had it applied before and do not know how the DLM bands on FTTC. Someone else here may be able to share their knowledge of banding.
Good to see progress and that they're re-escalating it. Keep us posted.
-
Still not heard anything back from BT, but I have put my HG612 back on my line now as I want to see the stats. I've got it accessible over the WAN port via some pfsense NATing, so I don't need to pop a laptop next to it anymore - will just leave a VM collecting the stats.
Just as a quick snapshot, this is how we look at the moment:
(https://image.ibb.co/dYGdeS/line_stats_L_20180501_1627.png)
Why is my Upstream SNR so high....?
-
I wouldn't consider an SNR of 9 dB so high, but if you want I could probably find a dodgy filter on that could get it down (and maybe even reduce the sync speed). ;) You're already sync'd at the full 20 Mbps upstream, so there will be spare margin (which is a good thing). I have 15 dB on the upstream, because I sync at full 20 Mbps with an attainable of around 27 Mbps.
Any improvements at all? Not really, though it seems that the line is quieter in some places but band D3 has taken a bit of a hit (may explain why your DS sync is a bit lower than previously). But in reality, the stats tell me that, even with the changes they have made, it is much the same. Everything is within margins to prior.
Anyway, the line is not banded. So you can discard what I said previously.
Hopefully BT will update you as soon as possible. But I cannot see you getting more speed than currently unless they find something else at fault and resolve it. :no:
-
Cheers for the insight. Will keep it running though and see if i can catch anything further over the coming days (may give some more to go on).
I'll keep bugging BT...as my point of sale range was 63-80......
-
Can I ask where BT get their 'minimum' speed guarantee from? I've now been told my minimum guarantee is 55-56Mb, and as I'm within that I'm fine. Yet these are my estimates on the DSL checker:
(https://image.ibb.co/eFBmG7/dslchecker.jpg) -
to me, that suggests my minimum I should accept is 63.4? (This is also the estimated range I get via ISP websites). They seem to be going by the low impacted range...which isn't what I signed up for!
-
ISPs provide you with a speed range, which is their estimated range. These figures are based on the BT's DSL Checker's estimates, although they may be slightly different depending on whether an ISP wishes to be conservative on the estimates or not (so some may have a lower range than others).
A minimum guarantee, however, is usually based on the Downstream Handback Threshold (which in your case, as you can see, is 56 Mbps) and not the range itself. If the line speed falls below the threshold then it is determined to be underperforming. Openreach will investigate if prompted by the ISP after all the usual tests are done, and if no improvements can be made then the ISP will generally allow you to exit contract without a fee.
Just to note, I think the BT website, when ordering broadband, shows estimates and guarantees based on address rather than telephone number. So there may be a slight discrepancy there. Either way, you're above the guarantee and below the estimates... but you're also out of contract, so you could just leave if you were not satisfied but you wouldn't get any faster on another ISP and you should probably wait until this "fault" has been investigated fully if you wanted to leave.
Of course, it goes deeper than this, but this is slightly more in layman's terms.
-
Cheers, understand that now. I'm not actually out of contract, my BT contract is up next April...so another year yet!
If you're interested, I've come across a great app called DSLStats, which I've published as a web server here - http://dslstats.ddns.net:55555/combined.html
Looks relatively stable in the short term...
-
Cheers, understand that now. I'm not actually out of contract, my BT contract is up next April...so another year yet!
Did you renew your contract? You said in your OP that you have been a subscriber since 2013. Perhaps you negotiated lower prices? :) As you said:
I've been a subscriber since 2013, I have always been on the Infinity 2 product and at the start used to achieve at least 75mb downstream.
Either way, doesn't matter - I apologise for my error (perhaps I had made an assumption :no:). Hopefully they'll get back to you soon.
If you're interested, I've come across a great app called DSLStats ...
I did mention this program just over a week ago:
... I would recommend logging your line statistics over the next few days using HG612 Modem Stats (or DSLstats, if you would prefer... both are just as good as each other) ...
:P
Edit:
You might want to adjust the parameters in DSLstats to show the full extent of the bitloading graph. You should be able to click on "Change tone range" and select VDSL2. You may want to adjust it manually so it fits the graph better.
-
Sorry, yeah I have had Infinity since 2013 but have renewed my contract over that time. To be fair, this period between now and Feb is the first time I've dropped below 65, I've been pretty content with it in the most part.
Yeah, great call on this app. I like it alot...have adjusted the bits so it's VDSL2 range now.
I have actually got some luck from BT, they've agreed to honour my range - 63-80, so are sending out another engineer on Thursday.
-
I have actually got some luck from BT, they've agreed to honour my range - 63-80, so are sending out another engineer on Thursday.
:dance:
Fingers crossed there is something they can do to get you over into that range. :fingers:
I can't remember if you mentioned something about which exchange and cabinet you are on, but maybe you can confirm whether your cabinet has more than one fibre cabinet (for the reason of increasing capacity)? Since the newer one - if one exists - could be Huawei, and they could switch you to it. Though it is fairly uncommon to see additional fibre cabinets (especially considering newer Huawei models that were rolled out as part of BDUK support extensions, unless the area has a high amount of subscribers that surpasses what a cabinet and extension can provide).
-
Nah, unfortunately not. There's only ever been the one ECI cab next to my PCP.
I'd say 90% of cabs in Southampton are ECI :(
Although anything new that goes up now is indeed Huawei. Am I right in assuming BTO don't actually use ECI for new deployments anymore?
-
As far as I was concerned, ECI had not been used in FTTC deployments since around the start of 2014. https://kitz.co.uk/adsl/fttc-cabinets.htm (https://kitz.co.uk/adsl/fttc-cabinets.htm) pretty much proves me wrong. Huawei cabinets did exist prior to the 2014, but as I can quote from the aforesaid link:
What model is installed is down to BT's planning dept and anticipated demand in your area. The earliest cabs were Huawei's. During the 2012-2013 period BT seemed to be favouring the ECI cabs, but since late 2013/early 2014 most new cabs tend to be Huawei.
Edited to correct information.
-
As far as I am concerned, ECI has not been used in FTTC deployments since around the start of 2014. https://kitz.co.uk/adsl/fttc-cabinets.htm (https://kitz.co.uk/adsl/fttc-cabinets.htm) pretty much says the same thing. Huawei cabinets did exist prior to the 2014, but as I can quote from the aforesaid link:
ECI's were deployed by Openreach right up till August 2016.
They had switched to using mainly Huawei cabinets on new sites some time before that. Most BDUK work was entirely Huawei. There was still ECI's being deployed on new commercial sites as late as 2015.
There are ECI activations as late as September 2015 on my exchange, though the cabinets may have been sited a while before going live.
At some point it went exclusively Huawei for new sites, but for any existing ECI cabinet that was full Openreach added a 2nd ECI cabinet.
They stopped deploying ECI cabinets completely around August/September 2016.
That's just before we first spotted an ECI being added to with a Huawei cabinet for the 1st time in this thread (https://forum.kitz.co.uk/index.php/topic,18678.0.html). A month later my own ECI got a Huawei big brother.
I haven't seen an ECI FTTC DSLAM being deployed anywhere since then.
-
j0hn, thanks for pointing out my quote. I noticed that I had phrased it wrong so I re-worded to correct it.
-
Connection has been stable for the last 19 or so hrs, although DLM hasn't increased my sync speed so I'm still below the 63.
These error stats over a 19hr period are nothing to worry about are they? Seems relatively low to my untrained eye.
FEC: 0 26
CRC: 83 2
ES: 64 2
SES: 0 0
UAS: 26 26
-
I don't think there's anything DLM will do that will increase your sync speed - you're on fastpath and your DS SNRM is just over 6dB so I think that's as good as it can get. The only thing you could do is monitor your DS SNRM and see when it's at its highest...and resync the modem at that time of day (yours may not vary much, but mine can vary by as much as 2dB over the course of 24 hours in a predictable cycle).
As for the ES, 64 is in the green over 19 hours...although as you're on fastpath already and not banded that's not going to benefit you. Based on my OCD stats collection, and correlating with when DLM temporarily kicks me onto high interleaving, BT use standard (rather than speed) profile so as long as you stay below 1440 ES per day you're fine.
-
Yeah, I must admit I'm not putting in much hope of DLM giving me much of a kick. At least BT are still trying to help and live by their 63-80 range they say they want to get me back to.
My SNRM on the downstream is pretty static, but the highest recordings I've noted were around 10pm last night for no more than 1 min. D1 jumped to 8, D2 9.3 and D3 11.2. I guess those short-jumps can simply be a case of another customer or two unplugging their modem for a few mins!
-
@sotonsam, it looks like you've resized the DSLstats window! ;D
Anyway, the error counters are looking pretty good. The MTBE (Mean Time Between Errors) is currently at about 1000. While you're above the green threshold (which would allow for the DLM to make improvements), your line is already running at max speed with no interleaving (fastpath) so there is no overhead to lose from what I can see. :no: This is about as fast as you can go, give or take maybe up to 5% depending on the time of day. As @GaryW said, you could find the best time to resync by looking at the SNR stats where the margin is highest to get the highest speeds. But I would be tempted to just leave it at the moment until the Openreach engineer has been on Thursday.
... BT use standard (rather than speed) profile so as long as you stay below 1440 ES per day you're fine.
I thought BT used speed profile?
-
I thought BT used speed profile?
That was always the assumption, but every time my ES for the day goes over 1440 (but well below 2880) I get DLM intervening. When I raised this on the forum other people did comment that their experience also seems to suggest it's standard profile. The last 3 times DLM intervened my ES totals for the day were: 1740, 1855, 1539.
If I didn't need to have my phone service with BT for a Redcare alarm system I'd be tempted to switch to another provider that's definitely on speed profile (assuming that was a definite definite!)
-
If that is the case, then perhaps @kitz could review and update https://kitz.co.uk/adsl/DLM.htm (https://kitz.co.uk/adsl/DLM.htm)? :)
I think that it's not only MTBE/R that is a factor in whether the DLM takes action, but rather bursts of errors in a short period of time and other issues (so even if the threshold is not breached). I could be wrong as it's somewhat a speculation since I do not know and have not looked into it, but there is only so much information published. I can't disagree with you though as perhaps BT does use the standard profile and you have figures that would seem to back up that statement.
-
Most BT lines are provisioned on the Speed profile.
It's known that some lines are provisioned on the Standard profile, but the reasons for this are unclear.
It was originally speculated that it might be those with BT TV that were on the Standard profile. I'm not so sure that's the case though.
I have BT TV and I'm definitely on the Speed profile.
I had 11 weeks without G.INP with the line jumping back and forth between fastpath/interleaving. DLM was only ever triggered if I broke the Speed profile limit (2880).
I'm pretty sure the MyDSLWebStats traffic lights had a note about some BT lines using the Standard profile, but that will be gone now.
Do you have any TV services from BT Gary?
-
Do you have any TV services from BT Gary?
No BT TV, and never had it. However, I used to be on Unlimited Faster Broadband which has now been dropped so I'm nominally on Infinity 1. However, I wonder if UFB was standard profile and as there was no DLM reset when I "moved" to Infinity 1 maybe it's persisted. And/or maybe it's a long-line thing generally for "stability"?
Of course, the odds of having any sort of sensible conversation with BT about it is probably zero! Getting a DLM reset is impossible, getting them to change the profile is also probably impossible...
-
So, engineer has been and gone. Tried his hardest to raise my sync speed to be fair to him, and managed to get it up by 1mb....so I've at least gained a bit I guess! He did actually tell me I was the ‘first’ port to be activated on the DSLAM back in 2013, so he said I’d have experienced the biggest cross-talk drop to anyone else.
Here are my on-going stats (you can see when he was doing his work)
http://dslstats.ddns.net:55555/connection.htm
After having some chats about AAISP the other day, I'm seriously considering getting a 2nd line from these guys (broadband only) and load balancing my FTTC connections with Pfsense - which would probably give me around 120mb and 30ish up.
Won't be cheap, but I don’t have any pay tv anymore so I have a bit in the budget…and my connections combined will still be cheaper than Virgin Media's ''full house bundle'' at the £120 p/m my mate is paying.
-
I'm not sure AA is that expensive, Zen used to be pretty expensive years ago and then their prices came down. What do you think? Is BT Retail expensive?
Btw, AA still has the units tariff, I think. This is where you pay for what you use, and there are no limits, but it’s cheaper to pre-purchase download amounts than to just go ahead and go mad. If you are a light user, or do downloading overnight (which I do) then that might be worth a look. The units tariff is a secret though. That’s what I am on. It’s £3.90 to download 1TB between 0200 and 0559 BST if you are on that deal, but very expensive per MB in the daytime weekdays. I have no idea whether it would be of any use to you. Uploads are free. See https://www.aaisp.net.uk/broadband-units.html
-
Well, an order has gone in with AAISP for a New Copper Pair and FTTC provide. I'll have this installed in a different place than the current master socket, which will be a much shorter run than my current line.
It'll be interesting to see if I get a better performance from them as opposed to BT Infinity. (obviously the local loop and copper to the cab will still be the same). I'll plumb it straight into my 3rd NIC on my Pfsense box and have a play around with the load balancing features.
I thought my BT contract was up next year, but in fact it's up in October....so that's why I've decided to do this now, get myself accustomed with AAISP sort out VOIP and then run down the BT contract.
Just a query I'm not sure on - is it just 1 pair which is carried across on the overhead cable to a premises, or do the overheads contain 'more than one pair' which can be connected up at a later date to supply an additional line? Or will they need to run an entirely new overhead to my property?
-
It depends, every drop cable can have a different number of pairs from what I've observed. One house I lived in a while ago had four pairs, while the house I'm currently living in only has two pairs. If there's a shortage of available pairs then I imagine they'll arrange to run another drop cable?
-
As Ixel points out it varies.
It could be 1 pair, 2 pair or even 4 pair.
I wouldn't expect a residential property to have more than a 4 pair drop cable.
The chances are your drop cable will have a 2nd spare pair that can be used.
-
I thought that would be the case, cheers for the replies.
Amazing turn around, I've already got a BTO install and an activation date for next week.
-
Sotonsam, I have three AA copper ADSL2 lines, bonded. 4.55mi long. I had a second pair activated in the original drop cable, then they ran a second drop cable to give me the third metallic path. I'm assuming that I have two pairs in the second drop cable too.
-
So, 2nd line installed today and service with AAISP all up and running. As you guys predicted below, there was a spare pair in the drop that he could re-use so that wasn't a problem.
Here are my stats for my new AAISP line:
http://dslstats.ddns.net:55551/connection.htm
Max: Upstream rate = 23220 Kbps, Downstream rate = 63693 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 64445 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 5.7 6.5
Attn(dB): 13.1 0.0
Pwr(dBm): 13.5 4.9
And for my existing line with BT Infinity:
http://dslstats.ddns.net:55555/connection.htm
Max: Upstream rate = 21044 Kbps, Downstream rate = 49752 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 62090 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 3.0 6.0
Attn(dB): 14.4 0.0
Pwr(dBm): 4.5 4.5
The one thing I've noticed with my old line is how my SNR has dropped down to 3, and my max rate is down to 49....
-
Most likely crosstalk from your new connection has caused the SNRM/attainable rate to drop on the downstream for your original connection.
-
Most likely crosstalk from your new connection has caused the SNRM/attainable rate to drop on the downstream for your original connection.
I'd second that.
I would probably resync the BT Infinity line if the errors start getting too high. We don't want to see the DLM adjusting parameters for it if the MTBE is too low.
Luckily for me when getting a "new line", even though the original drop cable had a free pair, I had a fresh drop. No noticeable crosstalk nasties for me. :P
Intersting to note that your new connection shows a newer DSLAM firmware than your old:
- BT Infinity: IFTN:0xb206 (178.6)
- AAISP: IFTN:0xd086 (208.134)
-
Intersting to note that your new connection shows a newer DSLAM firmware than your old:
- BT Infinity: IFTN:0xb206 (178.6)
- AAISP: IFTN:0xd086 (208.134)
Ah, so you have also spotted that.
Assuming both circuits are via the same ECI M41, I can only presume that the two lines are connected to different line cards.
-
My new line seems very clean, latency is as low as i've had it on FTTC.
Will keep an eye on my original line, I think the errors have settled down slightly now (we had a bit of thunder earlier which caused the errors to jump). Although oddly it didn't really affect my new line!
I've got both of these lines working via PfSense and have the WAN's ballanced, works pretty well to be honest and I'm happy with the results so far!
-
Ah, so you have also spotted that.
Assuming both circuits are via the same ECI M41, I can only presume that the two lines are connected to different line cards.
The same thing happened to me at my previous address last year. Zen's connection was on 0xb206 and AAISP's connection was on 0xd086. Of the two I found that the line card running version 0xd086 appeared to perform better. Both line cards were from the same ECI DSLAM.
I would probably resync the BT Infinity line if the errors start getting too high. We don't want to see the DLM adjusting parameters for it if the MTBE is too low.
Yeah, I'd do the same if it were my line.
I've actually developed a program that will take action if there's a high amount of errors, it's compatible with LEDE (some minor modifications to the dsl_control file such as adding bitswap stats and a few other changes) and my DrayTek router so that not only stats are being logged, but it will also adjust the downstream target SNRM depending on the number of downstream ES+SES in the last 24 hours (rolling) :). It's still work in progress though, useful to try and preserve fastpath or squeeze more speed out of the connection (one of my lines is at an offset of -2.0 dB, making it 4 dB SNRM).
-
My new line seems very clean, latency is as low as i've had it on FTTC.
I would agree. Seems like Openreach gave you a good pair. Perhaps it being a newer firmware may have some improvements also, going on what Ixel said. In fact, I did find Ixel's topic (https://forum.kitz.co.uk/index.php?topic=20451.0 (https://forum.kitz.co.uk/index.php?topic=20451.0)).
I would be surprised if your BT line synchronised much below what it currently achieves. Though it is not unheard of to see more than 10 Mbps lost through crosstalk when using additional pairs in the same cable.
Ixel, in regards to your topic mentioned above, perhaps the difference in the depth may have contributed in some speed difference? That also ignores some of the minor variences in the pairs.
-
Crosstalk can of course be bad and I presume you can not have G.Vector to fix it. I note that G.fast mandates the use of a G.Vector type system.
My second pair connection is a good bit worse then the first, and this is only very slow, low-frequency, ADSL2. However for some odd reason the original pair is not degraded, which makes absolutely no sense, crosstalk can not possibly be one way, so there is something bogus about this result or conclusion of mine.
-
Crosstalk can of course be bad and I presume you can not have G.Vector to fix it. I note that G.fast mandates the use of a G.Vector type system.
My second pair connection is a good bit worse then the first, and this is only very slow, low-frequency, ADSL2. However for some odd reason the original pair is not degraded, which makes absolutely no sense, crosstalk can not possibly be one way, so there is something bogus about this result or conclusion of mine.
You may have mentioned before Weaver, but what speeds do you have on your lines? Are these 'bonded' or do you just do soft load ballancing?
As I'm on an ECI cab I'm still waiting for the day we get G.NIP - just something to help. But I'm not holding my breath....
-
I have three fully IP-bonded ADSL2 lines, load splitting in both directions, done by the ISP downstream and by my Firebrick router upstream. The router’s WAN (internet-facing) interface presents a single unified IPv4 address, same for IPv6. A single say TCP connection goes at triple speed in both directions, it isn't a matter of allocation flows such as TCP connections or users to one or other link, everything is really triple speed. And it’s very efficient, better than 97% iirc. I get 3.05 Mbps downstream sync rate and 512k upstream on one line, the other two are about to get upgraded modems installed and get ~2700 kbps and ~2800 kbps downstream sync rates and 436k and 496k upstream, but the downstream should increase a good bit when I upgrade the remaining two modems.
The lines are 4.55 miles long, from the best estimate I can get. BT Wholesale supplies to the ISP AA.
-
Continuing saga on my BT Infinity line.
I'm now down to a 55 attainable.....
I can't see why though. Nothing locally should be affecting it, I was having these issues with it even before I got AAISP. That's now below my handback threshold of 56, but what do you think they'll be able to do? (Given that they've already been out twice). Maybe I just have to accept this is how it is..?? And this poss. gives me ground to cancel my contract early...?
http://dslstats.ddns.net:55555/connection.htm
for comparision, here is my AAISP line -
http://dslstats.ddns.net:55551/connection.htm
-
Just as an update to all of this, I now only have a single AAISP line - my BT line was cancelled and any termination charges were waived because I was below my handback, so that all ended well.
Amazingly this AAISP line is epic, so I've got a good pair me thinks. It's been up for around 25 days at 77mb, very few errors. Had to just resync it, didn't really want to...but I had to move some power bits around, but low and behold my sync has actually increased to 79 now.
This line is probably one of the best performing lines around on my attenuation! So my gamble really did pay off…!
http://dslstats.ddns.net:55552/index.htm
-
A good result, all round. :)