Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: NewtronStar on April 15, 2016, 12:35:17 AM
-
Does this help understand how the graph works? :flower:
Think I have had the 3dB profile set on my line the modem re-synced at 00:00
[admin split from this thread (http://forum.kitz.co.uk/index.php/topic,17494.0.html)]
-
Does this help understand how the graph works? :flower:
Think I have had the 3dB profile set on my line the modem re-synced at 00:00
:cool:
-
Nothing hear but there again I am on ECI and we get everything at least 12 months down the line
-
Does this help understand how the graph works? :flower:
Think I have had the 3dB profile set on my line the modem re-synced at 00:00
Looks like your error seconds have increased aswell...
-
Think I have had the 3dB profile set on my line the modem re-synced at 00:00
Ooooooh... it looks like you do indeed!
Nice one, its taken you straight up to 39999 :dance:
Looks like your error seconds have increased aswell...
:( Have to watch that closely. I cant see on MDWS yet exactly how its affecting. All I see atm is there has been 10 Err Secs since 11pm.
Its also not to unusual to see the odd ErrSec at sync time.
-
Hmm, good point kitz ;)
I'll be keeping an eye on that, I wouldn't mind Interleaving being turned off at the moment... missing 10Mb of potential sync, as well as the other missing 20meg ::)
-
NS's news is definitely exciting :)
sorry was in mid flow when typing a response to your post and the modem did a resync and went to investigate and the stats changed.
let hope this is not a crosstalker thing but this time the upstream has changed which never occurs when the crosstalker turns off their modem
-
It was strange I first noticed the network icon turning yellow on the PC screen then looked at the router it was blinking red on the Internet status it would not connect, checked the router logs and a lot of PADI were showing up.
Then turned off the router for a few minutes not the modem and it connected ok and the SNRm had changed and also the Sync rate.
DS FEC's has increased a bit
-
Doesnt look like a crosstalker.
From what I can see, you went straight in at 3dB and nearly 2 hrs later, your max attainable is still holding nicely at around 40Mbps.
If it was a quick sync before your disturber, then your attainable would drop.
Your Errored seconds have settled as well - so far so good :fingers:
-
DS FEC's has increased a bit
Hmm so they have, but otherwise all seems ok so far.
Its only natural that you will get an increase in error rate the lower your SNRm drops... but as long as FEC and G.INP can keep the line stable and they don't turn into E/Secs, then all should be good.
You're now pushing your line to its limits... but got a nice 4.5Mbps increase out of it. :)
We just need vectoring now ::)
-
Congratulations, NS! Maybe I'll get the new profile soon!
-
Just wondering if I get a sync rate of 35 Mbps at 10 dB, what would I get at 3 dB? About 45 Mbps?
Also, I wonder if this removes banding any quicker? Not that I need it removed now... :D
-
Ooh. Interesting. Can't wait to see it on MDWS...
-
Just imagine if everyone's line went onto 3 dB? :D
-
Keep thinking at some stage the modem is going to do another resync and it will be back to 6dB anyway my line is in the good hands of the DLM ::)
-
If your line's stable it may not, I may get given the 3 dB SNR Margin on Monday if I'm lucky.
-
Would it be a good bet to say no 3dB on ECI until they sort out the G.INP problems?
-
I would say so yes, I would think G.INP might be makign 3db SNR profiling possible...
-
Apologies if this has already been mentioned, but is the 3db margin on US/DS or just the downstream?
-
Type of cabinet shouldn't make any difference. It's being trialled on both types of cabs.
It's a stage 2 trial that is being applied to about 50k lines... so not everyone will get it.
Just because you are switching to 55Mbps account, that doesn't necessarily mean that you will get 3dB.
-
Apologies if this has already been mentioned, but is the 3db margin on US/DS or just the downstream?
From looking at NS's stats, its 3dB up and 4dB down.
-
Thanks kitz ;D
A bit of a boost to the upload would be nice!
-
Just because you are switching to 55Mbps account, that doesn't necessarily mean that you will get 3dB.
I know that, but it's quite likely.
-
My worry when the SNRm is at 3dB will be during evening times as SNRm will drop by 1dB around 20:30 hours and may see the SNRm hitting the 2.4dB mark, that's when i'll start to cringe :phew:
-
> SNRm will drop by 1dB around 20:30 hours and may see the SNRm hitting the 2.4dB mark, that's when i'll start to cringe
It depends on the modem you've got and on the line conditions but you might get away with it quite ok. I do. (But with ADSL2, not VDSL2.)
-
Type of cabinet shouldn't make any difference. It's being trialled on both types of cabs.
It's a stage 2 trial that is being applied to about 50k lines... so not everyone will get it.
Just because you are switching to 55Mbps account, that doesn't necessarily mean that you will get 3dB.
Seeing as I got G.INP early on ECI they should give me 3db too :D
Wishful thinking ::)
-
My worry when the SNRm is at 3dB will be during evening times as SNRm will drop by 1dB around 20:30 hours and may see the SNRm hitting the 2.4dB mark, that's when i'll start to cringe :phew:
Seems to be doing well at the moment, fingers crossed.
-
Just seen the DS SNRm hitting the low point of 2.1dB no DS errored seconds the SNRm should start to increase as it's just coming up to 21:00 hours :fingers:
Edit just the 1 errored second at 20:54
-
Just seen the DS SNRm hitting the low point of 2.1dB no DS errored seconds the SNRm should start to increase as it's just coming up to 21:00 hours :fingers:
Just as you said that you get 1 ES! :D
-
The 3dB SNRm sounds like this ->
My midi file converted to Fruity Loops
https://soundcloud.com/yamahadx7/miles-children-808 (https://soundcloud.com/yamahadx7/miles-children-808)
-
Viewing your SNRM plot for the last 24 hours, it looks as if you need to perform the experiment . . .
Initiate a re-synchronisation event at 1000 hours, tomorrow morning. Then we will see, for sure, at what value your target SNRM has been set. ;)
-
Initiate a re-synchronisation event at 1000 hours, tomorrow morning. Then we will see, for sure, at what value your target SNRM has been set. ;)
I was hoping the DLM would do that for me at some stage just don't like messing around until the 48 hour period has passed by
-
BT rolling this out is going to annoy peeps like me, as they cant even get g.inp right on my line yet. Which is a requirement for this 3db profile.
So we now have a 3 tier service, dependent on cabinet lottery?
1 - no g.inp 6db
2 - g.inp 6db
3 - g.inp 3db
-
Chrysalis we've always had a multi tiered service based on how far away the cabinet is and how good your line is :P
Why should no g.inp annoy you, looking at your stats your on fast path and you have a 72/20 sync, fancy a swap with myself, BE1 or Weaver?
-
Chrysalis we've always had a multi tiered service based on how far away the cabinet is and how good your line is :P
I agree with Chrysalis. I am on an ECI cab and would really benefit from Ginp, 3db and vectoring. I am one of the lucky ones with Ginp and this has given me a speed increase.
What irks me is BT have used two cab providers and it is clear that one is sh#t and one is good.
Knowing we probably need to wait another year before BT does anything else with the ECI cabs is even more infuriating. My line will easily manage a 3db target just switch it on and let the DLM do its thing if there is an issue!
BT should use lines/cabs which have technical users. These users can try their different modems and avoid all these false starts. Clearly they are targeting lines where the users do not have a clue if their line has been impacted by something new or not.
<rant over>
-
Chrysalis we've always had a multi tiered service based on how far away the cabinet is and how good your line is :P
I agree with Chrysalis. I am on an ECI cab and would really benefit from Ginp, 3db and vectoring. I am one of the lucky ones with Ginp and this has given me a speed increase.
What irks me is BT have used two cab providers and it is clear that one is sh#t and one is good.
Knowing we probably need to wait another year before BT does anything else with the ECI cabs is even more infuriating. My line will easily manage a 3db target just switch it on and let the DLM do its thing if there is an issue!
BT should use lines/cabs which have technical users. These users can try their different modems and avoid all these false starts. Clearly they are targeting lines where the users do not have a clue if their line has been impacted by something new or not.
<rant over>
It's extremely fortunate that BT have chosen to use more than one cabinet vendor. Try to imagine the repercussions if BT only used Huawei cabinets. It should then become obvious to you why this would be an extremely bad idea.
-
Clearly they are targeting lines where the users do not have a clue if their line has been impacted by something new or not.
Can you enlighten us as to how they go about this ruse ?? ::)
-
Considering the the trial is ~100,000 lines and there are 33million of them we are lucky to even see one, unfortunately only 1/330 are in the trial I highly doubt BT has a massive spy network to determine how to avoid us :D
-
BT rolling this out is going to annoy peeps like me, as they cant even get g.inp right on my line yet. Which is a requirement for this 3db profile.
So we now have a 3 tier service, dependent on cabinet lottery?
1 - no g.inp 6db
2 - g.inp 6db
3 - g.inp 3db
Chrys they are not rolling it out. Its a trial. A test on some lines. Some lines will get it and some wont.
So how is a 3dB trial annoying you?
I know for a fact that I will not be part of the trial, so no point me holding my breath.. and its nothing to do with the fact that Im on an ECI cab.
-
It's unlikely I'll get it, but I might be one of the lucky few connected my cabinet! *Wishful thinking* :D
How do people know if they have a change of getting it?
-
Considering the the trial is ~100,000 lines and there are 33million of them we are lucky to even see one, unfortunately only 1/330 are in the trial I highly doubt BT has a massive spy network to determine how to avoid us :D
Check MDWS ID: NStar. :)
-
It's unlikely I'll get it, but I might be one of the lucky few connected my cabinet! *Wishful thinking* :D
How do people know if they have a change of getting it?
The only way to know for sure is to be head of planning at BT.
-
If I currently have a Downstream SNR Margin of 10 dB with a Downstream Attainable Rate of nearly 45 Mbps, then at 3 dB will I get about 50 - 55 Mbps?
-
See the graph I made below, that my assumption.
-
See the graph I made below, that my assumption.
Thanks!
-
Unfortunately the IP profile and Sync rate don't match still on the 92.3% instead of 96.8% so with a sync rate of 39999Kbps the throughput should be 38720Kbps but all I am getting is 36950Kbps a loss of 1770Kbps somewhere.
Still it's way better than the IP Profile of 28.4 that I used to get before G.INP was rolled out and when I first got VDSL2 installed the open profile sync was 32000Kbps for 2 days and I am exactly 1000 meters from the cabinet that is good going for the old pots cable which was not designed to take these higher frequency we use on FTTC.
-
I am exactly 1000 meters from the cabinet that is good going for the old pots cable which was not designed to take these higher frequency we use on FTTC.
VDSL2 was designed for use on the POTS cable. 99.9% of all new houses in the UK have had POTS cable installed, and still do today. It's good for BT that they've been able to keep this decrepit infrastructure relevant, though not so good for us, the end users.
-
Chrysalis we've always had a multi tiered service based on how far away the cabinet is and how good your line is :P
Why should no g.inp annoy you, looking at your stats your on fast path and you have a 72/20 sync, fancy a swap with myself, BE1 or Weaver?
It annoys me as its technology progression and that it is a prerequisite for the 3db profile (which in turn improves burst speed).
I do also get occasional SES. So the errors are not completely not service affecting.
Finally I also dont just think about myself, there will be people stuck on interleaving because of this.
-
BT rolling this out is going to annoy peeps like me, as they cant even get g.inp right on my line yet. Which is a requirement for this 3db profile.
So we now have a 3 tier service, dependent on cabinet lottery?
1 - no g.inp 6db
2 - g.inp 6db
3 - g.inp 3db
Chrys they are not rolling it out. Its a trial. A test on some lines. Some lines will get it and some wont.
So how is a 3dB trial annoying you?
I know for a fact that I will not be part of the trial, so no point me holding my breath.. and its nothing to do with the fact that Im on an ECI cab.
True its not a full rollout, its a small rollout for the trial. My post more meant "if" this proceeds to a full rollout whilst ECI cabinets are not fully g.inp activated I will be annoyed.
So the trial itself in its present state doesnt annoy me.
So now this is cleared up, will you please share with all us peons all the 3db trial information you have :)
-
Nice clarification Chrysalis. I think we all appreciate the Kitz forum as the only place you can get good, reliable technical information.
PS. There is nothing worse than not knowing what someone else knows... and have told you they know! Pretty please Kitz ;)
-
It will certainly benefit some more than others, and it should give me a bit more of a speed boost, although it's my upload that really suffering. I wonder why they don't make it the target SNRm variable so each line can adjust to it's optimum, perhaps that's just too complex?
PS Kitz, please share :fingers:
-
PS Kitz, please share
There will no doubt be some who will complain and who will think its their right to then go demand that their ISP to be put on the trial.. and all that will happen is some script monkey will know nothing about it.
Its the ISP who ultimately decides if their customers partake in the trial. I don't know the criteria other than its ISP related and which (if any) of those customers will go on the trial.
Looking at you William - No matter how hard you pester your ISP, they will not put you on the trial just because you ask them, so there is absolutely no point moaning if you are selected or not. Its possibly already been decided and nothing you can do is going to change it.
---
Its not unknown for BT to ask ISPs such things.
They did this with maxdsl - "Do you want to partake in the trial - can we have 'x' no of customers from you."
-
I already knew the above, and thats the only reason why Im sharing now.
However, this is the last time I go looking for or asking for more info.. because every single time I do, then all I get is grief and false accusations about BT.
Its happened with DLM, my suspicions about the MSILs & PN, G.INP Mk1, G.INP Mk2, G.INP 2016, 3dB.
It should have been abundantly clear that Im sick of having to justify I do what I did for the sake of getting more info.
The hints were there that I was sick of hassle when all I was doing was trying to help.
Its just not worth it and takes up far too much time and all I get for my efforts is stupid accusations.
---
ETA
Those that wondered what the above is about, obviously didn't see some of the comments the other day as to why I went off on one and why I am so fed up.
-
I agree there is no right to demand to be put on a trial and so forth.
I think the issue that has got to some people, is that CP's are not communicating with their customers, so the issue not with openreach but with the CP's. not communicating with their customers, this sort of information at the very least has to be passed onto those selected end users in the trial.
This 3db trial is a good thing going forward and will surely up most people's speeds without a downside (g.inp managing most of the risks).
-
Looking at you William - No matter how hard you pester your ISP, they will not put you on the trial just because you ask them, so there is absolutely no point moaning if you are selected or not. Its possibly already been decided and nothing you can do is going to change it.
Sorry, but if you mean me, where did I state I would moan if I wasn't on the trial, I understand it would be very unlikely and why would I contact BT?
-
I will be watching the trail with some interest as it may have the potential to squeeze even more speed out of ageing copper.
However, does this not have the potential to make crosstalk worse for those that are already affected? With more data squeezed down the lines using previously ignored frequencies, as they were below the margin set for a 6db margin, doesn't this mean that it will impact upon other users on the same cabinet? For me this means that either GNP will have to work harder (or add more depth to compensate for errors) or this will just end up being a zero sum game where once everyone has it on a cabinet that there will be more crosstalk and the end result will not be significantly different from what we have now. This may also have implications for those connected to a cabinet who are much further from that cabinet. Those users closer to a cabinet will see more benefit, but again, this will create more crosstalk and be a bigger problem for those who are further away.
With this in mind, I'm surprised that the trial seems to be with individual users and not individual cabinets as this has effectively ruled out a consideration of the above problem.
I'd also have some doubts about the ability of the current backhaul in many areas to cover the increase in available bandwidth that is now available to consumers, especially at peak times, but that is another issue.
Interesting times, and it is always good for a healthy and informed debate here on Kitz, so please feel free to correct any assumptions that I have made which are wide of the mark :)
-
Seem to have had this happen on morning of 15th.
No mass of graphs as I'm only running by BQM and a rare speed test.
Throughput gone from 63Mb/s to a touch over 67Mb/s.
This is on a Huawei 288, one of a pair, approximately 500 enabled FTTC lines between them at about 500m of cable from cabinet
-
Its the ISP who ultimately decides if their customers partake in the trial. I don't know the criteria other than its ISP related and which (if any) of those customers will go on the trial.
<quote snipped a bit>
Thanks for the info.
As probably yourself and others here, I remember when ISP’s were smaller and asked for volunteers to trial new products.
The last trial I took part in was when UKOnline were trailing ADSL2. IIRC it took 3 profile changes before I could keep synch at the heady speed of 15Mb/s - and I was subject to a NDA.
Also I’m pretty sure I was paying more for broadband then than I am now. How times change.
-
Its the ISP who ultimately decides if their customers partake in the trial. I don't know the criteria other than its ISP related and which (if any) of those customers will go on the trial.
<quote snipped a bit>
Thanks for the info.
As probably yourself and others here, I remember when ISP’s were smaller and asked for volunteers to trial new products.
The last trial I took part in was when UKOnline were trailing ADSL2. IIRC it took 3 profile changes before I could keep synch at the heady speed of 15Mb/s - and I was subject to a NDA.
Also I’m pretty sure I was paying more for broadband then than I am now. How times change.
Yes, we pay at least £20 less a month for 37 Mbps more speed...
-
Seem to have had this happen on morning of 15th.
No mass of graphs as I'm only running by BQM and a rare speed test.
Throughput gone from 63Mb/s to a touch over 67Mb/s.
This is on a Huawei 288, one of a pair, approximately 500 enabled FTTC lines between them at about 500m of cable from cabinet
I would have expected a bigger jump in speed, seems a bit disappointing.
You are on a 3db snrm now?
-
According to post (http://forums.thinkbroadband.com/fibre/t/4477372-anyone-on-the-3db-snrm-yet.html) on TBB:
the SNR, it can be 3dB, 4dB or 5dB. It doesn't have to jump right down to 3. It'll depend on the line. Obviously if your line is already on 10dB or higher it seems unlikely you'd ever see any benefit from this trial, DLM won't suddenly reduce the SNR to under 6 just because you happen to be in a trial area.
-
thats why I asked if its 3db, as it may be possible he could be on 4 or 5db.
-
I would have expected a bigger jump in speed, seems a bit disappointing.
You are on a 3db snrm now?
I'm assuming a margin change is the cause of the increase. The timing suggests it was a configuration change of some description and certainly not been at 67Mb for about 300 other subscribers on the node. Not monitoring the modem for right now so no idea about the exact margin.
-
Earlier this afternoon, in a PM with Chrysalis, I mentioned that it does seem as if N*Star's circuit is operating with a 4 dB target SNRM.
Subsequently my attention was drawn to the comments made elsewhere (http://forums.thinkbroadband.com/fibre/t/4477372-re-anyone-on-the-3db-snrm-yet.html).
Perhaps those avid MDWS watchers will make a note of which circuit appears to be operating with a 3 dB, a 4 dB and a 5 dB target SNRM? :)
Do we have one or more representative cases of each of those targets? :-\
-
Could you look at the SNRm graph at just after 00:00 to me that looks like crosstalker spikes ???
-
Definitely looks like crosstalkers to me, it's not that user who's been having line drop outs again?
-
I'm assuming a margin change is the cause of the increase. The timing suggests it was a configuration change of some description and certainly not been at 67Mb for about 300 other subscribers on the node. Not monitoring the modem for right now so no idea about the exact margin.
It was not a margin change it appears.
I suspect planned work was being carried out on the DSLAM and it was reloaded. The outage was somewhat long for a resync.
The increased sync would've been due to my modem coming online before some of my many disturbers (~287 of them on one DSLAM, ~200-240 on the other).
I restarted my modem earlier and not only was there no 6dB profile, DLM responded to the restart by switching off G.inp and falling back to default 8ms delay downstream interleaved profile.
No matter. Will leave it be and let it do its thing.
-
this is the problem with no access to stats, lots of people will now assume any upward change of sync speed is now related to this trial.
-
Looking critically at the plot of N*Star's SNRM that I posted in the early hours of this morning we can see, a the far right hand end, that "something was happening". My initial thought was that perhaps another stepped reduction of the SNRM target was taking place. Clearly that was not the case.
Looking at the latest SNRM snapshot plot we can see that the target still appears to be 4 dB. (But we can't be absolutely sure without seeing the effect of a resynchronisation event.)
Having considered all the various graphs that have been plotted from the data harvested from N*Star's circuit, it does seem as if the circuit is somewhat abnormal. One to continue to watch. :)
-
Surely the upload target is 4dB and the download one is 3dB, otherwise the attainable when SNR is at 3.3 would be below the sync.
Maybe it only looks like 4dB on the download due to the service being 40/10.
-
I was able to look at NS's stats at the time it happened, at that particular moment in time, it was quite clear at the time it was 3dB on the downstream.
If you zoom in real close you can see at that particular time the line had small bumps but was only varying by about 0.1dB.
ie prior to the resync there were small fluctuations of between 7.2 and 7.3 dB. After the resync there were small fluctuations between 3dB and 3.1dB.
Most of his SNR variance doesn't start until 5pm but starts to rise again after 9:30.
At the time of the resync aside from the odd 0.1db it was pretty stable and doing its usual thing.
It does however look like the upstream is set at 4dB.
I guess a resync is in order, to double check.
----
attached
1) Zoomed in graph showing 3.1 dB and small fluctuations between 3db and 3.1dB for the downstream.
2) Zoomed in graph of downstream bands, at time of sync showing 2.9dB for D1 and 3.1dB for D2
-
Maybe it only looks like 4dB on the download due to the service being 40/10.
Like you say, he will be restricted to syncing at the max 39999, so there will be times when he goes above 3dB.
Between the hours 4am and 4pm the line is at its best, so will sync at 39999 with surplus SNRm.
The sure-fire way of finding out would be a resync at around 7/8pm when the line is at its worst.
-
it does seem as if the circuit is somewhat abnormal. One to continue to watch. :)
My circuit has been abnormal for just under a year and even your good self has made comments in the past to my line stats ;D it's like a SNRm battle against my crosstalkers.
I suspect it's all down to the badly corroded underground joint that effects all who use this distribution pole and until that has been sorted out then premises No 1 is still going to have random drop outs which effects my SNRm.
When on the 6dB profile if the SNRm went below 4.5dB it was an automatic DLM resync for my modem.
-
I suspect it's all down to the badly corroded underground joint that effects all who use this distribution pole <snip>
Ah, yes. I had completely forgotten about that known poor joint. :(
-
Between the hours 4am and 4pm the line is at its best, so will sync at 39999 with surplus SNRm.
The sure-fire way of finding out would be a resync at around 7/8pm when the line is at its worst.
Would you like a quick HG612 resync or a power off and wait 30 mins & stick the 12v plug back in think I can afford 1 MTBR, 21:00 looks like the lowest SNRm point at the moment
-
A quick resync should do it.
You will get away with just the one. Ive done 5/6 once when testing a router and DLM left me alone.. but IIRC your ISP may use a different profile. 1 or 2 will be perfectly fine though.
-
It was a crosstalker thingy aargh
-
It was a crosstalker thingy aargh
Damn, your back to 6 dB. Whaaat?
-
It was a crosstalker thingy aargh
Damn, your back to 6 dB. Whaaat?
Ah well back to 33000 Kbps it won't hurt me from streaming 3 HD movies at the same time :D
-
Such a shame, naughty b*kat...
-
I had a similar event happen to me a night recently (I think last Wednesday). Around the same time in the evening my line dropped and came back up at around 61mbps (ordinarily around 53mbps)... once everyone else came online my SNR was 0.8dB - clearly unsustainable, but no errored seconds!
They must just be doing some sort of upgrade work on the cabinets and we happened to connect before the majority of the crosstalkers did.
Kind of shows just how much of an effect crosstalk is actually having. 61mbps might have been after half of the users had connected, or I might just have been the first, I suppose it's impossible to know unless there's a power cut. However, vectoring still looks like something we won't see!
Currently my line is showing a SNRM of around 3dB, but that's just my own doing. I have another VDSL line in here at the moment and it hits with about 3dB in crosstalk, so I make sure it isn't in sync when that one is negotiating with the DSLAM.
-
Such a shame, naughty b*kat...
Wasn't me! :P It was our leader, Kitz, who recommended performing a resynchronisation at the circuit's worst time for RFI.
Now that we know N*Star's circuit is not included in the 3 dB target SNRM trial, he could then perform another resynchronisation at around 1100 hours on Wednesday or Thursday and regain some DS & US speed.
-
Such a shame, naughty b*kat...
Wasn't me! :P It was our leader, Kitz, who recommended performing a resynchronisation at the circuit's worst time for RFI.
Now that we know N*Star's circuit is not included in the 3 dB target SNRM trial, he could then perform another resynchronisation at around 1100 hours on Wednesday or Thursday and regain some DS & US speed.
Oops! You're both cats! :lol:
-
If it was a cross-talker then why did the max attainable go up and stay up?
Newtrons max attainable is the highest it has ever been, if it was an x-talker, then surely his max attainable would not have stayed so high once the disturber came back online?
Look at NS's stats over the past 240 days in the graph below.
Note how when the max attainable goes up - then correspondingly the SNRM goes up. That is typical behaviour from crosstalk.
Yet on the 15th, when the max attainable went up.. the SNRM went down. That is unusual behaviour. Since when did less SNRm cause more attainable speed if it wasn't anything to do with the target SNRm or FEC overheads. The pattern since the 15th was totally different. ???
Generally speaking max attainable should mirror SNRm. It didnt - on the 15th SNRM went down and max attainable went up indicating something else was at play.
I'm also wondering about Ignition too now, who thought he may have had it.. then it vanished after a resync. Mind you, it would a bit of a rubbish trial if it got removed upon a resync.
-
I had a similar event happen to me a night recently (I think last Wednesday). Around the same time in the evening my line dropped and came back up at around 61mbps (ordinarily around 53mbps)... once everyone else came online my SNR was 0.8dB - clearly unsustainable, but no errored seconds!
Your line displayed the expected crosstalk behaviour, see on the graph below we can see the brief red dot where you sync'd with 6dB. Look how at that time, correspondingly your max attainable went higher. Then as you dropped down to 4dB, your max attainable also went down.
Newts didnt do that - his max attainable went up and stayed up at the record high, despite only having 3dB of snrm.
----
PS another example
Someone the other week suggested that Eric's line had 3db, yet when I looked at his stats at the time of resync, I could see when zooming in, that his line also dipped after a very brief spike and the max attainable corresponded with the lower snrm.
Its why I said at the time (http://forum.kitz.co.uk/index.php/topic,17356.msg317965/topicseen.html#msg317965) that I thought erics was not 3dB and him more likely doing a quick resync before his disturber.
-
I may be wrong, and I haven't got the time just now ...... but I'm sure I've read that some of the 3dB trials would initially only be for a 24hr period ? Don't know if this has been mentioned elsewhere, but would account for the sudden presence and loss of the 3dB profile ??
-
[I started writing this yesterday afternoon. It is written in the context of *not* having done the resync around 9pm yesterday; I'll cover that separately later]
I couldn't respond any further over the weekend, but it seems well worthwhile to have allowed some time for @NS' stats to accumulate. They are interesting.
Here's my analysis, ordered from cause, through direct effect, to indirect effect.
1. What Target?
The initial resync shows SNRM of 3dB for both upstream and downstream, suggesting that is the target.
2. Actual SNRM In Practice
Actual downstream SNRM rises from the starting point of 3dB to around 3.6dB later on Friday, but that kind of increase (0.6dB) seems to match the usual kind of improvement gained between 00:30 and mid-daytime - even before the resync.
Because @NS's SNRM cycles predictably each day, the speed achieved and the SNRM witnessed depends very much on the exact time of day that the resync happens.
We can see the "before" range was around 5dB-6.3dB, while the "after" range is now around 2.2dB-3.6dB. The difference turns out to be about 2.7dB, and has bought a speed improvement of 4.5mbps.
3. Raw FEC Rates
We see a marked increase in the FEC error rate - i.e. errors that were small enough they could be corrected.
This increase in FEC seems to occur very much in patterns, synchronised to the daily decline in SNRM: a wide spike from 4pm to 6am, with the worst being around 9pm. Notably, FECs seem to happen much more readily when SNRM declines below 3dB, even a little, while they stay relatively consistent when just above 3dB.
This might point out a useful rule-of-thumb: that we don't really want the line to drop below 3dB at any time; as @NS' line varies by around 1dB daily, this line might benefit from being on a 4dB target, so worst case never goes below 3dB.
4. G.INP Retransmission Usage
Errors that can't be handled by FEC get bumped into the retransmission mechanism.
In @NS' case, I think we can see a general increase in the "Retransmission TX" counts since the resync, but we don't see anything like the wide spike from 4pm to 6am that we see in the FECs ... suggesting that the FEC process has been very effective.
The other retransmission counts (Corr and Uncorr) tell us that the retransmission process is largely working - with just a few spikes in Uncorr.
5. CRC Errors
Errors that can't be handled by retransmission become CRC errors
The CRC graph doesn't show anything untoward has happened at all - a great result
6. Latency/Jitter
One outcome of additional retransmission would be the impact on latency: in particular, the increase in jitter.
I can't see a graph for @NS on this, so it is hard to tell whether there was any marked difference in outcome.
7. MTBE
The ultimate outcome is: How stable is the line? What is the impact to MTBE?
This gets shown to us in the ES and LEFTRS graphs, and the good news is that there seems to be virtually nothing changed about these.
I think there is an additional measure used by BT: FECS (an MTBE measure for FEC, in a similar way to ES being used for CRC); SIN 498 tells us that it is mandatory for the modem to be able to report this to the DSLAM. Unfortunately, there seem to be almost no modems that report this value. However, I'm sure we'd see a serious difference in this graph, if it were available to us.
8. Conclusion
@NS's line responded very well to a 3dB target, with the only exception being the spiked increase in FEC when actual SNRM values fell below 3dB.
The general increase in FEC was slightly visible in increased re-transmission rates, but the large spikes weren't replicated.
I can see that, for pure speed purposes, the line would work well enough at a 3dB target, but I can't help that a 4dB target would be best here.
-
If it was a cross-talker then why did the max attainable go up and stay up?
Newtrons max attainable is the highest it has ever been, if it was an x-talker, then surely his max attainable would not have stayed so high once the disturber came back online?
I agree. It looked and felt like the proper response for a drop in the target SNRM.
For what it is worth, I'd have recommended the same action - though I'm really glad we left it running untouched for a few days first.
-
I may be wrong, and I haven't got the time just now ...... but I'm sure I've read that some of the 3dB trials would initially only be for a 24hr period ? Don't know if this has been mentioned elsewhere, but would account for the sudden presence and loss of the 3dB profile ??
Changing SNRM target for a line certainly has the possibility of introducing uncontrolled instability on a line - an outcome no-one would want. So the trial could have disastrous outcomes, for some people at least.
How do you mitigate against this happening? I could very much understand a trial that worked for a limited time, or was a one-shot event.
[Slight Aside:
In old-style DLM, we have all seen the behaviour where INP value is changed and a resync is triggered for it to take effect. In new-style DLM, we see cases where a new INP value takes effect post-sync (say from 49 to 50), but the resync wasn't triggered by DLM itself: the change happens after a resync by the user.
So we've seen that DLM can change settings, but not bother with a resync just yet.]
The trial could make use of this capability: When ready, set an SNRM target of 3dB, and force a resync. Then, 24 hours later, restore the SNRM target to 6dB, but don't force a resync. The new target would then become active whenever the line re-synced - whether triggered by DLM, user, or fault.
-
I'm assuming a margin change is the cause of the increase. The timing suggests it was a configuration change of some description and certainly not been at 67Mb for about 300 other subscribers on the node. Not monitoring the modem for right now so no idea about the exact margin.
It was not a margin change it appears.
I suspect planned work was being carried out on the DSLAM and it was reloaded. The outage was somewhat long for a resync.
The increased sync would've been due to my modem coming online before some of my many disturbers (~287 of them on one DSLAM, ~200-240 on the other).
I restarted my modem earlier and not only was there no 6dB profile, DLM responded to the restart by switching off G.inp and falling back to default 8ms delay downstream interleaved profile.
No matter. Will leave it be and let it do its thing.
I'm wondering about this, given that @NS' line removed the 3dB margin after a resync.
In your case, it certainly could be an "early sync" after maintenance, leading to a combination of a high speed/low (actual) margin, but the telling component will have been the attainable speed. Do you know what that was?
That low (actual) margin could then have resulted in an increased error rate, causing the DLM impact you saw - a switch to old-style interleaving+FEC with 8ms latency. The only thing missing from this conjecture is the automatic resync as a consequence of DLM actions - whereas you resync'ed manually, right?
Another explanation could be that DLM reset itself, back to the new-style default (no G.INP, and low interleaving downstream). Again, we're missing the automatic resync.
I then wonder if this is an "artifact" of the way BT were going about this trial - in line with @BlackSheep's post, and my conjecture above. Perhaps you *were* put onto a 3dB target for a while, but DLM left a "fallback configuration" that was equivalent to a DLM reset, just in case your line couldn't cope.
Then, when you manually resync'ed, your line fell back to this "couldn't cope" configuration.
How long was it between the automatic resync, and the subsequent manual one you performed?
-
How long was it between the automatic resync, and the subsequent manual one you performed?
It was up for 3 days 20 hours, should have left the modem alone until an automatic resync was initiated by DLM.
I would have thought a trial would last much longer that this if you were selected it should take into account manual resyncs be it the user or DLM actions or even say power failures, if that is the way Openreach conduct their trials then they are not getting the full picture on end-users lines.
-
Looks like I may have been moved onto 3db profile - I wonder if it is still a short term trial or whether it will stay... time will tell.
My line with uptime of > 90 days dropped last night for over 5 minutes - dsl light went off on the modem.
It came back as per attachment.
-
My works connection resynced at 1am this morning, but the downstream synced at 5db, which gives me the max of 40 Mbps for the package we're on, upstream stayed at 6db but the speed improved. Stats are on MDWS under Ronskiwork.
No idea of this is related, but just seems odd to sync at 5 instead of 6.
-
I presume that was a typo in the last sentence. One possibility is that a 3 dB target has been applied and it ended up with 5 dB because it's capped at 40 Mbps.
-
Those who are on the 3db, are you all on the HG612?
-
I have an HG612.
-
Looks like I may have been moved onto 3db profile - I wonder if it is still a short term trial or whether it will stay... time will tell.
It looks like the downstream target has been set to below 6dB, for sure. Below 5dB is very likely. Hard to tell whether it has been set to 3dB or 4dB, when current SNRM is running at 4.5dB.
The reason it is hard to tell? The downstream speed has risen to 60Mbps, with an attainable of 63Mbps. That difference of 3Mbps perhaps represents just 1dB of margin ... suggesting a real target of 3.5dB. For reference, your actual speed rose by roughly 3Mbps too, and actual SNRM has dropped from 5.5dB before the resync to 4.5dB after the resync - a further confirmation.
The downstream speed has risen to exactly 60Mbps, and the upstream to a whisker shy of 17Mbps. It looks like you have been banded at speeds of 60/17 ... but it is impossible to know when those were put in place.
Upstream, however, does look like a 3dB target has been used. Your actual/banded speed is still well short of the attainable speed, but the picture gets muddied on upstream by the dynamic upstream power-backoff mechanism.
Now to look at the effect of this...
The underlying FEC rate seems to have increased, but there seems to have been very little change in the impact to retransmissions or to CRCs. Perhaps we shouldn't be surprised ... even though the target SNRM might have changed by 3dB, other factors mean your actual SNRM has only changed by 1dB.
NB:
You had a big burst of CRCs in the afternoon before the change, surrounded by a longer period of FECs. There was some noise source around then that doesn't appear in the days beforehand. Whatever happened, it doesn't look like it was enough to trigger a DLM intervention of any form.
-
I presume that was a typo in the last sentence. One possibility is that a 3 dB target has been applied and it ended up with 5 dB because it's capped at 40 Mbps.
Yes, it was a typo, corrected now thanks. Could well be, attainable is 47, but we are interleaved.
I'm using an HG612 here at work.
-
My works connection resynced at 1am this morning, but the downstream synced at 5db, which gives me the max of 40 Mbps for the package we're on, upstream stayed at 6db but the speed improved. Stats are on MDWS under Ronskiwork.
Most of what I wrote for @garypower applies to you too, except you don't appear to have banding - but the package limit of 40Mbps cuts in instead, and has the same effect of a higher SNRM than target.
If a 3dB target was being used, then the 2dB you have "spare" ought to be worth around 4-5Mbps, by my rule-of-thumb reckoning. However, your attainable is currently 8Mbps above the actual speed. I think the difference comes down to the fact old-style FEC+interleaving is in place, where the attainable is artificially high.
In terms of errors, your line is reacting in a similar way too: More FECs, but not notably more CRCs or ES's. But, strangely, I see the same thing on your line as @garypowers from yesterday: a bigger burst of FECs and CRCs. A coincidence? Some kind of cause/effect going on?
-
NB:
You had a big burst of CRCs in the afternoon before the change, surrounded by a longer period of FECs. There was some noise source around then that doesn't appear in the days beforehand. Whatever happened, it doesn't look like it was enough to trigger a DLM intervention of any form.
Thanks for the analysis - the burst of CRC's seem to coincide with the time of large thunder / lightening storms and lots of rain.
I can not think of anything else running in the house that is not usually on.
-
There was also thunderstorms near us yesterday to.
-
HG612
Seems like the upstream maybe not on a 6dB profile anymore?
-
Considering your uptime is 54 days, it's quite possible that the SNR has just drifted down overtime.
Edit. Although 54 days does take us back to the beginning of April, which is when NS started this thread, really need to know what your SNR was at time of resync.
-
The upstream SNRM seems to have settled on 3db now - the downstream still at 4.3
I assume this is because of what looks like some banding set from a previous time.
I seem to remember 60000, 16999 from a long time ago before crosstalk dragged me well under these figures.
I wonder if this banding will remove itself at some point as the upstream looks like it can take some more and the downstream as well if it was allowed to go to 3db.
[Moderator edited to fix the typo. (upstream --> downstream)]
-
A week on, I've just gone back to check @garypower and @Ronskiwork's lines.
Both appear to be continuing as they were set up back then, with error rates continuing as was visible initially. Things look reasonable...
-
On the trial the new SNR margins can be 3, 4 or 5dB. It isn't just 3dB.
-
On the trial the new SNR margins can be 3, 4 or 5dB. It isn't just 3dB.
If this is a 3dB trial don't reboot the modem ;)
-
If this is a 3dB trial don't reboot the modem ;)
I don't know if this is still a trial to be honest. But I do know what I said above was correct for the trial.
-
Any more news on the trial itself? Is it going to be rolled out to more lines eventually?
-
What was the SNRM at resync?
-
My line appears to have recently (about a week ago) switched onto a 3db profile - it's added about 4Mbs DS sync speed. Given it's a pretty slow line its really pleasing and I'm not risking a resync at the moment.
-
Recently noticed my line a few Mbits faster so looked at the stats, which I don't normally monitor unless I have line issues.
I'm on a 40/20 product on a Broadcom cabinet with G.INP enabled and was originally synced at around 36-37Mbit on the standard 6dB target, as I'm approx 500M away from the cabinet and my line has some aluminium in it along the way.
Now though I have maxed out DS sync at 39,999 and my SNR is now 4.6dB and the sync has been up now for over 4 days. As I've hit the sync limit for my product, I'm unsure what my target is now set to.
There was no cabinet-wide outage to cause this, as other lines connected to the same cabinet have stayed up for weeks.
-
40/20 product? Plusnet's 40/20 product did not restrict the sync speed, and won't exist for much longer anyway (they should have already migrated you to 55/10, or are currently in the process of switching everyone on 40/20 to 55/10).
-
So far my 3db target SNR has survived a month, including a coupe of reboots.
-
So far my 3db target SNR has survived a month, including a coupe of reboots.
what modem are you using, and are you holding to MDWS? if not, is it possible you could? I'm yet to see anyone keep 3dB after a resync
-
Bad new for me - modem lost connection just after 11pm today.
It seems I have been resync'd at 6db :(
62 days uptime with increased download & upload. It is the upload I will miss the most !
Is it likely to be worth contacting the ISP to see if I can be put back @ 3db?
-
Mine is back to 6db now too :-(
Successful test though, just need it implemented for real.
-
Bad new for me - modem lost connection just after 11pm today.
It seems I have been resync'd at 6db :(
62 days uptime with increased download & upload. It is the upload I will miss the most !
Is it likely to be worth contacting the ISP to see if I can be put back @ 3db?
Did your attainable rate increase with this 3dB trial ?
-
Very much so.. was great while it lasted!
See if you can spot when it started and when it reverted from the screenshot ;-)
-
So, is this actually a 'thing' or just being trialled?
-
BTW, I'm on 3 dB downstream target SNRM (but on ADSL2), as you may recall.
-
From R3350 EIP2 (delivery 21 January 2017) (https://www.openreach.co.uk/orpg/home/updates/eipcommunications/eipcommunications.do)
OR-32420 GEA-FTTC XdB
Strategic development of DLM system to allow reduction in
target margin on new and existing GEA-FTTC lines
So the 3dB (or some value lower than the current 6dB) target SNRM for FTTC might be deployed towards the end of January 2017.
-
Does ”strategic" mean a limited deployment or does it mean a full deployment and DLM will intervene if 3db is too low?
-
I think there's only one DLM system. I assume it would work in the same way as the ADSL2+ DLM, in that the target SNRM would start at the default of 6 dB, and thereafter the DLM might lower the target SNRM if it determines the line is operating sufficiently well (ILQ green).
I didn't think they were going to lower the target SNRM on every FTTC line, then have the DLM put it back up if necessary on some lines. I suppose it depends on how you read the "on new and existing GEA-FTTC lines" part.
-
BT SIN 498 7.2a (http://www.btplc.com/sinet/SINs/index.htm) was recently published, apparently it says publishing extracts is not allowed, otherwise I'd quote the paragraph in the recently added section 1.2.2 about downstream target SNRM.
It says that starting in March 2017, the DLM will select a downstream target SNRM of 3, 4, 5 or 6 dB, determined by how stable the line is.
-
Thanks ejs good spot.
:thumbs:
>> I'd quote the paragraph in the recently added section 1.2.2 about downstream target SNRM.
BT dont usually mind you quoting short extracts from SINET as long as you quote the original source where you got the info from.
What they do take umbrage at is copying huge walls of text and not accrediting where you got the info from.
Copyright law states excerpts are allowed in the following circumstances
1. The reason for using the material is genuinely for the purpose of quotation, criticism or review
2. The material you are using is already available to the public
3. Your use of the material is fair
4. Where practical, you have provided sufficient acknowledgement
5. Your quotation must be no more than is required to achieve your purpose
See also copyright legislation section 30 (http://www.legislation.gov.uk/ukpga/1988/48/section/30) - Criticism, review and news reporting.
I think they'd have a hard time chasing someone using it to prove a point or explain something... or as in this particular case it would be covered by 'news'. If they got really arsey they could ask you to remove the quote if it wasn't relevant.
-
BT SIN 498 7.2a (http://www.btplc.com/sinet/SINs/index.htm) was recently published, apparently it says publishing extracts is not allowed, otherwise I'd quote the paragraph in the recently added section 1.2.2 about downstream target SNRM.
It says that starting in March 2017, the DLM will select a downstream target SNRM of 3, 4, 5 or 6 dB, determined by how stable the line is.
Any information on if this will apply to both cabinet types? Does ECI Ginp get a mention? :crossfingers: Thanks
-
IF the trials go well I was told april 2017 before we see g.inp on eci..
-
Thanks ejs. For some reason I missed your post about the EIP otherwise I may have picked up on this sooner.
I think this is a newsworthy article that some people have been waiting for - link (http://forum.kitz.co.uk/index.php/topic,18933.0.html). :clap:
-
Don't know about this FTTC 3dB - 6dB Target SNRm it seems to late to recover what users have lost due to crosstalk as some have lost upto 20Mbps so even with a 3dB SNRm profile it won't gain back all that was lost but it's a bonus and the 4 month wait is good if its true :)
-
I've been doing pretty well with 3dB downstream target SNRM on ADSL2, no errored seconds at all most of the time, as far as I recall, and can hold on to the connection for many days or even weeks. One interesting thing is that the dienstream SNRM often starts off well below 3dB, for some reason, or else drops well below it quickly and then hangs around at say 1.5 dB for a long while, but then end s up down around 0.3 - 0.8 dB.
The speed improvement isn't huge compared with a (supposed) 6dB target, a hundred Kbps or so on a ~2.6 Mbps downstream sync rate line. Part of the reason seems to be due to the fact that the 6 dB _target_ can easily end up as an actual SNRM which is a lot lower than that, so the gap we’re actually dealing with in the comparison is often something more like (~3dB - 1.5dB) not 6dB - 3dB
-
if it does apply for ECI then I would imagine without g.inp the amount of lines getting a lower snrm will be very limited. But hopefully ECI will be getting g.inp next march/april.
I hope if a line is lowered to 3db and then gets a red status in errors, the snrm would be bumped back up in preference to interleaving.
-
BT dont usually mind you quoting short extracts from SINET as long as you quote the original source where you got the info from.
I see that ISPr have quoted it in their news article.
-
Don't know about this FTTC 3dB - 6dB Target SNRm it seems to late to recover what users have lost due to crosstalk as some have lost upto 20Mbps so even with a 3dB SNRm profile it won't gain back all that was lost but it's a bonus and the 4 month wait is good if its true :)
It wont ever mitigate anything lost from crosstalk. But it helps.
Ive now lost over 30Mbps from my headline speed. The 20Mbps average was a figure I quoted about 18 months ago.. at that time my own headline loss was running at about 24Mbps.
In answer to the question about ECI cabs, the trial was both Huawei and ECI so I would think it would be rolled out on both.
-
>> ve now lost over 30Mbps from my headline speed.
Probably more... just looked at my stats, line is still playing up and spiking. (link (http://forum.kitz.co.uk/index.php/topic,18830.0.html)). If I did a resync now, my net loss would be 35Mbps.
I noticed a BT OR engineer next door yesterday morning, since then Ive lost another 1dB. :/
-
Given that fast path estimates by the hg612 seem to be fairly accurate (its interleaving where the attainable is whacky), my line originally could do 110mbit on my original pair. It eventually settled in the high 60s so over 40mbit loss, before plumetting below 50 causing me to get a new pair, the new pair was stable at 71-73 for quite a long time, over a year, but in the past 6 weeks has had multiple drops and is now down to just over 66 attainable.
A 3db profile would get me up to about 77 I guess, would have been the full 80 if not for the extra crosstalk in past 6 weeks.
But remember that currently ECI has no g.inp so lines qualifying for the 3db target wont be a lot I think.
Ironically before my original pair plummeted to 50 I was synced at over 70mbit on a low margin, this actually saved me because it meant the loss of speed exceeded the 25% criteria to get marked as a GEA fault.
-
Trying to work this out if your crosstalker was set to 3dB and your line was set to 6dB would that cause more crosstalk as when a crosstalker gains more sync this has an effect on the effected line by lowering their SNRm and lowering the Attainable sync.
To me it looks as if the 3dB target margin would cause more crosstalker wars :-\
-
no its power output that causes crosstalk not sync speed or snrm target the dsl signal strength is same but a lower target snrm simply means less of it is allocated as a buffer against errors
-
Thanks Chry for helping me understand crosstalk a bit better I do see slight changes on the power output on the modem during a modem reboot the DS power can change by 0.3 the US can change by 1.0, so I wonder how much our crosstalkers power fluctuates.
-
It's being reported that the nationwide rollout of the lower target SNR of 3db on Infinity VDSL will be in March.
Is there a set date for this or will it happen in stages over the month?
There are also conflicting reports as to whether ECI cabinets will be included in the March rollout.
Anyone got definitive news on this?
-
Cant see ECI getting the new snr profiles without G.INP..
-
http://www.btplc.com/sinet/SINs/pdf/498v7p3.pdf
Page 8, section 1.2.2
1.2.2 VDSL2 noise margins Currently the default target downstream noise margin is set to 6dB. From March 2017 the target downstream noise margin shall be set to either 3, 4, 5 or 6dB – the actual value shall be determined by the Dynamic Line Management (DLM) algorithm based on line stability.
No further info than March unfortunately.
ECI DSLAM's are not getting the new xdB target SNRM (http://www.ispreview.co.uk/index.php/2017/02/bt-update-uk-fttp-sogea-3db-21cn-wbc-broadband-plans.html)
-
Hehe. Seeing this thread's subject line pop up in the Unread Posts page made me think it had gone live now :) Not long to wait, though.
A quick question: A while back, my HG612 resync'd quickly after a local power cut and I got in before other crosstalkers. My sync rate was in the high 57's - a good 7-8MBit higher than usual. During that time, my SNRM was around 3-4dB and, although higher than normal, my ES and SES rates were nothing to worry about.
Is that a good estimation of what my line would be like if I were to have a 3dB profile assigned?
(I hope so. It was speedy!)
Chris
-
I guess it would be a good estimate once you get to this magic target SNRM of 3dB of course it will start at 5db then 4dB and finally 3dB and your SNRM looks quite steady and see no issues there when this new automatic SNRM is rolled out.
Just taking a guess if and when it arrives on my circuit my own SNRM changes quite a bit over 24 hours so 4dB would be the minimum the DLM will allow, of course we will not know until it's fully rolled out and it's just a trial at the moment ;)
-
Looks like DLM put me on a 3db margin last night. My exchange was NOT included in the trials.
I've gained 15mb on the downstream, but unfortunatley G-INP in still not activated, even though it is enabled at my cab, so ES are going through the roof.
-
Could you
Looks like DLM put me on a 3db margin last night. My exchange was NOT included in the trials.
Could you say what part of the country/exchange you are on?
-
I'm off https://www.samknows.com/broadband/exchange/WNROS
-
Looks like DLM put me on a 3db margin last night. My exchange was NOT included in the trials.
I've gained 15mb on the downstream, but unfortunatley G-INP in still not activated, even though it is enabled at my cab, so ES are going through the roof.
Looks like something else caused this. The upstream has also dropped by 3dB from 15dB to 12dB.
All the examples we've seen so far also drop in stages. From 6dB to 5dB to 4dB then finally 3dB. The upstream should remain static.
This thread is the perfect example of lots of wrong assumptions that they are on a 3dB target SNRM. Half the thread is ECI users who are excluded, and the other half were before the trial even started. There's 101 reasons that can cause a line to resync at a lower SNRM.
-
yes it might not be due to reduced target margin, but it is the only thing I can find to explain the drop in SNR and the quite large increase in max attainable (and therefore actual sync too).
I guess the DLM is going to do something tonight (loads of ES and ~2% packet loss). Might know more tomorrow......
-
Actually, the QLN graph from HG612 modem stats shows a very odd and quiet line
-
Actually, the QLN graph from HG612 modem stats shows a very odd and quiet line
Yuck is all I can say. :yuck:
Very odd. I would like to be able to explain what we are seeing . . . but I am unable to do so.
Am I correct in believing your G.993.2 service terminates on a (cabinet installed) Huawei MSAN?
-
Indeed that's a huge difference from your usual QLN on MDWS. Possibly a crosstalker is offline or has ceased their service.
Vectoring can also cause such symptoms, particularly the better use of bits/tone in D1 and D2. Less likely but worth checking the vectoring state anyway.
-
yes my service terminates at cabinet - Huawei MSAN, some 270m away.
Vectoring is not enabled.
I thought maybe it was a power cycle at the cab and then me be one of the first to sync, but wouldn't the max attainable drop back to what it was previously (or there abouts).
I need to compare actual QLN values direct from the modem to see which stats app is correct, DslStats and HG612 stats look very different even though I think they are meant to be based on "adsl info -qln"
I might have to resync manually before the DLM does, packet loss is becoming a problem as it is at the moment.
Edit: MDWS Quiet Line stats are incorrect, uploaded from DslStats, it is not showing current values from info --QLN, some example tones:
2000 -127.5000
2001 -127.5000
2002 -127.5000
2003 -127.5000
2004 -127.5000
2005 -127.5000
2006 -127.5000
2007 -127.5000
2008 -128.0000
2009 -128.0000
-
I thought maybe it was a power cycle at the cab and then me be one of the first to sync, but wouldn't the max attainable drop back to what it was previously (or there abouts).
Yes, that's the usual behaviour. The upstream SNRM dropping 3dB at the same time suggests it's neither a simple DSLAM reboot or a lower downstream SNRM target set by DLM.
A before and after QLN might help work out what it is, we may never know though. A missing crosstalker or a physical change (improvement) to the line are just 2 of the umpteen possible causes. There's no change in attenuation or reported power levels either so it certainly leaves one scratching their head as to what has occurred.
-
Just rebooted the modem and it's back to 6db and normal looking QLN, hopefully lower ES and packet loss too!
It's got to be a power cycle at the MSAN, incorrectly working out bit loading based on QLN before anyone else tried to sync (or before most people anyway).
-
Yuck is all I can say. :yuck:
The above comment was based solely on sight of the QLN plot. The DS bands had become very "deep" (in a vertical sense) whilst the US1 (or was it the US2?) appeared to have a sine wave superimposed upon it.
I never looked at any of the other plots or data . . . so I shall have to rely on j0hn's analysis. :)
-
I had a remote-triggered resync (RDI) early this morning at 00:58. First one I've ever seen.
Perhaps it was the cab being updated with the new DLM settings? One can only hope!
(I'm on the Gravesend exchange, which I stubbornly refuse to call by it's new 'Ebbsfleet' name. Ebbsfleet's not even a real place -- it's just a roundabout and a train station. Grrr.)
[edit] I should probably add that my target SNRM is still currently showing as 6.0. After the resync I gained a handful of kilobits in either direction, 1.5Mbit DS above my reported attainable, which is normal for the line -- it always syncs a bit quicker that it says it can!
-
I had an RDI today at 00:58 too. Over the last few days I've been watching my downstream SNRM stepping downwards in 1dB increments, 6.4, 5.4, 4.4 but instead of 3.4 it dropped to 1.8dB. That seemed strange but I was surprised to see my upstream drop by about 2dB along side it. No idea what this signifies.
attached image from MyDSLWebStats for easy reference.
EDIT: Rebooted the modem and SNRM is back at 4.4dB. I guess my modem went a little wonky during a DSLAM reboot. Bad modem, bad!
-
Looking at the "small print" in the upper section of your SNRM plot, I see that the synchronisation speed is (essentially) 80/20 Mbps DS/US. I would not expect to see much of a fall in terms of the SNRM value purely because you are at the upper limit (synchronisation speed) for the product.
Any SNRM below 3 dB should be regarded with suspicion. If such a state is maintained, I would predict that a remote (DSLAM) initiated re-train of the G.993.2 link will eventually occur.
Without studying your circuit's previous history, I shall assume that a 4 dB target SNRM will be the preferred minimum.
-
Oooo.
Fingers crossed that I see an SNRM drop overnight tonight! My line's reasonably well-behaved. No SESes and only a handful of ESes every day, and the SNRM hovers around .5dB of the target most of the time.
Let's hope the DLM God (I call him 'delemicus') has recognised my line's piousness.
-
BigJ your line is a 100% perfect example of the new xdB DLM target SNRM. It shows every characteristic I would expect to see.
1st is that only the downstream is affected. Upstream will show the usual slight variation but should remain roughly the same.
2nd is that the line doesn't jump straight to 3dB. Every example I've seen show the line should drop in 1dB stages.
3rd is that the max attainable rises with the drop in target SNRM.
With a lower SNRM caused by a DSLAM reboot it usually affects both downstream/upstream. The max attainable usually drops back down after all your crosstalkers reconnect. It also doesn't go 1dB intervals.
Your line appears to be on a 4dB target SNRM at the moment. If DLM considers that your line is coping with the current target then I would expect the line to resync either tomorrow or the 16th between 7-8am with a 3dB target. Let's see if that prediction comes to be ;)
-
Thanks for the info guys. I'm slowly starting to get a grip on how this all works.
Hope Delemicus answers your prayers displaced :fingers: Great name by the way :)
Hmmm, I'll take a punt on it dropping to 3 tomorrow!
EDIT: spelling. removed question about exchange as displaced answered it already.
-
I see you're not using the "default" HG612 ;)
-
I see that the synchronisation speed is (essentially) 80/20 Mbps DS/US. I would not expect to see much of a fall in terms of the SNRM value purely because you are at the upper limit (synchronisation speed) for the product.
Looking at the full process on MDWS, it looks like the line only reached 80/20 speeds because of the final event in the sequence - jumping from 65/20, to 69/20, to 72/20, and finally to 80/20.
The first two look like bona-fide steps in the 5-4-3dB process, but the 3rd looks like an unfortunate DSLAM reset. A close zoom into the SNRM graph shows the first reading after that resync is at 4.9dB at 01:00. 1 minute later, it has dropped to 1.7dB. The knock-on effect is obvious: A massive increase in FEC rates, which fortunately didn't translate into many retransmissions or CRCs. Thankfully, this was stopped by the manual resync back to 4.4dB.
This event likely shows the biggest risk to the 5-4-3dB process: A DSLAM reset can easily knock 3dB lines out of any decent behaviour - but hopefully it gets seens as a "wide area event".
-
Thank you for the insightful comment. As suggested, could this odd behaviour be explained by me using a Billion 8900AX instead of a HG612? The HG612 is just more resilient.
Also, if I hadn't done a manual modem reboot, would DLM have eventually noticed the SNRM was way off target and triggered a re-sync?
-
I'm using an 8800NL (v1) which works as well as the HG612. I think the v2 works better, and I wouldn't expect the 8900AX to be any worse.
It is hard to say how DLM would have reacted, as this is all new behaviour. The old DLM would tend to only react to the error rates, rather than SNRM values. The high FEC rate wouldn't have affected the old DLM decisions, but it could play a part in the 5-4-3dB decision-making.
I see your line looks to have jumped to a new setting today, at 3.5dB. Sync is 76Mbps, a gain of 10Mbps overall.
The progression (ignoring the blip) has been 66, 69, 72, 76Mbps with SNRMs of 6.4, 5.4, 4.4, 3.5dB.
Those are in line with what I'd expect.
-
Sadly, no SNRM drop for me, yet. Perhaps it'll just take a while longer to kick in, or maybe my line's performance doesn't match some criteria I'm not aware of.
Oh well!
-
True, we are in new territory now. Hopefully my line will stay nice and stable at the new 3.5 SNRM though I'm not going to complain if it needs to go up a little :)
-
As the 3dB is now going national I have two questions:
1. Are lines that are at the maximum sync for their service ub scope? For instance, I am on a 55/10 service but my attainable is 60/20, will DLM lower my target SNRM (assuming the line is stable) to produce a higher attainable figure?
2. Obviously, the big beneficiaries are those closer to the cabinet, but do those further away benefit "by default" if those closer are now running with a lower SNRM target (does it make their signal strength 'stronger' even if their own SNRM target doesn't change) ?
-
In theory, I suppose it would be the opposite. Running at a lower target SNRM could allow the same line rate at a lower power output, and so with lower power output, there would be less crosstalk. Relatively speaking, the crosstalk reduction would benefit shorter lines more than it benefits longer lines.
Of course, the answers to your questions are: I don't actually know, you'll have to wait and see.
-
This probably has been answered already;
Will this rollout be for ECI too? I'm unfortunately on an ECI cab. :-\
-
probably not as I expect g.inp is considered a requirement.
-
Oh dear, thanks for answering. :)
-
This probably has been answered already;
Will this rollout be for ECI too? I'm unfortunately on an ECI cab. :-\
Openreach has confirmed to ISPreview.co.uk that the roll-out is still due to commence this month as planned (phased roll-out) and some updated performance data from their extended trial is due to be shared with ISPs over the next couple of weeks.
We also asked whether ECI based VDSL2 DSLAMS (Street Cabinets) would continue to be excluded from the roll-out (as first reported here) and they confirmed that the enhancement will only be applied to Huawei based DSLAMS. ECI kit has become notorious for causing problems with various VDSL2 enhancements and changes.
Remember, not everybody will benefit from the new SNR profiles and Openreach’s DLM technology won’t apply the lower margin(s) unless your line is deemed likely to benefit.
[Moderator edited to add an attribution to the quotation.]
-
1. Are lines that are at the maximum sync for their service ub scope? For instance, I am on a 55/10 service but my attainable is 60/20, will DLM lower my target SNRM (assuming the line is stable) to produce a higher attainable figure?
2. Obviously, the big beneficiaries are those closer to the cabinet, but do those further away benefit "by default" if those closer are now running with a lower SNRM target (does it make their signal strength 'stronger' even if their own SNRM target doesn't change) ?
1. We don't know. I haven't seen one happen, nor seen discussion about it anywhere.
2. It seems unlikely. SNRM values, by themselves, don't alter the signal strength nor the amount of crosstalk inflicted on other lines. The only difference i can think of is when some extra tones get added into the medley because they are now viable. But that would require the modem to shift some bits off a high-bit-count tone onto a low bit-count one, and I don't know that it would happen. If it does, then the impact will be additional crosstalk on the new tones.
What @ejs says ...
In theory, I suppose it would be the opposite. Running at a lower target SNRM could allow the same line rate at a lower power output, and so with lower power output, there would be less crosstalk. Relatively speaking, the crosstalk reduction would benefit shorter lines more than it benefits longer lines.
... is a possibility, but I thought the aim at the DSLAM was to transmit every tone at the same power on every line, to spread crosstalk evenly (different tones can be different power, but still the same power on every line).
In theory, though, it would be possible to allow an "over-provisioned" line to use lower power; just low enough (once extra crosstalk inwards is allowed for) to drop the attainable speed to the package speed. That lower power would, in turn, reduce crosstalk outward to other lines. Reducing power is mentioned in DSM guides as an option, but I don't think I've seen it mentioned for quite such a dynamic case. The case when a new disturber gets added would cause a headache on deciding whether to increase power.
Upstream power backoff does allow lines to use different power upstream ... so different target SNRMs could have an effect there. However, this 5-4-3dB change appears to be only downstream.
-
Modems are supposed to take the Target SNRm into account when they calculate the attainable rate.
-
We had a big discussion about this on the thinkbroadband forum (http://forums.thinkbroadband.com/fibre/t/4528281-openreach-to-rollout-3db-target-snrm-for-fttc-next-year.html)
I was arguing that the maxattainable uses the actual target SNRM. MrSaffron and Robertos seemed to think modems use a fixed 6dB in all cases. WWWombat seemed to clear it up linking to VDSL2 specs showing 3 possible ways a modem can work out maxattainable. All 3 ways use a variable target, backing up my argument.
As the trial has gone on that point is now beyond debate. The maxattainable clearly rises as the SNRM drops each time.
edit: tag fail
-
Mr Saffron seems to have zero technical knowledge, I think he is just an employed/contracted journalist on that site.
-
WWWombat seemed to clear it up linking to VDSL2 specs showing 3 possible ways a modem can work out maxattainable. All 3 ways use a variable target, backing up my argument.
I'll just add...
As a software engineer, whose job has been to interpret & implement specs like this, I will say that shortcuts can be taken during development, and things that ought to be variable can get hard-coded. With the intention to come back and fix it, of course ;)
Trouble-shooting is the art of checking what the system is actually doing, rather than what you think it ought to have done. Spoken as the proud creator of hundreds of bugs :-[
-
I was arguing that the maxattainable uses the actual target SNRM. MrSaffron and Robertos seemed to think modems use a fixed 6dB in all cases.
Never saw that - its been a while since read anything on TBB otherwise I could have said something earlier to point you in the direction of ITU standards to back up your claim.
I already knew that it is uses the target SNRm from when I attempted to do a bit of digging a few years ago to see if there was any clue why max attainable went so skewy when Interleave (or rather INP) was applied to the line.
I'm still none the wiser why INP causes the discrepancy. I assume that most of the modem stats we see on here use the basic method (in fact I can't even recall there being a choice of methods at the time I looked). I'm also assuming that because most of the stats we do see tend to come from BCM chipsets then it could be down to the way that BCM interpreted the original recommendation.
I note the latest version of ITU G.993.2 says
The conditions of the basic method in this version of the Recommendation are unchanged compared to the conditions for ATTNDR calculation in previous versions of this Recommendation. This set of conditions did not specify a number of conditions to calculate ATTNDR, which lead to vendor discretionary behaviour in the reported ATTNDR values.
Looking at an archived version, which was the pre-published version of these changes relating to the max attainable rate was dated 05/2015 (amendment 6). Most of us here are used to seeing stats from the HG612/Zyxels/Billions all of which were around before that date.
I will say that shortcuts can be taken during development, and things that ought to be variable can get hard-coded.
Im talking about the BCM based modems that most of us use, but with this stat being part of the standard BCM commands then I would think its unlikely as we see enough movement of SNRm and target SNRm for it to be fairly accurate on lines which dont have INP. These modems are also used on adsl lines and with other SPs which have had variable target SNR (both more than and less than 6dB) long before Openreach decided to apply it. It only appears to go pete tong when INP is applied.
I dont know here and perhaps ejs may have some thoughts, but the other important figure used is SNRGAP. ITU states
The SNRGAP value is defined for a 10−7 bit error ratio on 4-QAM (no coding gain, INP_min0 = 0).
Is it something to do with the use of INP=0 in the calculation when say INP 3 is applied to the line which is throwing the figures out. Whatever way the figures that Ive noticed always seem to over compensate by about double what they should be.
The modem has to calculate a [true] SNRGAP to get the actual sync speed which will be calculated using any existing DLM params. Therefore is it possible that BCM is using the actual SNRGAP figure rather than one with INP=0 in the ATTNDR calculation that is throwing the figures out for interleaved lines.
-
In the ITU G.993.2 document, that SNRGAP term only appears in the ATTNDR formula for use when the modem is in "loop diagnostic mode". So it's for when the modem is in a special diagnostic mode, not actually trained up. Normally the ATTNDR wouldn't need to be calculated that way.
With the basic ATTNDR method, the modem is free to choose the amount of FEC data, interleaving depth and other framing parameters for maximum bandwidth (within the maximum delay). Whereas for the actual line rate, it will have to set the amount of FEC data, interleaving depth and other framing parameters to achieve the required minimum INP value specified.
Last time this was discussed, I think I had difficultly explaining or convincing people about the "coding gain" aspect, that FEC+interleaving could be used to give a higher net data rate than without. I'll try explaining it again.
The modem connects at the best speed it can constrained by having to meet the error rate (and target SNRM, but SNRM is defined relative to the error rate).
So when you add error correction capabilities, that would lower the expected error rate, therefore allow a greater bandwidth to be achieved for the same error rate. That's the coding gain.
Of course the FEC data takes up some of the bandwidth, which has to be taken into account to give the net data rate. But it's possible to gain more than you lose.
It was easier to see on ADSL2, when switching on FEC+interleaving can give you a higher net data rate than without.
-
I think we are singing from a similar hymn sheet.
ADSL has always used an 'SNRGAP' figure during the process of calculating bit allocation (http://www.kitz.co.uk/adsl/adsl_technology.htm#bit_allocation) and ultimately the sync speed. Its basically the difference between the SNR margin and the true SNR. It its simplistic form and in early days of DSL it covered an allowance for BER (http://www.kitz.co.uk/adsl/adsl_technology.htm#ber) of 10–7
A more recent definition (http://www.eurasip.org/Proceedings/Eusipco/Eusipco2016/papers/1570256496.pdf) of SNRGAP is
The signal-to-noise ratio (SNR) gap to capacity, or SNR gap
for short, is a function of the coding gain, noise margin and
target average BER
I do get what you are saying about coding gain and am not disputing that, it became apparent on some lines after G.INP.
Like you say it may also be apparent on ADSL2+ which was when INP was introduced.
-----------
What I was saying in my above post was... what if the reason why the ATTNDR calculation goes skewy on lines which have INP applied is because some modems are using the actual 'SNRGAP' figure calculated for bit allocation, rather than one with no coding gain and INP=0.
It would appear amendment 6 in 2015 to the ITU G.993.2 seeks to clarify that when calculating ATTNDR then you must use SNPGAP with BER 10-7, no coding gain & INP=0
If BCM was using the 'actual SNRGAP' figure for ATTNDR rather than the clarified baseline figure, then IMHO it is a highly possible reason why max attainable goes way out if the line has INP applied.
-
The paragraphs and formula referring to SNRGAP are the same in the 2011 edition of G.993.2 as they are in the 2015 edition of G.993.2, which includes whatever was in amendment 6.
What was added in the 2015 edition is the whole section with the improved attainable net data rate method. The improved method includes more conditions, including having to use the actual minimum INP requirement. It does not necessarily require INP=0 to be used, although that is an configurable option.
what if the reason why the ATTNDR calculation goes skewy on lines which have INP applied is because some modems are using the actual 'SNRGAP' figure calculated for bit allocation, rather than one with no coding gain and INP=0.
I'm not sure what you're saying makes sense. If the modem were using the actual SNRGAP figure to calculate the ATTNDR, the same as what it used for the actual bit allocation and the ACTNDR, then why would the ATTNDR become much higher than the ACTNDR? Surely an ATTNDR figure calculated using the actual parameters used on the line would give a value similar to the ACTNDR.
That bit about the SNRGAP=9.75 for the usual BER, no coding gain and INP=0 applies when the ATTNDR has to be calculated while in loop diagnostic mode. I think it's saying that's a less accurate method it has to use when in loop diagnostic mode, because the bits and gains table has not been calculated when entering loop diagnostic mode.
Edit: Now that I've managed to download Amd 6 (http://www.itu.int/rec/T-REC-G.993.2-201505-T!Amd6/en) to G.993.2 2011, it turns out that it has very little to do with ATTNDR at all (only inserting SNRM_MODE=5 in existing lists of SNRM_MODE numbers, one of which happens to be in the ATTNDR section). The improved ATTNDR calculation was in the 2011 edition of G.993.2, but support for it is optional.
-
Just had a re-sync on one of my lines (vic0239-2), SNRM now 4.3 ~4Mbps increase. And another as I type?
-
My line's stubbornly holding at 6dB +/- 0.3 dB. Booo! :)
-
My lines still on 9db!!! think its stuck
-
I was just about to create a ne wthread as my line has been doing some funny things lately but it could be this.
Firstly, G.INP was removed from my line for approx 1 week. I think errors were roughly 12/hour on an interleave level of 1/1.
A week later, It was re-applied then a few days later I had a DLM remote indicator 1 where my new sync was 2.4dB down and 6.4db up. I rebooted the router a few days later where it reverted to 6.3db down and 6.4db up. Just a few days ago, It had another DLM indicator 1 and it is now sitting at 4.3db down and 5.9db up. Gained a good chunk of speed and it seems happy with 0.06/6.5 ES/hour.
-
Just had a re-sync on one of my lines (vic0239-2), SNRM now 4.3 ~4Mbps increase. And another as I type?
Same again this morning with the other line. Errored seconds don't look too bad, so maybe DLM will be kind and offer me a little more. :)
-
Same here. Now sitting at 3.4db and a down sync rate of 73.6mbps
-
Re-sync today at 2 PM have dropped from 6db to 5db(been 6db for years), let see how it goes and if it drops to 4db in the coming weeks.
-
Have to say I'm apprehensive if this 6-3dB target goes live on my circuit for the extra wee bit of sync as it's not that important what is important is line stability and kind of know what my line is capable of and 6dB looks the best for me.
Have notice others saying it won't be active on lines who have stability issues and wondering what these are IE errored seconds or SNRM changes or retrains or all three
-
Further drop this morning:
Reason: 1 Remote Defect Indicator/DLM
Current Downstream Sync Rate is now 72806kbps @ 3.4db SNRM
Current Upstream Sync Rate is now 10491kbps @ 6.3db SNRM
-
Have to say I'm apprehensive if this 6-3dB target goes live on my circuit for the extra wee bit of sync as it's not that important what is important is line stability and kind of know what my line is capable of and 6dB looks the best for me.
In your case you know the typical, average, DS synchronisation speed that is obtained with a target 6 dB SNRM.
If it appears that the DLM process is experimenting on your circuit by dropping the target SNRM, then you could counteract that change by manually capping the DS synchronisation speed to what is currently obtained with the 6 dB target.
-
That is a good idea and for some reason forgot about manually capping the modem back to 6dB unsure what the DLM would make of it, MR N*STAR we the DSLAM sent you a target margin of 5 and then 4dB but for some reason your circuit is ignoring are commands :D
-
Looking at Vic's stats with my untrained eye, it seems reasonably similar to mine - slightly higher attenuation and roughly the same SNRM levels and hlog graphs. (Although your snrm's much smoother than mine - stats quantisation by the Zyxel modem perhaps?)
So I'm still holding out hope that I get an snrm drop sooner or later!
-
Looking at Vic's stats with my untrained eye, it seems reasonably similar to mine - slightly higher attenuation and roughly the same SNRM levels and hlog graphs. (Although your snrm's much smoother than mine - stats quantisation by the Zyxel modem perhaps?)
So I'm still holding out hope that I get an snrm drop sooner or later!
I thought the same. Probably a slow and measured roll out by BT.
-
Anyone know if the 3db will be applied to the up and down?
-
Anyone know if the 3db will be applied to the up and down?
Just downstream at the moment. In fact, the presence of upstream drops can used to figure out whether overall SNRM fall is due to DLM or just a fortunate resync. Noise-free fortunate resync will lower both, whilst a controlled DLM action will be downstream only.
-
Sorry for the running commentary. :-[
After a further re-sync this morning both my lines are now at 3.3db SNRM on the downstream, so I suppose that will be my new target completed after two interventions.
-
After a further re-sync this morning both my lines are now at 3.3db SNRM on the downstream, so I suppose that will be my new target completed after two interventions.
Yes, it certainly looks that way.
-
Yes, it certainly looks that way.
So, just to confirm, how much was the increase in downstream compared to db reduced?
-
My line rebooted just over 8 days ago (after ~ 74 days uptime)
Now holding @ 3.3 / 4.1db
Speed changed from 58,219 / 15,770 to 66,539 / 16,707
Interestingly the last time I went to a low snrm as part of the previous trial the download hit a banded 59,999 number = this has now been removed :)
-
So, just to confirm, how much was the increase in downstream compared to db reduced?
Over the three re-syncs:
SNRM db Attainable
Line 1 6.4 - 5.3 - 4.3 - 3.3 62,059 - 65,869 - 69,699 - 73,394
Line 2 5.9 - 5.3 - 4.3 - 3.3 60,552 - 62,430 - 66,558 - 69,649
I might be able to squeeze a little more from line 2 as it is affected by line 1 and was the last to re-sync.
-
Can you add the SNRM and speed from before the first step?
As it stands, we can only infer that a 2dB change gave each line about 7.4Mbps.
-
Apologies, for some reason I didn't go far enough back. :-[ I've updated accordingly.
-
Re-sync today at 2 PM have dropped from 6db to 5db(been 6db for years), let see how it goes and if it drops to 4db in the coming weeks.
Re-sync at 8AM today, down to 4db.
I'm 800 meters from the Cab(21.7dB attenuation) and have gone sync rate of @6db/46500 to 5db/48900 to 4db/52000.
To give you an idea of the gains.
-
This is good to know cheers!
I am also 800m from my cabinet, although i'm only on a 40mb product. My stats :
Broadband Link Downstream Upstream
Connection Speed 40000 kbps 7275 kbps
Line Attenuation 22.6 dB 0.0 dB
Noise Margin 7.5 dB 5.5 dB
My upstream snr has always been between 5.5 & 6db
-
This is good to know cheers!
I am also 800m from my cabinet, although i'm only on a 40mb product. My stats :
Broadband Link Downstream Upstream
Connection Speed 40000 kbps 7275 kbps
Line Attenuation 22.6 dB 0.0 dB
Noise Margin 7.5 dB 5.5 dB
My upstream snr has always been between 5.5 & 6db
This won't have any bearing on your line as you already sync at the maximum for your package. The SNRM can't drop below 6dB unless you upgraded package.
-
Surly AnglleRex line could go from 6dB to 3dB in steps of 1dB the only difference the extra connection speed (sync rate) speed would be added to their attainable sync and if they changed the package to say BT 55/10 they could then use that extra sync, hard to tell without knowing AR's attainable rate.
-
Surly AnglleRex line could go from 6dB to 3dB in steps of 1dB the only difference the extra connection speed (sync rate) speed would be added to their attainable sync and if they changed the package to say BT 55/10 they could then use that extra sync, hard to tell without knowing AR's attainable rate.
It technically could do that, but whilst they are capped at 40, would DLM bother to reduce the SNRM if it wouldnt actually make any difference to the sync speed? I guess we'll find out when it is rolled out my widely. Would lowering the SNRM to 3dB and thus increasing attainable, but capping at 40, make the line more prone to noise and errors? I'd assume so.
-
Assuming everything else remains the same, the target SNRM is irrelevant if the actual sync speed is limited to the rate cap. The current SNRM would still be 7.5 dB.
If the transmitted power level was also reduced, which is not likely to happen, and it reaches the same speed, but with a lower target and current SNRM, then yes the error rate would be higher.
-
Think I have gone on the trial to, I can see my errors have increased should I be concerned. So far I am at 4.2 on mydsl not sure if my errors are high though or are they ok :? Srtange thing is my line is not showing any speed increases on any of the speed tests I do (ADSL GUIDE and SPEEDNET) shows the same speed 68 down.
-
Really massive errored seconds showing up here yakidoda would cap your line at 40Mbps ASAP :P showoff :) and drop the current PPPoE on the router for 5 minutes to gain that extra speed.
-
Heheh, thank you NewtronStar appreciate your answer, made me smile ;) and the speed went up to 71-72.
-
Heheh, thank you NewtronStar appreciate your answer, made me smile ;) and the speed went up to 71-72.
Thats Good! Kitz has has a happy forum with nice and very helpful members and you have also joined the forum so enjoy yourself.
-
Apologies, I have just seen the replies to my question.
To clarify, yes, I'm on 40mb capped and have been since fibre came to my cabinet. There was no point going to the 76mb product as it was then, or even the 55mb product more recently as my max attain. was 42-44mb.
However, now the 3db has shown the increase to almost 55mb, it MIGHT be worth re-visiting.
I probably won't though :)
-
Ry-sync at 11AM now at 3.3db/54100 . (800 meters to cab 21.7 attenuation)
Happy with this if its stable, its close to my BT 55/10 deal
quick speed run (torrent running so upload is 1mb short)
http://speedof.me/show.php?img=170405102719-3761.png
-
I just had another re-sync but nothing appears to have changed as far as I can see.
My info should be uploaded onto MDWS if anyone can fathom out why it had one. All I can see is reason 1.
-
Strange one now, Line went down 00.30 last night, some sort of upgrade?.
My 3db SNR @54000 attainable 800m from cab.(21.7 Attenuation )
Line came back up, SNR is now 9db and my attainable is 67500 (21.9 Attenuation), makes no sense to me at all ?
-
Strange one now, Line went down 00.30 last night, some sort of upgrade?.
My 3db SNR @54000 attainable 800m from cab.(21.7 Attenuation )
Line came back up, SNR is now 9db and my attainable is 67500 (21.9 Attenuation), makes no sense to me at all ?
Check for vectoring? I'm not sure if this is actually live? Others more knowledgeable would probably know :D
-
there has been a flood of posts on tbb reporting higher attainable out of nowhere, can you please check what your vectoring status is.
-
there has been a flood of posts on tbb reporting higher attainable out of nowhere, can you please check what your vectoring status is.
Any idea where I will find that info on a Billion 8800NL ?
My router stats since reboot.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FDgrMXsSh.jpg&hash=fa41e19ed78c33384df75a189e6787a8d8007f13)
-
there has been a flood of posts on tbb reporting higher attainable out of nowhere, can you please check what your vectoring status is.
A flood? I've seen 2?
-
telnet in to the device and send the command
"adsl info --vectoring"
state 5 means it's not enabled on your cabinet.
-
A flood? I've seen 2?
you ruined the excitement shhhh.
But good to get vectoring status checked anyway.
-
No Vectoring :(
On BT 55/10
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FB6tKLM0.jpg&hash=44f1739e675287d9d0825b4b0a8ebe48ae44ec87)
-
Vectoring state 1 means it's enabled
-
Vectoring state 1 means it's enabled
Damn does that mean I'm actually one of first for something. ;D
-
It means it is enabled in your CPE -- the Billion modem/router.
But the big question is: "Does 'enabled' mean that vectoring is active on the circuit in question?" :-\
-
The VCE MAC address being something other than all zeroes, plus the non-zero counts for the error samples sent, indicate that vectoring is operating on this line.
The vectoring state number does also indicate that it is in operation - I think it's been reported previously that it changes between 1 and 3, presumably depending on what vectoring activity is currently occurring.
-
It means it is enabled in your CPE -- the Billion modem/router.
But the big question is: "Does 'enabled' mean that vectoring is active on the circuit in question?" :-\
I think it is enabled on the live connection, it will show 5 if its not.
interesting.
-
5 indicates not configured on my TP-Link I think the 1 status indicates it is live on the circuit.
-
See http://forum.kitz.co.uk/index.php/topic,13930.msg349129.html#msg349129 (http://forum.kitz.co.uk/index.php/topic,13930.msg349129.html#msg349129) for the list of vectoring states.
A state of 1 indicates that vectoring is fully operational.
-
Cheers for all the info guys as its all above my head :).
Big jump in attainable when you realise attainable was 42-4300 before the 3DB margin(old 6db).
Now with a 9db margin, attainable is 67000.
Question now is it here to stay on my line? or is it just a test.
-
hopefully its here to stay, I know its going to make ECI users pretty annoyed, but I hold no grudge against hauwei people, so fingers crossed for you it stays, thats quite a jump. Is a shame you not on MDWS then we could have analysed loads of data.
-
You probably don't have a 9 dB target SNRM. The SNRM is higher than whatever the target is because the speed is capped at 55Mb. The attainable will be calculated using the target SNRM.
-
hopefully its here to stay, I know its going to make ECI users pretty annoyed,
Using every muscle in my body not to have a rant about the ECI cabinets it has been a few months since my last one!
I am saving up my energy ready for the announcement that Ginp and 3db will never be implemented on ECI as they can't get it to work. Must be getting closer to a further update on this soon.
-
hopefully its here to stay, I know its going to make ECI users pretty annoyed, but I hold no grudge against hauwei people, so fingers crossed for you it stays, thats quite a jump. Is a shame you not on MDWS then we could have analysed loads of data.
MDWS will it run with just a Billion 8800NL connected to the line ?
-
Here we go again.. eci users short changed :rant: :rant:
Another reason to move to huawei area ::)
-
This could simply be a BDUK Huawei cabinet that's had vectoring switched on the meet some "over 24mbps" targets by extending the reach to further away properties.
There are a few of them kicking about.
-
This could simply be a BDUK Huawei cabinet that's had vectoring switched on the meet some "over 24mbps" targets by extending the reach to further away properties.
There are a few of them kicking about.
Lee you could well be right, I'm very rural in Mid Wales and the cab covers people out to 1.5 miles +
-
MDWS will it run with just a Billion 8800NL connected to the line ?
Yes download DSLStats and Sign up for MWDS. Billion 8800NL is in the list on DSLStats.
-
The VCE MAC address being something other than all zeroes, plus the non-zero counts for the error samples sent, indicate that vectoring is operating on this line.
Excellent. A clear, concise, statement. Thank you. :)
-
See http://forum.kitz.co.uk/index.php/topic,13930.msg349129.html#msg349129 (http://forum.kitz.co.uk/index.php/topic,13930.msg349129.html#msg349129) for the list of vectoring states.
A state of 1 indicates that vectoring is fully operational.
And my thanks are also due to you. :) The above link is to the post that I could not track down . . .
-
OK, MDWS up and running, can someone confirm they can see the stats ?
-
OK, MDWS up and running, can someone confirm they can see the stats ?
What is your user name? I don't see Xup . . . :-\
-
Xup was to short a name so had to be Xuplaptop :)
-
Something must be amiss. I can only see one user with an ID that starts with an "x" and that is xreyuk. :-\
-
Something must be amiss. I can only see one user with an ID that starts with an "x" and that is xreyuk. :-\
I can see you and myself in there you're green I'm grey ?(usernames)
-
Don't forget xhemp and Xspwaj-Dsr
-
I don't see B*cat or Xup* in the graph list.
-
I'm there now, I had no idea I needed the Validation key Doh ! ???
-
I see Xup graphs.
-
I, too, can see Xuplatop in the users' list.
We now need to wait for about 24 hours of data to be collected.
-
Anyone see anything different with the vectoring enabled stats on MDWS, it's been up and running now for 36 hours.
Had a resynce last night at 9.15PM just like it was in retraining?.
-
I can see the resynchronisation event and can confirm that the circuit was a little bit unstable just before the re-train occurred.
Unfortunately the uploads to MDWS ceased after 2323 hours (2 August) and resumed at 1007 hours (3 August) so there is a big gap in the data . . .
Looking at the two plots that tell something about the physical infrastructure of the circuit -- The Hlog plot confirms that there is no obvious wiring defect and that although the line length is tending to longer rather than shorter you have adequate signals in the DS1, DS2, DS3, US0 & US1 bands. The US2 band is, essentially, absent. The QLN plot tells me that the circuit is fairly well AC-balanced and that the cabinet is of a significant distance from the telephone exchange with which it is associated. The is minor RF ingress; some (at the lower frequency) are undoubtedly broadcast signals.
For the current behaviour of the xDSL link (across the physical circuit) I would prefer to leave it for others to analyse.
-
I can see the resynchronisation event and can confirm that the circuit was a little bit unstable just before the re-train occurred.
Unfortunately the uploads to MDWS ceased after 2323 hours (2 August) and resumed at 1007 hours (3 August) so there is a big gap in the data . . .
Looking at the two plots that tell something about the physical infrastructure of the circuit -- The Hlog plot confirms that there is no obvious wiring defect and that although the line length is tending to longer rather than shorter you have adequate signals in the DS1, DS2, DS3, US0 & US1 bands. The US2 band is, essentially, absent. The QLN plot tells me that the circuit is fairly well AC-balanced and that the cabinet is of a significant distance from the telephone exchange with which it is associated. The is minor RF ingress; some (at the lower frequency) are undoubtedly broadcast signals.
For the current behaviour of the xDSL link (across the physical circuit) I would prefer to leave it for others to analyse.
Cheers for that, the cab is 800 meters away the exchange is 4000M away.
I left the computer running for 24hours but had to turn it off last night as I was away for the night.
-
Cheers for that, the cab is 800 meters away the exchange is 4000M away.
I left the computer running for 24hours but had to turn it off last night as I was away for the night.
Interesting, I'm also 800m from my fibre cab. Wondering if we ever get Vectoring if my speed will increase!
-
Had a resync just now (had one yesterday to enable G.INP) and it looks like I'm now on a 5dB target. Sync now maxed out as I'm on the up to 55Mb profile.
-
Had a resync just now (had one yesterday to enable G.INP) and it looks like I'm now on a 5dB target. Sync now maxed out as I'm on the up to 55Mb profile.
Wish ECI would get G.INP :(.
-
Hopefully this autumn ixel, fingers crossed.
-
I have vectoring too :P :P
-
bduk area gigabit?
-
Has anyone on a LLU provider (eg Vodafone) has their target SNRM lowered? Apart from a period after a power cut, my SNRM’s been 6 or just over for ages and no drop in target.
-
There is no LLU with FTTC. It's all OpenReach DSLAMs, their Element Managers, their DLM.
The lower SNR target profiles work the same across all ISP's. I've seen lower margins on a large number of different ISP's, including Vodafone.
-
Ah, of course. Thanks!
So either the new profiles haven’t rolled out to my area (Gravesham) yet, or my line is still not pleasing the DLM gods. Never mind!
-
bduk area gigabit?
Yup.
-
Ah, of course. Thanks!
So either the new profiles haven’t rolled out to my area (Gravesham) yet, or my line is still not pleasing the DLM gods. Never mind!
Huawei?
-
Huawei?
Yep! Huawei cab with an Openreach-branded HG612 on Vodafone.
-
I haven't seen my SNR reduce either. I'm on HG612 and a Huawei cab. :/
-
Syncing below the max rate for your chosen product?
-
Pretty much the whole south east had a power cut today. Upon resync my upstream SNR is now 3db and max attain 41.5 odd
Details on MDWS if anyone wanted to take a look.
-
Pretty much the whole south east had a power cut today. Upon resync my upstream SNR is now 3db and max attain 41.5 odd
Details on MDWS if anyone wanted to take a look.
Wow, south east? I thought it was just localised to my area, shocking!
-
Looks like my line’s just started its target SNRM adjustments (MDWS: displaced)
Sync up from 48-ish to 51, target now 5.0dB
Seems all I had to do was leave the country (in Toronto at the moment). Yaay!
-
I'm beginning to build up a picture in my mind it's probably wrong :-\
If your line/circuit sync is lower than the upto sync for example your on 40/10 service and your only getting 24Mbps then the 3dB target will be implemented.
Your on a 40/10 service and very close to the max of say 38Mbps the 3dB target margin will not be implemented.
Your on a 55/10 service and not close to the max it will try the 3dB target and so on with 80/10
-
Well, been on a 4dB profile for a couple of days and it's solid. Attainable up from 47 to 53 -- so each 3dB drop gave a rise of about 3Mbit.
ESs are at about 20-odd per day, and SES are between zero and 10 per day. So I imagine its likely that the line will drop to a 3dB Target SNRM soon.
If that gets me to 57Mbit attainable, I'll be very happy. 57Mbit is what my line got when FTTC was first enabled back in 2012. Undoing the speed loss due to crosstalkers would be nice!
-
Does anyone know if this is still estimated to complete this month?
Is it still the general consensus that we will only get it if DLM thinks your line can take it?
-
I'm beginning to build up a picture in my mind it's probably wrong :-\
If your line/circuit sync is lower than the upto sync for example your on 40/10 service and your only getting 24Mbps then the 3dB target will be implemented.
Your on a 40/10 service and very close to the max of say 38Mbps the 3dB target margin will not be implemented.
Your on a 55/10 service and not close to the max it will try the 3dB target and so on with 80/10
I was on 79,574 and then the 3dB target was implemented and I'm now on 79,999 at 4.5dB
-
I was on 79,574 and then the 3dB target was implemented and I'm now on 79,999 at 4.5dB
Your a lucky boy as I said I'm probably wrong but I'll stick with my observation, the SNRM changes to XdB started to happen in FEB-MARCH 2017 its either a very slow rollout or specific to the circuits requirement which is what I am trying to find out.
I have seen really bad circuits with mad SNRM fluxuation and errored seconds and still it lowers the SNRM margin yet their attainable is lower than the max for that service :-\
-
I'm on a 3dB as of Sunday morning.
77211 sync on a ~600m line (19.3db attn).
Cab is full, expecting last few circuits to go live this week so would hope I've had my whack of crosstalk.
Only time will tell :)
-
I'm on a 3dB as of Sunday morning.
77211 sync on a ~600m line (19.3db attn).
Cab is full, expecting last few circuits to go live this week so would hope I've had my whack of crosstalk.
Only time will tell :)
Typical Willy Waver don't mind me I'm just jealous and frustrated most new members lines are getting faster these days a a full 80/20 service would do me for another 5 years ;)
-
Haha!
Just quite impressed (and surprised) more than anything. Line estimate is 45-61 clean.
It's a "new" estate with all ducted cables. I say new, it's been being built for around 9 years which is why there's no FTTP.
Previously had 2meg ADSL so it's quite an improvement :D
-
I think my line is about 800m 22.8db attenuation (according to the fttc engineer back in 2015 and his device).
I was always max attain 42-44mb / 6mb. since mid May this has plummented to 37.5mb max attain - however a powercut a few weeks back put me back to 42mb attain and a spike in CRC errors caused a resync then back again to 37.5mb max..... ffs
I'm only on a 40/10 service but would like to be back in the mid 40's where possible. I've no idea if I have crosstalk, rein or a problem on the line - there are no issues when making calls so i'm guessing something else has kicked it out :/
Hoping this 3db will help!
-
Reduction took place last weekend, down to 3.3 and sync now at 74437. However, according to BTW Test results my IP profile rate is sat at 68Mpbs. I've reset the router and modem and it's not changed, stuck perhaps.
-
As that's 91% it could be you're on high retransmission
-
As that's 91% it could be you're on high retransmission
Don't think so, but my stats are there on MDWS so you can take a look and confirm or reject that idea.
Edit.
That would appear to be the case.... what a con.
-
Is it normal for a line to get a few DLM resyncs before it gets the 5dB profile and few more DLM resyncs after it's applied in the first 24 hours ?
-
Is it normal for a line to get a few DLM resyncs before it gets the 5dB profile and few more DLM resyncs after it's applied in the first 24 hours ?
Not with my drop, 3 clean steps down to 3.3db, one re-sync at approx 5, 4 and 3.3. only re-sync was caused by me forcing the sync down to 70Mbps to try and force a lower G Inp value... It didn't work though.
-
TBH don't even know if this is the sub SNRm but it looks like it, don't have a steady SNRM which makes this even harder DLM resyncs have settled down.
-
With the recent news of ECI maybe getting a xdb trial from the 20th of this month, do we have any more facts about the huawei xdb changes that are meant to be still on going?
My line is still 6.1-6.6db and only synced at 35mb on a 40/10 product, just wondering if I'll ever see this mythical unicorn :D
-
I’ve also been wondering if the roll out is finished. I’m on a Huawei cab with a margin of 6.3 to 6.4, not that the xDB would make much difference to me being on a 76Mb synch but it would be nice to see the 79999 back in the stats.
-
A higher sync is not always better with XdB as once your INP goes into higher retransmit you lose some throughput now on 5dB with a sync of 39551 but the throughput is only 35811 kbps = 90% of 96% on low restransmit and 4dB was better at 92%
TBH I would prefer to have a sync of 38000 kbps with a interleaving depth of 8 and INP: 46.00 @ 96% throughput.
-
A higher sync is not always better with XdB as once your INP goes into higher retransmit you lose some throughput now on 5dB with a sync of 39551 but the throughput is only 35811 kbps = 90% of 96% on low restransmit and 4dB was better at 92%
TBH I would prefer to have a sync of 38000 kbps with a interleaving depth of 8 and INP: 46.00 @ 96% throughput.
That's great cheers.
I'm leaving my line alone for a bit, think it was 52 & 42 on inp with 8 down and 4 up
-
A higher sync is not always better with XdB as once your INP goes into higher retransmit you lose some throughput now on 5dB with a sync of 39551 but the throughput is only 35811 kbps = 90% of 96% on low restransmit and 4dB was better at 92%
TBH I would prefer to have a sync of 38000 kbps with a interleaving depth of 8 and INP: 46.00 @ 96% throughput.
Too true. I have just changed modem from an HG612 through a Zyxel 1312 and I'm now using a Billion 8800NL. The Billion wins on sync. However it matters not which one is syncing fastest as I have, as you say got a higher rtx level. So although I have gained just over 11Mbps from a sync of 63Mbps to a sync of over 74Mpbs, my throughput was being limited to approx 68.4Mpbs. In saying all that, I did have a rtx of 52 it'a now at 51, by reducing the sync the throughput has increased to around 69.2, so I have achieved a slightly higher throughput by reducing the sync rate to 71.
-
Too true. I have just changed modem from an HG612 through a Zyxel 1312 and I'm now using a Billion 8800NL. The Billion wins on sync. However it matters not which one is syncing fastest as I have, as you say got a higher rtx level. So although I have gained just over 11Mbps from a sync of 63Mbps to a sync of over 74Mpbs, my throughput was being limited to approx 68.4Mpbs. In saying all that, I did have a rtx of 52 it'a now at 51, by reducing the sync the throughput has increased to around 69.2, so I have achieved a slightly higher throughput by reducing the sync rate to 71.
Sorry to go slightly off topic here, but are you saying you gained over 11Mbps from switching from a HG612 to a Billion 8800NL (assuming R2) :o? That's an impressive increase if so, makes me wonder if I should buy a Billion too (just for modem only).
EDIT: Just read some posts that the R2 gives worse performance than the HG612, where the first version of the 8800NL gave better performance, so I'm guessing you have the first version.
-
OK so does an increase in INP reduce the max attainable?
1. My line INP has increased from 45 to 52
2. My Max attain is now 37meg and synced at 35meg
3. The below line stats show attain 42meg sync 40meg
These are my line stats from before the thunderstorm in May :
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 6531 Kbps, Downstream rate = 42040 Kbps
Bearer: 0, Upstream rate = 6604 Kbps, Downstream rate = 40000 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 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): 7.1 5.9
Attn(dB): 22.9 0.0
Pwr(dBm): 11.0 -1.3
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 138 207
M: 1 1
T: 0 39
R: 8 6
S: 0.1101 1.0000
L: 10684 1712
D: 16 1
I: 147 107
N: 147 214
Q: 16 0
V: 12 0
RxQueue: 27 0
TxQueue: 9 0
G.INP Framing: 18 0
G.INP lookback: 9 0
RRC bits: 0 24
Bearer 1
MSGc: 90 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 10.6667 0.0000
L: 24 0
D: 1 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 29698
OHFErr: 2981 865
RS: 1137461808 1158236
RSCorr: 1457020 503
RSUnCorr: 0 0
Bearer 1
OHF: 16729836 0
OHFErr: 60 0
RS: 100378646 0
RSCorr: 8896 0
RSUnCorr: 63 0
Retransmit Counters
rtx_tx: 557383 0
rtx_c: 13725 0
rtx_uc: 118278 0
G.INP Counters
LEFTRS: 342 0
minEFTR: 39989 0
errFreeBits: 163884756 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 3486525131 0
Data Cells: 277836243 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 149 763
SES: 73 0
UAS: 22 22
AS: 268726
Bearer 0
INP: 45.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 9.78
OR: 0.01 26.15
AgR: 40252.99 6630.10
Bearer 1
INP: 2.50 0.00
INPRein: 2.50 0.00
delay: 0 0
PER: 16.06 0.01
OR: 47.81 0.01
AgR: 47.81 0.01
Bitswap: 200904/200950 3368/3379
Total time = 1 days 2 hours 39 min 8 sec
FEC: 1457020 503
CRC: 2981 865
ES: 149 763
SES: 73 0
UAS: 22 22
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 9 min 8 sec
FEC: 2517 2
CRC: 0 7
ES: 0 7
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 213 1
CRC: 0 5
ES: 0 5
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 2 hours 39 min 8 sec
FEC: 9931 11
CRC: 0 34
ES: 0 32
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 520042 248
CRC: 1503 319
ES: 66 261
SES: 35 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 3 days 2 hours 38 min 45 sec
FEC: 1457020 503
CRC: 2981 865
ES: 149 763
SES: 73 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
-------------------------------------------------------
Stats from July :
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 7128 Kbps, Downstream rate = 39212 Kbps
Bearer: 0, Upstream rate = 7128 Kbps, Downstream rate = 35000 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 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): 7.3 6.4
Attn(dB): 23.0 0.0
Pwr(dBm): 11.0 3.6
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 73 211
M: 1 1
T: 0 0
R: 6 12
S: 0.0666 0.9446
L: 9610 1897
D: 8 4
I: 80 224
N: 80 224
Q: 8 4
V: 5 1
RxQueue: 132 12
TxQueue: 33 6
G.INP Framing: 18 18
G.INP lookback: 31 6
RRC bits: 24 24
Bearer 1
MSGc: 90 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 10.6667 16.0000
L: 24 16
D: 1 1
I: 32 32
N: 32 32
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 0
OHFErr: 84 6
RS: 313733304 67258
RSCorr: 469025 8763
RSUnCorr: 0 0
Bearer 1
OHF: 22672871 741484
OHFErr: 7 11
RS: 136036856 852009
RSCorr: 292 496
RSUnCorr: 14 0
Retransmit Counters
rtx_tx: 92432050 1279
rtx_c: 24313 70396
rtx_uc: 9272 24431
G.INP Counters
LEFTRS: 25 1886
minEFTR: 35003 7124
errFreeBits: 194425494 992513467
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 3037005364 0
Data Cells: 1090589083 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 23 2
SES: 0 0
UAS: 36 36
AS: 364186
Bearer 0
INP: 52.00 41.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 35418.64 7153.55
Bearer 1
INP: 2.50 4.00
INPRein: 2.50 4.00
delay: 0 0
PER: 16.06 16.06
OR: 47.81 31.87
AgR: 47.81 31.87
Bitswap: 282219/282222 7677/7696
Total time = 1 days 5 hours 10 min 22 sec
FEC: 469025 8763
CRC: 84 6
ES: 23 2
SES: 0 0
UAS: 36 36
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 10 min 22 sec
FEC: 264 13
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: 366 7
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 = 5 hours 10 min 22 sec
FEC: 6987 209
CRC: 8 0
ES: 2 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 62352 4533
CRC: 8 0
ES: 2 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 4 days 5 hours 9 min 45 sec
FEC: 469025 8763
CRC: 84 6
ES: 23 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
-
OK so does an increase in INP reduce the max attainable?
No.
With old style interleaving+INP the max attainable is over estimated, by quite a bit.
With G.INP the INP value shouldn't change the max attainable. The max attainable is pretty accurate with G.INP enabled.
What NewtronStar was discussing above was the difference in throughput between retransmission high and retransmission low.
Retransmission low has an ip profile/throughput around 96.7% of sync speed.
Retransmission high has an ip profile/throughput around 91-92% of sync speed.
The lower snrm profiles tend to use retransmission high.
So while dropping from 6dB to 5dB snrm will increase your sync, it lowers your actual throughput. It's only when the line moves on to 4dB and 3dB that you will see an increase in throughput.
I've yet to see my line use retransmission low with a lower snrm profile. It appears to be possible though as BlackSheep posted his line profile changes which showed DLM trying retx low on his line.
-
No.
With old style interleaving+INP the max attainable is over estimated, by quite a bit.
With G.INP the INP value shouldn't change the max attainable. The max attainable is pretty accurate with G.INP enabled.
What NewtronStar was discussing above was the difference in throughput between retransmission high and retransmission low.
Retransmission low has an ip profile/throughput around 96.7% of sync speed.
Retransmission high has an ip profile/throughput around 91-92% of sync speed.
The lower snrm profiles tend to use retransmission high.
So while dropping from 6dB to 5dB snrm will increase your sync, it lowers your actual throughput. It's only when the line moves on to 4dB and 3dB that you will see an increase in throughput.
I've yet to see my line use retransmission low with a lower snrm profile. It appears to be possible though as BlackSheep posted his line profile changes which showed DLM trying retx low on his line.
Ok, thanks for clarifying that. Looking at both the stats above, and given that on a mass powercut recently I resynced back up to 40/7 with max attain 44/7.5 (only to drop 5 days later to 37/7), does that just point to a cross talker dragging me down?
-
Sorry to go slightly off topic here, but are you saying you gained over 11Mbps from switching from a HG612 to a Billion 8800NL (assuming R2) :o? That's an impressive increase if so, makes me wonder if I should buy a Billion too (just for modem only).
EDIT: Just read some posts that the R2 gives worse performance than the HG612, where the first version of the 8800NL gave better performance, so I'm guessing you have the first version.
Yes I bought the first 8800NL version second hand off Amazon on Sunday, twas only £39. No, the 11Mpbs increase is down to the drop from 6db to 3db. althoough I gained a Mb+ or so switching to the Billion. As a side note upload DID vastly improve with both the Billion and the Zyxel. I am now able to push the 20Mbps whereas with the HG612, hitting 18Mbps on upload was rare.
-
With the recent news of ECI maybe getting a xdb trial from the 20th of this month, do we have any more facts about the huawei xdb changes that are meant to be still on going?
I believe the huawei xdb changes are still going on - my parents line in Wandsworth appears to have benefited from this yesterday morning @10:31. The line is on MDWS under gt94sss2
-
I believe the huawei xdb changes are still going on - my parents line in Wandsworth appears to have benefited from this yesterday morning @10:31. The line is on MDWS under gt94sss2
Thanks :)
-
moved house and had a new line installed on Dec1st which is still interleaved. One thing ive noticed keeping an eye on my stats since the install is that my snr hasnt really moved from 6db sometimes rising to 6.1-6.2. Ive only just recently found that BT introduced this 3db target some time ago. Is it still to go live on some cabinets or is it possibly that my max attainable rate is only 40mb being quite far from the cabinet that my snr will not go lower than its current 6db. I feel i could benefit not only from g.inp, but a lower target of 3db would also give me a few extra mb
im connected to a hauwei cabinet using a hg612 modem
thanks. mark
-
moved house and had a new line installed on Dec1st which is still interleaved. One thing ive noticed keeping an eye on my stats since the install is that my snr hasnt really moved from 6db sometimes rising to 6.1-6.2. Ive only just recently found that BT introduced this 3db target some time ago. Is it still to go live on some cabinets or is it possibly that my max attainable rate is only 40mb being quite far from the cabinet that my snr will not go lower than its current 6db. I feel i could benefit not only from g.inp, but a lower target of 3db would also give me a few extra mb
im connected to a hauwei cabinet using a hg612 modem
thanks. mark
I beleive xdB requires you to first have G.INP active. Generally it seems once G.INP is active, xdB follows a few days later.
From your posts on the other thread, you don't yet have G.INP active on your line. Follow through the instructions there, and then once G.INP has been enabled on your line keep an eye on it to see if xdB will be applied. xdB is not always guaranteed as it will depend on the quality of your line, but it won't happen regardless until G.INP has been enabled on your line.
-
great stuff thank you
-
I beleive xdB requires you to first have G.INP active. Generally it seems once G.INP is active, xdB follows a few days later.
From your posts on the other thread, you don't yet have G.INP active on your line. Follow through the instructions there, and then once G.INP has been enabled on your line keep an eye on it to see if xdB will be applied. xdB is not always guaranteed as it will depend on the quality of your line, but it won't happen regardless until G.INP has been enabled on your line.
^^ Exactly this. I expect KingJ to drop to 5dB in the next day or 2 if the line is deemed stable.