Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: arronlowley on May 09, 2017, 04:44:50 PM
-
reason im asking as ive been with sky since january, my connection was perfect up until the previous week.
my sync dropped from 70/20 to 49/20 so i rang sky would said they would send an engineer. after a couple of days my sync went up to bang on 60000/20000, meaning of course dlm capped, however i didnt have any interleaving applied which i thought was odd.
today an engineer came, reset dlm to tell me that it would not go back up to my original 70/20 or thereabouts and said the cab was fine and that no further action could be taken although he told me there is something wrong somewhere... why tell me there is something wrong if you cant or wont find the source and fix it.
anyway whats annoyed me is not the fact that my internet is still capped at 60, the issue is the dlm reset has caused interleaving... i thought a dlm reset got rid of interleaving not applied it.
i believe the dlm reset has turned off g.inp, my modem states bearer 0 and my errors are much much higher than before he reset dlm. if i had g.inp wouldnt it state bearer 1? my interleave depth on g.inp was 3 1 or 4 1 and now its 8 1. so im right in assuming the dlm reset has caused interleaving.
roadworks have been going on for the past 1-2 weeks, there are temp traffic lights been used etc close to the cab, could this also be an issue?
-
today an engineer came, reset dlm . . .
<snip>
i believe the dlm reset has turned off g.inp,
A full "circuit recalc" will leave it "wide open" on fast-path. Then, depending upon what the DLM process has noted, G.998.4 (a.k.a. G.Inp) will be re-applied. So, basically, a little patience will be required.
roadworks have been going on for the past 1-2 weeks, there are temp traffic lights been used etc close to the cab, could this also be an issue?
There is a possibility. But it would be rather difficult to quantify.
-
it just seems odd to me how i was synced at 70/20 since i joined with a noise margin of 6 and now im connected at 60/20 with the same noise margin...
if it was crosstalk it wouldnt say my max attainable is still 70, and surely the dlm reset should have put my sync back up, but it didnt. ive only had these issues since the roadworks began so im pointing the finger. pretty annoyed, when sky put their costs up, im leaving to go to vodafone as i will save £17 a month.
-
. . . im leaving to go to vodafone as i will save £17 a month.
:swoon: Are you sure you will be satisfied with Vodafone? Have you read the following three threads?
- http://forum.kitz.co.uk/index.php/topic,18911.0.html
- http://forum.kitz.co.uk/index.php/topic,19020.0.html
- http://forum.kitz.co.uk/index.php/topic,16987.0.html
:-X
-
it just seems odd to me how i was synced at 70/20 since i joined with a noise margin of 6 and now im connected at 60/20 with the same noise margin...
I don't think you are comparing full apples with full apples.
Right now, it looks like the DLM reset has been of the variety that starts out with interleaving, which may get removed in 2 days - and replaced with either an open profile, or a G.INP profile.
Speculation on here has been that there are 2 types of DLM reset, which behave differently. One of the differences is whether the starting position is "fully open" or "with FEC+interleaving". Another difference is whether existing "banding" (or, as you call it, "DLM capping") gets removed.
You said previously that you were now 60/20 with interleaving. But the act of adding interleaving also adds FEC, which in turn uses some of your bandwidth (10-15-20%). Because some of the bandwidth is used behind the scenes, your noise margins aren't directly comparable with times when there is little or no FEC.
i believe the dlm reset has turned off g.inp, my modem states bearer 0 and my errors are much much higher than before he reset dlm. if i had g.inp wouldnt it state bearer 1? my interleave depth on g.inp was 3 1 or 4 1 and now its 8 1. so im right in assuming the dlm reset has caused interleaving.
Hmm.
The best indication is to look at the "INP" and "delay" parameters, not the depth.
When INP is zero, then DLM has left things wide open.
When INP is in the region of 3-4, and delay is in the region of 8-16, then old-style DLM intervention has turned on FEC+interleaving - and you will get depths of around 1,000.
When INP is in the region of 30-50, and delay is still 0, the DLM has activated G.INP. We tend to see depths of 4 or 8, but other values have been seen - and differences might appear with ECI hardware.
-
Why hello wombat, I also posted on thinkbroadband lel.
Anyhow I've logged into the modem, I have an inp level of 3, delay of 8 and depth of 1181, so I'm guessing this means it's the old traditional Dlm.
Can you explain why the Dlm reset didn't increase my sync? I've had Dlm resets in the past and every time my sync went back to Max with no interleave, however this time it's the opposite and I have both.
-
Were those past DLM resets on FTTC?
The other issue with FEC+interleaving is that the max attainable rate reported tends to be a fair bit higher than the actual rate.
-
yes they were and thats not the case, i was with bt in 2015 and had a connection of 80/20 for the majority of the year and then it dropped to 70/20. i went to virgin media, then left and came to sky in january, had a sync of 70/20 until the roadworks started, my max attainable is still 70/20 as seen in the modem stats.
-
What I meant was, that with FEC+interleaving, the max attainable rate calculated will be very likely be a fair bit higher than what the line can now manage under its current state and environmental conditions.
So your max attainable is 70/20, and your actual downstream speed is currently lower than that, which is entirely to be expected with FEC+interleaving and how the max attainable rate is calculated.
-
With FEC+ interleaving, a max attainable of 70mb and current sync of 60mb, I would estimate the line to get about 65-66mb without interleaving.
Something definitely changed on your line, as it likely won't reach the 70mb you had previously. As others have said the max attainable is over-estimated when FEC+interleaving is applied.
Can you explain why the Dlm reset didn't increase my sync? I've had Dlm resets in the past and every time my sync went back to Max with no interleave, however this time it's the opposite and I have both.
A DLM reset on an ECI DSLAM still puts the line on fastpath. An engineer ordered DLM reset on a Huawei DSLAM now tend to apply interleaving.
-
What I meant was, that with FEC+interleaving, the max attainable rate calculated will be very likely be a fair bit higher than what the line can now manage under its current state and environmental conditions.
So your max attainable is 70/20, and your actual downstream speed is currently lower than that, which is entirely to be expected with FEC+interleaving and how the max attainable rate is calculated.
As @ejs says ^^^
I'll just add that, if the FEC+interleaving gets removed by DLM, and the line switched to an "open" profile, the sync speed that results tends to be halfway between the current sync and attainable speeds being reported (ie while FEC+interleaving is in place). It would be likely that your line would swap to 65/20 - both in sync and attainable.
HOWEVER...
If your line swaps to a G.INP profile directly, then you might not see this stage. And it is possible that, with G.INP active, you could end up on the same (ie 65/20) speed or higher.
Can you explain why the Dlm reset didn't increase my sync? I've had Dlm resets in the past and every time my sync went back to Max with no interleave, however this time it's the opposite and I have both.
a) BT keep "playing" with DLM. They seem to add features, and change behaviour. At the very least, we've seen changes to cope with G.INP for the last 3 years, including attempts to cope with ECI incompatibilities/faults. We've also likely seen changes to cope with ASSIA patents claims.
b) Last year seemed to bring evidence that (i) DLM resets didn't always get rid of banding; (ii) DLM resets seemed to work in two different ways; (iii) banding was used more aggressively, and (iv) banding sometimes stuck.
I'm expecting DLM to change again this year - at minimum to cope with the 5-4-3dB targets, but likely for ECI G.INP too.
BT don't advertise the behaviour of DLM. All we can do is observe, watch for changes in that behaviour, and try to figure out the reasoning behind it. It is a war that we can only ever come second in.
Your line?
It seems likely that you've fallen foul of both some crosstalk changes and a DLM intervention ... potentially mixed up with the traffic works.
-
A DLM reset on an ECI DSLAM still puts the line on fastpath. An engineer ordered DLM reset on a Huawei DSLAM now tend to apply interleaving.
Oooh. I'd not seen the methods reported as an ECI/Huawei distinction before
-
Indeed my line is now at a 4dB target again but I suspect some banding has been applied to keep sync to 71 as I am seeing lower errors. I think Openreach/BT are still playing with DLM.
-
im not too bothered if my sync doesnt go back up to the full 70 and i know the issue isnt crosstalk otherwise my max attainable wouldnt be the same...
im just bothered about the latency.
-
If and when the interleaving gets removed, perhaps replaced with retransmission (G.998.4 / G.INP), then the max attainable rate calculated will be lower.
-
as far as i remember there is no 71 step for banding its 74 then 67, but i welcome to be corrected
-
as far as i remember there is no 71 step for banding its 74 then 67, but i welcome to be corrected
Bob on ......... Level 34 is 67Mbps ...... Level 35 is 74Mbps. #nolevel42quipsthanks. ;D
-
I recall seeing some of the lists of banded speeds quite a while ago.
However, I vaguely remember a couple of reports last year (one via Walter), where DLM was gradually reducing the banding (ie was increasing speed) in almost round-number steps of 2.5Mbps - at least in the middle of the scale.
So, the pattern would be something like: 20, 22.4, 25, 27.6, 30, 32.4, 35, 37.6, 40, etc
In those cases, DLM relented so far, before getting "stuck". Banding wasn't removed completely.
That pattern was absolutely nothing like the previous list.
Does anyone else remember these cases?
-
wombat yeah is much smaller gaps undet 40mbps
-
As mentioned by Chrys above ...... the nearer you get towards level 1 (2Mbps), the smaller the banding increments become.
-
[Moderator note: This post & the following replies have been split off from a thread on a totally different topic and merged here.]
some people think that they can reset dlm from their end, but its not possible otherwise they wouldn't spend time sending engineers out.
i had an engineer sent yesterday, he reset my line but dlm decided to not give me my max sync back and instead gave me interleave, the engineer told me that there is an issue somewhere but because my line is within the estimated range openreach wont find it...
now i fail to understand how you can have a job to do but instead tell the customer that you wont do anything about it, my line came back clear and the cab came back clear, but he said there is something causing my line to error, which i believe is roadworks as this issue has been going on for about 1 to 2 week, i went from 71/20 to 49/20. now im stuck at 60/20
-
i will update when dlm decided to apply g.inp, hopefully my sync will go back up, my line was capped at bang on 60000/19999 but after the reset its at like 60313/19999.
so i still think its been capped.
-
if he moves to the lower package, it will just be capped at the max speed of 40/10 or 40/2 whatever talk talk do.
it wont reset dlm though.
some people think that they can reset dlm from their end, but its not possible otherwise they wouldn't spend time sending engineers out.
i had an engineer sent yesterday, he reset my line but dlm decided to not give me my max sync back and instead gave me interleave, the engineer told me that there is an issue somewhere but because my line is within the estimated range openreach wont find it...
now i fail to understand how you can have a job to do but instead tell the customer that you wont do anything about it, my line came back clear and the cab came back clear, but he said there is something causing my line to error, which i believe is roadworks as this issue has been going on for about 1 to 2 week, i went from 71/20 to 49/20. now im stuck at 60/20
What exactly do you think the roadworks is doing to the line?
Short of a generator or something inducting some sort of noise, unless the cables are physically disturbed by the roadworks, I can't think of how they could interfere.
Surely everyone on the cab/cable bundle you're on would be experiencing the same issue?
-
im fuming, before the engineer visit my line was fine apart from the loss in sync, now since hes messed about, my internet has become a lot worse, last night i was lagging and tonight its even worse :@ im getting ping spikes into the thousands, and severe packet loss, traceroute indicates its skys network, as the pings are high in hop 3.
-
just look at the state of this :@
https://i.gyazo.com/26eaf90f7ea0eeff94058a4c1b174481.png
-
i would assume so but i dont know anyone else on sky so i cant check, but since the engineer messed with whatever he did, things have gotten worse, im getting severe packet loss and high ping which points back to the network at hop 3, tonight gaming is unplayeable. im so peed off.
-
i would assume so but i dont know anyone else on sky so i cant check, but since the engineer messed with whatever he did, things have gotten worse, im getting severe packet loss and high ping which points back to the network at hop 3, tonight gaming is unplayeable. im so peed off.
The ISP would be irrelevant, as the connection doesn't get to the ISP kit until the handover point. So any of your neighbours on FTTC from the same cabinet would be affected if it were due to the roadworks.
Do you have any noise on the line?
-
You should be able to change your DNS to say Google public DNS and see how it fairs when doing ping and tracert's
-
i dont know if any of my neighbours are on fttc so as i say i cannot ask. the engineer said my line was fine however he said there was an issue somewhere but he couldnt be bothered to look for it... he went to the cab and said it was fine.
but since his visit i am now lagging and am getting packet loss. i go to work to come home to this crap, its a joke,
-
yet some plonker from sky chat is telling me i dont know what im talking about, yet hes trying to tell me its one of my devices... dont think so pal, only started to lag since after the engineer left.
-
i just have no luck with any isp i come across its a total shamble, its a shame i cant get fttp with hyperoptic.
-
arronlowley your thread is turning into a rant and that sort of stuff gets ignored here, have you a FTTC fault or not ?
-
For reference purposes -- http://forums.thinkbroadband.com/fibre/t/4545498-engineer-visit-made-things-worse-need-help.html
-
im fuming, before the engineer visit my line was fine apart from the loss in sync, now since hes messed about, my internet has become a lot worse, last night i was lagging and tonight its even worse :@ im getting ping spikes into the thousands, and severe packet loss, traceroute indicates its skys network, as the pings are high in hop 3.
which do you prioritize, low stable pings or maxed out sync speed? banding is the best solution for the former g.inp aside.
if hop 3 had high latency but the hops afterward did not you can ignore that it is a red herring.
-
arronlowley your thread is turning into a rant and that sort of stuff gets ignored here, have you a FTTC fault or not ?
Wise words.
-
G.inp kicked in yesterday at 10am, low ping and 70/20 which is my max sync but now my ping monitor is showing other issues which is packet loss.
The packet loss is only showing up in the evening at peak times, my latency is also spiking at these times, seems to me like there is something going on in terms of utilisation.
-
I'd wait for roadworks to finish, then ask sky to re-test line.
I'm sure Sky would be happy to send engineer out if your happy to accept the SFI2 charges if engineer can prove line is fine.
It could also be an issue in sky's network, over congestion.
Don't always assume its the line.
Another thing you can try is requesting a new sky router.
-
i will post some screenshots in here about what i mean, for the last 3 nights the packet loss is in the evening after 6pm, if you look before and after 6pm and 11pm you can see how solid the latency is, which is why i think its congestion.
[attachment deleted by admin]
[attachment deleted by admin]
-
Where an increase in latency affects the yellow area, but not the blue area, then it is an indication of a relatively minor amount of congestion.
Each pixel width represents about 100 pings over 100 seconds; the blue columns tell you what has happened to the pings on average.
- If there is no blue column, then the average latency is equal to the minimum latency.
- If there is a tall yellow column, but no blue column, then there has been a delay to one or two pings. If more pings were affected, then the average would increase, and a blue column would exist
Working through the maths, you can see that each extra blue pixel requires (from 100 pings) a total of an extra 100ms of latency.
This can be achieved with
- 1 ping taking 112ms instead of 12ms
- 5 pings taking 32ms instead of 12ms
- 10 pings taking 22ms instead of 12ms
- 20 pings taking 17ms instead of 12ms
In the final pingplot attached, at around 9pm, it looks like you are seeing 1 blue pixel over a fair period (2 hours), and 2 blue pixels over short periods (5-10 mins). The average is going up slightly, while the maximum tends to be around the 22ms level or less.
That suggests that, over a 2 hour period, you are getting additional latency of 5-10ms to around 10-20% of your packets. And, in some small 5 minute bursts, the same kind of delay to around 20-40% of your packets.
That plot is quite normal for a line that was in use at the time - such as watching Netflix - or for showing low level congestion over a wide area, that is common in the evening peak. I've attached 2 examples from my line - 1st, a day when only the SamKnows tester was working, and 2nd, notably where Amazon Prime was streaming HD to the TV.
Your plot is not what I'd consider to be an indicator of anything wrong with the line. It looks unlikely to be something caused by the engineer.
Your previous attachment with large outbound pings might, instead, suggest one of Sky's routes was heavily congested, but not the one that the BQM transits over.
Edit: Added the lost attachment.
-
so do you think this is just normal then? my girlfriend has been using an amazon fire stick recently and quite a lot, could be that.
the other night when i posted the cmd ping, i think that was my error, i was connected at 2.4ghz and the wireless strength wasnt the best and i believe windows was downloading an update in the background. i tested it and my ping times were all over, connected back at 5ghz and it wasnt as much of an issue, what im going to do if i have permission from my girlfriends parents as this isnt my house, is bring the telephone cable around the back of the house in term making it shorter and putting the router in the room with the pc and using an ethernet cable, our internal wiring is too old to use powerline to its full potential, im talking over 30 years old.