Kitz Forum
Announcements => News Articles => Topic started by: kitz on January 07, 2015, 11:12:09 PM
-
It would appear that from 12th of Jan, BT Openreach is rolling out G.INP technology nationwide on VDSL lines. G.INP -alternatively known as PhyR, gives effective protection against noise bursts.
Traditionally the way the DLM handled lines that were subject to frequent noise bursts was to increase the Target SNR Margin to give the line a larger buffer zone. G.INP works slightly differently by lowering the BER rate and is designed to work alongside Vertoring (which improves sync speeds by effective protection of crosstalk).
G.inp coding now provides an improved retransmission-based error-handling mechanism for VDSL2 & VDSL2 Vectoring which results in significantly lower overheads. By replacing the traditional Forward Error Correction (FEC) mechanism, G.inp avoids the FEC-associated fixed overhead of about 12 percent in typical cases, and G.inp only kicks in when there’s actually an error to correct.
- See more at: http://www2.alcatel-lucent.com/techzine/vdsl2-vectoring-delivers-on-its-promise/#sthash.Gibov2ll.dpuf
Some of the more observant amongst us on this forum have already suspected that BT had possibly been dabbling with G.INP/phyR & DLM for a while and its certainly not gone unnoticed the introduction of FEC without interleaving.
What is unclear at the moment is any definite statement that BT 'may' start to use g.inp as one of the parameters for the DLM, but from information available, it would appear that they may well be doing so - Again some of us have noticed differing levels of INP applied.
What is new is the nationwide roll out and the possibility that some modems with older firmware may have problems obtaining internet access (sync but no PPP) if it has a G.INP profile applied by the DLM.
An example could be replacement of an ECI modem (which natively does not support PhyR) on a line that already has an INP profile applied by the DLM, may not be able to obtain PPP until its firmware has been updated.
-
Finally!
Not joking but I'm pretty sure that BT are the last teleco in any developed country to implement g.INP - its verging on farcical how far behind they are.
-
Sorry if this is a naive question but how - if at all - might this affect customers who do not have BT as their ISP?
Stuart
-
Sorry if this is a naive question but how - if at all - might this affect customers who do not have BT as their ISP?
Stuart
Openreach handle all the VDSL connections so I think it will affect everyone, the only reason there may be "any" doubt to this is the recent discussions about the "custom" field in the DLM parameters.
I had FEC enabled on fast path on my downstream during my last fault, although I have no idea if it was due to this phyr or not because interleaving has never been a requirement for FEC. But one thing was clear, I believe when that happened it was the first time I had heard of DLM implementing such a configuration and it was on my own line.
-
Reading the info again it certainly seems to imply that it is now used as one of the DLM parameters for FTTC and they have named this profile parameter "ReTX".
What does it mean for the EU's.. well basically g.inp/PhyR Error correction is far more efficient with overheads that the traditional RS FECs. Less overheads = more actual throughput speed. So the theory is that lines using G.INP FEC algorithm should be able to sync at a slightly higher rate than a comparable line using traditional RS FEC.
The warning is that because its now used as a DLM parameter, it could cause problems on modems that aren't compatible with g.inp - such as the native ECI modems. These should be automatically updated via the BT Agent thingy so if you've had one a while then it should be fine.... but no doubt there are some ECI modems which havent been upgraded yet (such as the one thats been in my cupboard for a well over a year and some on BT vans etc) and those are the modems that may not be able to attain PPP session.
This is worth bearing in mind for users that swap between modems, because if the line has already been categorised and profiled by the DLM with a ReTX profile, then it wont be able to get access to the internet despite being in sync. One way round that would be a DLM profile reset.. but on that latter point BT are also monitoring for "misuse of DLM resets".
-
When Sky implemented g.INP on ADSL nearly 3 years ago they found that it increased sync rates by between 10-20%.
My own line went from being rock-solid (handful of CRC errors/day) @ 17.5Mbps to being just as rock-solid at 20.5Mbps. This of course depended on the modem/router being capable of g.INP, which most of the Be/O2 routers weren't & hence as they (mainly) all wanted to use their own (ancient) Technicolor junk they had lower speeds when they were switched to Sky exchange kit.
-
I just found this which states that Sky have been using it since Easter 2013, but what I note in there is that it confirms that as we suspected that BT has indeed been trialling it on VDSL since 2013. - link (http://www.ispreview.co.uk/index.php/2013/10/sky-broadband-upgrade-unbundled-uk-network-boost-performance.html)
Re the TG582n - the DSLchipset in those routers is actually very good. I dont deny that its been around a while now and the wifi isnt brilliant, but when it comes to the DSLside its damn good. It has a BCM6328 chipset (same as the HG612 & most of the Billions).
Despite having several routers available I stuck with the TG582n when on adsl2+ because it gave me the best sync speeds and was rock steady. This is why so many BE users liked it. Any moans about that particular router are all to do with wifi not the DSL chipset. Its because of its chipset and DSL stability why ISPs such as AAISP and Zen also recommend it.
Due to its BCM6368 it should natively be compatible with g.INP so no idea why it shouldnt work when on Sky. Be* were talking about implementing g.inp on their MSANs several years ago before they got bought out. afaik they trialled it, but never got around to rolling it out to all their MSANs.
It's the modems such as the ECI's which use a Lantiq VRX-268 chipset which may have problems and need updated f/w. This includes the HomeHubs, but BT will automatically do that via the BTAgent. All the BCM6368 and BCM63168 based routers should be fine.
-
BT trials really are excessive, a 2 year period for testing is just insane. DSL can be so much better than it is in this country, think of all their wasted cash on engineer visits etc. because they like a limping duck on technology rollouts.
-
Interesting that BT are only doing this on VDSL whereas Sky were able to do it on ADSL2+.
I wonder if that's because BT have little control over what consumer-end equipment is connected except for FTTC installs?
-
Another naive question ;) Is there any easy way to see this is active when looking at the router/modem?
Stuart
-
Interesting that BT are only doing this on VDSL whereas Sky were able to do it on ADSL2+.
I wonder if that's because BT have little control over what consumer-end equipment is connected except for FTTC installs?
I have absolutely no doubt about that being the most likely explanation.
I seem to recall in the hardware section someone purchasing a new vdsl modem/router and being unable to obtain a PPP session. They ended up twiddling with all the settings including g.inp and SRA.. and only then being able to get a valid connection. We couldnt at the time understand why this would be. I cant recall the exact details now - I think it may have been in one of the ASUS threads, but dont quote me on that.
-
I wonder if the 63168 modems are designed to expect g-INP to be working. At the time of the 63168 release most of the worlds service providers were probably already implementing g-INP.
That might help explain why I, and some others with CRC and ES spikes present on their line, get bigger CRC and ES and often SES spikes with the 63168 modems. The HG612 with the 6368 currently seems better on these lines but only with regard to these spikes.
-
I wonder if the 63168 modems are designed to expect g-INP to be working. At the time of the 63168 release most of the worlds service providers were probably already implementing g-INP.
That might help explain why I, and some others with CRC and ES spikes present on their line, get bigger CRC and ES and often SES spikes with the 63168 modems. The HG612 with the 6368 currently seems better on these lines but only with regard to these spikes.
I did wonder that myself when I saw your post last night in another thread about it.
I (and several others) didnt see the same issue with the 63168 as it works better on my own line, but then again I dont get many large burst noise events... which is where g.inp is supposed to be the most effective. I dont know Im afraid but yep it could be a contributing factor that cant be ruled out.
-
Interesting that BT are only doing this on VDSL whereas Sky were able to do it on ADSL2+.
I wonder if that's because BT have little control over what consumer-end equipment is connected except for FTTC installs?
I have absolutely no doubt about that being the most likely explanation.
Amusingly that's not the case as Sky permit you (they changed T&Cs a couple of years ago - just after the g.INP trial) to use whatever equipment you like on ADSL services. The DLM works fine on a 6dB margin regardless of whether the router supports g.INP but obviously ex-Be people were used to 3dB margins with no DLM & things are a bit iffy at 3dB IMHO.
You are however obliged to use Sky-provided equipment on VDSL2 services. Sky changed their T&Cs last year to specify that & blamed BT (quelle surprise!) so its not the way you think.....
Edit - and regarding the Technicolor Be/O2 kit, just how much of that do you think had modem firmware released in the last 5 years ;) Sky updated the 2504n kit remotely after the trial so g.INP was enabled - pretty sure that most BCM reference kit shipped with modem f/w that disabled g.INP prior to 2012 or so. People did try to tell the ex-Be people but most had made their minds up that Sky was junk long before they came onto forums :)
-
lol... still mates and a lot of respect for each other.. but the time old argument between you and me. :lol:
I liked BE.. it was great, as was the support. 3dB worked fine for me with my TG582n rock steady 24/2.6 until x-talk even then lots of BE users were stable on 3dB. BT also does 3dB and theres quite a few BT users on a 3dB profile. BE went down the pan due to lack of investment in technology and we all know why that was.
My experiences with Sky havent been good, I put several pple on Sky years ago thinking it was cheap and they wouldnt notice the difference. One of them was dad, another my daughter and its me that has to sort out any problems they have. My experience with dads line wasnt good. Support are awful and with my daughter they repeatedly promised things that never materialised - including the MAC key when she'd had enough and wanted to move after a physical line fault and how Sky handled it. She's very happy with her current ISP.
Dads problem was the DLM restricting him to <2Mb and no matter how hard we tried over many months that never much improved so he moved away last year. Yet it happily syncs at 7Mb on a BTw based line with just a small amount of interleaving (22ms v skys at one time 96ms to the BBC). I know you say things are different with their DLM now... but up until last April, things certainly weren't.
Would I go with Sky.. nope I wouldnt, but I respect that you have a different opinion and experiences.
-
Speaking only from an engineering perspective, I find SKY's Tier 2 support to be the best there is on DSL diagnosis. I have no idea how hard it is for the EU to get to talk with these guys, or if it's even allowed, but when it comes to diagnostics they are very much on the ball.
Just thought I'd chuck in my two-penneth, seeing as I'm usually pro-BT. ;) :)
-
The best place to look for Sky outages is the Easynet service portal - not posting link for obvious reasons but you're all bright people so I have no doubt you'll find it.
All I can say is that on the very few occasions I have had to deal with Sky I've had no problems with getting past T1 support & T2 had a BTO lad around on the one occasion it warranted it within 3 days (I turned down the Saturday appointment) - said "lad" now has a s/w* radio (up to 30MHz) & reads this forum :D
I compare that with previous ISPs (Be, Zen, Nildram -as was) and the only one which came up to scratch when something went wrong before was UKOnline (now Sky).
I appreciate I sound like a fanboi here but Sky hit a core network traffic peak of 2.2Tbps on xmas day - it just works but don't expect support on stuff like rdns etc. Horses for courses.
*shortwave not software
-
All I can say is that on the very few occasions I have had to deal with Sky I've had no problems with getting past T1 support & T2 had a BTO lad around on the one occasion it warranted it within 3 days (I turned down the Saturday appointment) - said "lad" now has a s/w* radio (up to 30MHz) & reads this forum :D
Ha ha ........... if it wasn't for the 'Lad' reference ..... that could have been me !! ;) ;D On a serious note (as Kitz is aware), I point as many folk as I can, engineers and EU's alike, to this incredibly informative site. It genuinely helps break down barriers with disgruntled customers.
I'm happy you can get through to Tier 2 so easily ...... so with that in mind, for any SKY users looking on who may need assistance, to get to T2 it's 0345 366 1038 (Opt 4). They ensure you have to listen to ALL the options before you select one :'(.
-
Black Sheep BT ISP customers need to navigate through the ISP call center firewall before getting close to talking to someone on the Tier 2 support ;D
-
Alas, I'm a stranger to which ISP offers the EU the best technical availability, as we have certain numbers to ring and more-often-than-not, have to quote a job specific fault reference number to verify we are indeed an OR engineer.
I do however have a picture built up in my mind of who's who, gauged from the level of abuse I get when visiting the EU's premises. Again, IMHO SKY appear to be easy to deal with. I would say (again IMHO), TT are the worst.
*PS - I put Opt 4 in a previous post above ..... it's actually Opt 5*.
-
That's good news, finally BT are making some progress.
Two questions:
1) May I ask how you found this out? I've checked TBB and ISPReview and both websites don't seem to have an official announcement yet, so I can only assume this must be an internal Openreach announcement not currently available to general public?
2) I presume changes will be noticed at some point during Q1 of 2015, or do you believe this may go on for a longer timeframe?
-
I dont expect there will be an official press release announcement. The more observant will start noticing soon enough. Certainly by the end of the month
Anything DLM related is hard to get hold of and often obscured in amongst other stuff... (more so since the ASSIA case)... so quite often you are reading about one thing and you realise theres a snippet about something else.
-
I see. Fair enough, thanks.
-
Incidently on my billion phyr is only enabled on the upsteam modem side, as I left it on its defaults. So for me to use it I would have to resync. It be interesting to see if the DSLAM does a modem check first for compatibility.
-
Just had my ECI swapped out for a Huawei by Openreach today so going to look out for this on my line (once I have time to unlock it / keep it off so DLM doesn't interfere ;D )
-
Incidently on my billion phyr is only enabled on the upsteam modem side, as I left it on its defaults. So for me to use it I would have to resync. It be interesting to see if the DSLAM does a modem check first for compatibility.
Just checked my billion 8800AXL and phyr is only enabled on downstream - this was the default.
Sent from my iPhone using Tapatalk
-
Hmm I wonder if this is why my Billion lost a large chunk of 'attainable speed' prior to Xmas?
I enabled PhyR on the DS earlier this week during the initial set up and it seemed to recoup that lost speed but I didn't associate it with this at the time.
I have been loaned another Asus DSL-68U and noticed this morning with G.INP enabled my attainable rate is roughly 85/24 and holding steady, yet with PhyR on the Billion and ZyXEL its at roughly 61/22. It makes you wonder if the Broadcomm/ECI chipsets run slightly on the cautious side by restricting the DS for stability purposes compared to the Mediatek chipset which has no restrictions.
-
Hmm I wonder if this is why my Billion lost a large chunk of 'attainable speed' prior to Xmas?
I enabled PhyR on the DS earlier this week during the initial set up and it seemed to recoup that lost speed but I didn't associate it with this at the time.
I have been loaned another Asus DSL-68U and noticed this morning with G.INP enabled my attainable rate is roughly 85/24 and holding steady, yet with PhyR on the Billion and ZyXEL its at roughly 61/22. It makes you wonder if the Broadcomm/ECI chipsets run slightly on the cautious side by restricting the DS for stability purposes compared to the Mediatek chipset which has no restrictions.
With all the issues with the asus I wouldn't trust what it reports, I think it's too optimistic.
Sent from my iPhone using Tapatalk
-
Hmm I wonder if this is why my Billion lost a large chunk of 'attainable speed' prior to Xmas?
I enabled PhyR on the DS earlier this week during the initial set up and it seemed to recoup that lost speed but I didn't associate it with this at the time.
I have been loaned another Asus DSL-68U and noticed this morning with G.INP enabled my attainable rate is roughly 85/24 and holding steady, yet with PhyR on the Billion and ZyXEL its at roughly 61/22. It makes you wonder if the Broadcomm/ECI chipsets run slightly on the cautious side by restricting the DS for stability purposes compared to the Mediatek chipset which has no restrictions.
With all the issues with the asus I wouldn't trust what it reports, I think it's too optimistic.
Sent from my iPhone using Tapatalk
The issues with the ASUS have mostly been down to the 'spectrum' process. I've found that after killing that process that the device has been considerably more stable here. But I suspect simoncraddock might be right in that the BDCM's and Infineon's run a tad more cautiously compared to the MediaTek's.
-
Hmm I wonder if this is why my Billion lost a large chunk of 'attainable speed' prior to Xmas?
I enabled PhyR on the DS earlier this week during the initial set up and it seemed to recoup that lost speed but I didn't associate it with this at the time.
I have been loaned another Asus DSL-68U and noticed this morning with G.INP enabled my attainable rate is roughly 85/24 and holding steady, yet with PhyR on the Billion and ZyXEL its at roughly 61/22. It makes you wonder if the Broadcomm/ECI chipsets run slightly on the cautious side by restricting the DS for stability purposes compared to the Mediatek chipset which has no restrictions.
Please quote actual sync speeds and snrm rather than just attainable thanks.
Only quoting attainable doesnt have much meaning on its own because its reliant on the coding of the firmware on that device.
Also the asus device isnt stable, so its unfair to compare it to devices that are stable.
Its not always right to go after that extra few mbit of sync speed, on my line the zyxel syncs higher than the billion, but it had a higher rate of ES, plus its buggy firmwares put me off, so I chose the billion for every day use.
-
Hmm I wonder if this is why my Billion lost a large chunk of 'attainable speed' prior to Xmas?
I enabled PhyR on the DS earlier this week during the initial set up and it seemed to recoup that lost speed but I didn't associate it with this at the time.
I have been loaned another Asus DSL-68U and noticed this morning with G.INP enabled my attainable rate is roughly 85/24 and holding steady, yet with PhyR on the Billion and ZyXEL its at roughly 61/22. It makes you wonder if the Broadcomm/ECI chipsets run slightly on the cautious side by restricting the DS for stability purposes compared to the Mediatek chipset which has no restrictions.
Please quote actual sync speeds and snrm rather than just attainable thanks.
Only quoting attainable doesnt have much meaning on its own because its reliant on the coding of the firmware on that device.
Also the asus device isnt stable, so its unfair to compare it to devices that are stable.
Its not always right to go after that extra few mbit of sync speed, on my line the zyxel syncs higher than the billion, but it had a higher rate of ES, plus its buggy firmwares put me off, so I chose the billion for every day use.
Remembering stats isn't always possible, not all of us perform 24/7 monitoring so we can only quote what we remember.
However since hooking up the Asus 3.5 days ago it's been very stable, to the point DLM actually took favour and decreased interleaving yesterday for the first time in over a month which it didn't do whilst using the ZyXEL or Billion.
-
Hmm I wonder if this is why my Billion lost a large chunk of 'attainable speed' prior to Xmas?
I enabled PhyR on the DS earlier this week during the initial set up and it seemed to recoup that lost speed but I didn't associate it with this at the time.
I have been loaned another Asus DSL-68U and noticed this morning with G.INP enabled my attainable rate is roughly 85/24 and holding steady, yet with PhyR on the Billion and ZyXEL its at roughly 61/22. It makes you wonder if the Broadcomm/ECI chipsets run slightly on the cautious side by restricting the DS for stability purposes compared to the Mediatek chipset which has no restrictions.
Please quote actual sync speeds and snrm rather than just attainable thanks.
Only quoting attainable doesnt have much meaning on its own because its reliant on the coding of the firmware on that device.
Also the asus device isnt stable, so its unfair to compare it to devices that are stable.
Its not always right to go after that extra few mbit of sync speed, on my line the zyxel syncs higher than the billion, but it had a higher rate of ES, plus its buggy firmwares put me off, so I chose the billion for every day use.
While I agree with what you've said about the attainable rate being an unreliable comparison, I don't agree with what you've said in terms of instability. The device was considerably unstable, but as I will repeat - most of the instability was around a process called 'spectrum' which if left running in the background would for some reason cause a huge amount of CRC errors. I've not only found that since killing it that the device has been considerably better, some other people on another forum have also reported similar results.
Anyway without me dragging this off topic any further, I'll leave it there :).
EDIT: Forgot to mention, I won't deny however that the device's chipset might not be entirely as stable on long lines, but as I'm not a huge distance from the cabinet mine is working fine at the moment and I expect further improvement once G.INP is available.
-
yeah, my comments are also based on feedback for the device on plusnet's forums, it doesnt have a good showing on there.
If you have found something that makes it much more reliable have you suggested to asus to make those changes by default?
-
yeah, my comments are also based on feedback for the device on plusnet's forums, it doesnt have a good showing on there.
If you have found something that makes it much more reliable have you suggested to asus to make those changes by default?
Yeah, babis3g and myself have told ASUS about this problem so they're aware it exists - when they plan to release a fix for the spectrum process I don't know though. The most recent firmwares we had from ASUS via email were 2158 betas (both with spectrum removed temporarily, but one had the new bitswap and the other had the original bitswap). I'm not entirely sure whether there's a difference between the two bitswaps, but currently I'm running the official 2158 and kill spectrum manually.
-
yeah, my comments are also based on feedback for the device on plusnet's forums, it doesnt have a good showing on there.
If you have found something that makes it much more reliable have you suggested to asus to make those changes by default?
Yeah, babis3g and myself have told ASUS about this problem so they're aware it exists - when they plan to release a fix for the spectrum process I don't know though. The most recent firmwares we had from ASUS via email were 2158 betas (both with spectrum removed temporarily, but one had the new bitswap and the other had the original bitswap). I'm not entirely sure whether there's a difference between the two bitswaps, but currently I'm running the official 2158 and kill spectrum manually.
Likewise, running exactly the same firmware with spectrum killed and in 50+hrs since DLM decreased interleaving much to my surprise I've the following error stats:
CRC DS: 6
CRC US: 15
ES DS: 8
ES US: 18
SES DS: 1
SES US: 2
HEC DS: 0
HEC US: 0
What is however really surprising is that neither the Billion or ZyXEL I have can come close to such low numbers, if they are indeed correct. However with DLM reducing my interleaving level on Friday there's no reason to suggest they are inaccurate.
-
sadly they are definitely broken.
You cannot have more ES than CRC.
A ES is at least 1 CRC.
Plus to boot you also have none zero SES.
Not only does the SES to ES ratio seem weird but it also further's the point the CRC isnt right.
But good news on your stability anyway.
What is the actual sync speed and snrm? surely you can provide these figures as its in use right now.
I am curious tho if that firmware has a bug counting errors and as such is sending bad info back to the DSLAM which in effect has led to DLM been misled?
-
Actual sync is 54/19 up from 52/19 earlier this week (not significant could just be purely the snrm being lower right now)
SNRM is 6.0db DS / 6.1db US
Interleaving is down to 659 from 984.
There are quite a few anomalies in the stats, FEC still being a big one.
DSLuptime is showing different to the GUI also but without wanting to rock the boat, it appears generally to be performing better than the Billion & ZyXEL regardless of these mis-counts.
In almost 5 weeks I saw no gain via DLM whilst using a Broadcomm based unit, yet 24hrs after hooking up the ASUS it reduces Interleaving by almost a third, coincidence or cumulative affect of the past month perhaps?
I've just triggered a re-sync as of 20:30 so I can check a clean batch of stats again in 24hrs. I'm wondering if the initial process of turning spectrum off disrupted the counts.
If it's working I'm happy to let it do it's job regardless of firmware inconsistencies that don't affect the performance, they will get sorted eventually just like other devices.
-
ok thanks for info.
so with a snrm of 6db its estimating an extra 30 attainable?
-
Both the Billion and ZyXEL hovered around 6.4 to 6.6db from memory with attainable sitting between 60 and 62/19, I can't see any stats on MyDSLWebStats with me being offline.
I'm currently showing 81/22 on the Asus which will probably rise gradually as it has done before, which I'll be honest is odd but how can you be sure Broadcomm and ECI don't air on the cautious side and artificially reduce this for stability. I'm not going to start messing with DLM over rides like Ixel has been doing just to test stability at the upper reaches of the attainable figure as I only have access to this device for 2 more weeks and don't want DLM to kick me down for tampering. However it will be interesting to see if DLM continues to favour the current performance.
-
its odd to the point its plain wrong.
Of course it is possible both the broadcom devices are also not correct, but their estimates are much more realistic.
Plainly speaking, if you were to resync now with that estimated attainable and it was accurate then you would expect to actually get close to that sync speed. The attainable is an estimate of what sync speed you would get if you resynced at that moment.
So the asus syncs 2-3mbit higher but also has a bit lower margin?
One of kitz recent posts gave an estimate on how much the zyxel reports for her line per db of snrm. On a longer line where is less tones available its even lower per db. My billion was estimating an extra 3mbit for 0.5-0.7db of spare snrm above 6db and I reckon that was an "over" estimate.
With a 6db margin given 6db is the target your attainable should be the same or extremely close to your sync speed.
Right now I am synced at 72916 with a 5.9db snrm, the attainable estimated by modem is 72892.
Ok check max's post here with pics.
http://forum.kitz.co.uk/index.php?topic=14822.msg277681#msg277681
HE has a 10db margin for just over extra 30mbit attainable, its an interleaved screenshot so the attainable is inflated.
I was going to get more info of mydslwebstats but lost the tab in firefox.
-
My actual speed started dropping off when they turned of DLM and so far hasn't recovered. Attainable as been fairly consistent on the ZyXEL however the Billion dropped to around 45/22 just before the holidays. Only earlier this week did I reconnect the Bilion to find it was back to around 61/22 attainable but still only roughly 50/19 actual.
Originally the Billion at time of purchase early November was showing around 68/23 attainable and 64/19 actual.
There are some odd things happening for sure.
-
>> I'm currently showing 81/22
If a line is interleaved, then the max attainable sometimes goes to pot. Its something to do with the router thinking there is 'spare' but the reality is when Interleaving and error correction is turned on, the overheads for RS encoding is actually using it for redundant data. The ASUS isnt the only router that doesn this.. Ive seen it happen on several if not most modem/routers.
The errors count does look a little strange I'd expect more than 6CRCs if an SES has been recorded. A reset is perhaps a good idea :)
As regards the error rate and reduction in interleaving... in all fairness iirc you did get a bit clobbered by the DLM when you first had issues with the ASUS, so now that they appear to have fixed the f/w you are probably recovering from that. I cant recall exactly but if you were syncing at >60 Mbps when using the Billion/Zyxel you cant compare the error rate to a router that is now syncing at 54Mbps. With the lower speed I'd expect the errors to be substantially lower. Hopefully the DLM will recover and you can get back up to >60Mbps again. :fingers:
Im not interleaved & judging by what my SNRm is, then my max attainable rate seems pretty realistic.
-
Kitz yeah but have you seen any other modems over estimate by such a large number? to have that estimate on a 6db margin is completely whacked.
-
Kitz yeah but have you seen any other modems over estimate by such a large number? to have that estimate on a 6db margin is completely whacked.
My attainable on an 8dB margin is 84000 therabouts, and when I had a 6dB it was 83500 according to my stats ??? On the Super Router I used to get an attainable of 90000 in the same conditions.
-
So basically take attainable with a pinch of salt when interleaved.
-
This kind of takes me back to a question I posed to Asus in October which they didn't answer.
Could the high attainable rate be the cause of the unusually high FEC count when interleaved?
I guess this topic has drifted way off course, so I'll leave it at that.
-
Not sure where you're seeing your statistics, but on mine they seem to be accurate with exception to FEC obviously (e.g. I don't have more ES+SES than I do CRC errors on mine).
The attainable rate is mis-calculated somehow, my theory is that it might be calculating the attainable rate of what it would be at around 0 dB SNRM. I don't think it's causing the abnormal FEC count :(.
-
Kitz yeah but have you seen any other modems over estimate by such a large number? to have that estimate on a 6db margin is completely whacked.
Nope. In theory the maximum bit loading on a line that is perfect is somewhere just a little over 3Mbps per 1dB of SNRm or 3.8 Mbps if there were no PSD masks.. and Ive no idea how much effect PCB will have.
Also remember the router reports an average figure for the SNRm so there may be some tail end tones which couldnt load any more bits into the bin even if there was a 1dB rise. (It needs 3dB over base line to load one bit).
So basically take attainable with a pinch of salt when interleaved.
Unfortunately yes. The modems dont seem to adjust correctly to RS overheads.
Could the high attainable rate be the cause of the unusually high FEC count when interleaved?
Not the FECs - unlikely.
The attainable rate is mis-calculated somehow, my theory is that it might be calculating the attainable rate of what it would be at around 0 dB SNRM.
More likely no proper adjustment for error correction overheads and its somehow adding the RS Correction redundancy on to the throughput figure. In cases like this then you'd expect the max attainable to increase each time a greater depth of Interleaving & Err/Corr is applied by the DLM.
Another area is that it may not be adjusting properly to PCB or PSDmasks and performing the calculation without due consideration that those particular tones wont attain any higher sync speed regardless if there is more SNRm. Bearing in mind that PSD masks can easily knock 2 or 3 bits per bin out.. that could amount to quite a bit of sync speed.
-
I wonder if this change will also be put on for ADSL lines as well? I can not wait for Fiber to become live in my area.
-
As far as I know Sky already have physical retransmission (and something called Nitro) on their own ADSL services (not any service through BT's equipment that is).
EDIT: A member at OcUK said the G.INP rollout would be happening as of Wednesday, not sure on his source of information but I'll be eagerly watching my local cabinet for changes from that day onwards. If anyone here can confirm the above then please do :).
-
It rolls out as of today (12th Jan 2015). :)
-
It rolls out as of today (12th Jan 2015). :)
Thanks for the confirmation Black Sheep! Much appreciated.
One final question if I may ask, do you know whether it's something that will take time to rollout (e.g. days, weeks), or is it likely to be a change done overnight? I presume it will take a little bit of time to rollout unless BT have done preliminary work weeks before hand and just need to 'flip a switch' to make use of it.
-
It rolls out as of today (12th Jan 2015). :)
isnt this already used on interleaved connections, INP is the 2nd field on the right in ronski's tools and it has always been a non 0 value when interleaved.
Or is that a different implementation of INP.
-
It rolls out as of today (12th Jan 2015). :)
isnt this already used on interleaved connections, INP is the 2nd field on the right in ronski's tools and it has always been a non 0 value when interleaved.
Or is that a different implementation of INP.
G.INP / PhyR / Physical Retransmission is different to the traditional INP we're used to seeing.
The big difference is that it only is used to tackle errors when they occur rather than be constantly running on the connection like it is at the moment. This as such should mean higher sync rates because of no constant overhead, and finally low latency because of no constant delay as it's only used when an error needs to be tackled rather than all of the connection's uptime :P.
I believe the INPRein statistic reported on the HG612 might change, as that's part of G.INP.
-
So the improvement will only be seen by interleaved lines because fast path has no error correction overhead?
-
So the improvement will only be seen by interleaved lines because fast path has no error correction overhead?
It will benefit both fastpath and interleaved if BT enable it by default rather than possibly allowing DLM to turn it off and on, as it should correct some or a lot of ES as I understand (due to its dynamic nature of tackling errors).
If G.INP is enabled all of the time then I presume interleaved will eventually only be used in situations where G.INP isn't quite able to handle poorly performing lines (if any such event will happen).
-
It rolls out as of today (12th Jan 2015). :)
isnt this already used on interleaved connections, INP is the 2nd field on the right in ronski's tools and it has always been a non 0 value when interleaved.
Or is that a different implementation of INP.
G.INP / PhyR / Physical Retransmission is different to the traditional INP we're used to seeing.
The big difference is that it only is used to tackle errors when they occur rather than be constantly running on the connection like it is at the moment. This as such should mean higher sync rates because of no constant overhead, and finally low latency because of no constant delay as it's only used when an error needs to be tackled rather than all of the connection's uptime :P.
I believe the INPRein statistic reported on the HG612 might change, as that's part of G.INP.
A great explanation as to how G.INP (as I perceive it) will work. Alas, as it's not really engineering related, we have hardly had any info surrounding the roll-out, or the timescales involved. I wish I had more info to share, but genuinely don't. :'(
-
No idea if it's related but my connection was down from 16:02 and came back up at 17:23. No stats were logged, but the modem was responding with the following.
12/01/2015 16:02:03.159 - ERROR!!! - Status = Idle
12/01/2015 16:02:03.159 - ERROR!!! - Couldn't determine Modem in use, exiting
Before and after speeds are virtually the same
-
So the improvement will only be seen by interleaved lines because fast path has no error correction overhead?
It will benefit both fastpath and interleaved if BT enable it by default rather than possibly allowing DLM to turn it off and on, as it should correct some or a lot of ES as I understand (due to its dynamic nature of tackling errors).
If G.INP is enabled all of the time then I presume interleaved will eventually only be used in situations where G.INP isn't quite able to handle poorly performing lines (if any such event will happen).
My concern with g.inp is it potentially will cause jitter due to delys been on and off depending on errors. But I guess its vastly superior to permanent higher latency caused by interleaving.
-
Strange - My Billion VDSL2 sync showing no retrain or disconnected yet by BT roll out? I don't think it haven't rolled out yet!
-
There's nothing strange about that. It's not a matter of just pressing a button and immediately the whole country is switched over. I've no idea how it's being rolled out, but I'm sure it will be done in stages.
-
It will be in stages. It would be chaos if they disconnected everyone at the same time. The servers at ISPs that handle your login would probably crash due to the volume of attempts to log back on.
-
I imagine it will probably be changes to DLM, so G.INP probably won't be noticed until the next time it needs to take action unfortunately. Whether G.INP will be either used on fastpath, replace interleaved profiles, or something else altogether, I have no idea. But one thing I'm guessing is that G.INP won't be active all of the time (unlike in Ireland with Eircom for example).
A few possibilities are:
1) Fastpath with G.INP <=> Interleaved
2) Fastpath <=> Fastpath with G.INP <=> Interleaved
3) Fastpath <=> Fastpath with G.INP
4) *I think is unlikely* G.INP enabled all of the time
-
It also wouldnt surprise me that they may roll it out but not force a new sync.
-
Just using the web when the connection stalled and then this appeared on the stats?
(http://tapatalk.imageshack.com/v2/15/01/13/09ef592cdf26b88b3ebc135a188bb652.jpg)
Can't say I've ever seen a spike up before? Maybe related to PhyR roll out? Attainable sync went up by 10,000kbps as well.
Also had full packet loss showing during that time on the BQM. Although may be related to this:
BT are apparently doing this between midnight and 6, but I doubt that would have caused loss of sync:
(http://status.zen.co.uk/broadband/maintenance-outage-details.aspx?reference=246966[/url)BT is implementing a one-touch project to upgrade MSE, MSC, IEA, EES and EEA devices at (Kirkby Lonsdale, Leigh Collier Lancs, Oxted, Pocklington, Saffron Walden, Wigton, London Covent Garden, London Croydon South, Salisbury Sarem Trunk, Swansea Metro Node). This involves a software upgrade and some hardware changes on the device in a single night under (Program 45 - 7750 Software Upgrade).
I do have a theory, at this time, 00:23 connections on the cab disconnected, and as I reconnected, the amount of crosstalk reduced and then went back up as modems synced back up? I assume the effects of crosstalk are that sudden if all connections were to lose sync.
Obviously, this is only my own theory, however, it seems highly feasible? We also are experiencing an electrical storm at the moment, but that was after this spike.
-
I had asimilar outage around 11pm last night which lasted 5 mins but it didn't drop the line.
-
Strange - My Billion VDSL2 sync showing no retrain or disconnected yet by BT roll out? I don't think it haven't rolled out yet!
Also consider the fact that iirc your line is very good and sees very little errors. DLM will only use it if needed.
To explain to you a bit better, Its kind of like saying BT has introduced interleaving but you wont see it in use unless its deemed necessary.
--
eta.. just noticed that ixel also explained it.
-
@ jamie
That looks typical of when a crosstalk disturber performs a router reboot/resync. I see it happen on my own line a fair bit.
-
@ jamie
That looks typical of when a crosstalk disturber performs a router reboot/resync. I see it happen on my own line a fair bit.
I'd never seen it before so thanks for pointing this out. Thought I'd witnessed some enabling of G.inp, makes me realise how much one person is affecting me!
-
This is one of mine that I see frequently. I think their line must be reasonably unstable as it seems to drop several times a week, although not as often now so it may be more heavily DLM'd. This particular one 'costs' me 5Mb.
-
Interesting, looking back this one "cost" me about 11mb.
It was during an electrical storm so whatever line it was I'm guessing that is maybe what caused it.
-
Yes the situation you described is likely. Ive seen it too on a few occasions during would be considered wide event type noise. I'll see burst of CRCs but because my line is in a better condition it will hold on to the connection, yet the other line gets taken out during the same event. I'm pretty certain Ive shown screen caps of this before on the forum.
-
A question from the not so informed. Is it possible to have fastpath and interleave, see below:
(http://s29.postimg.org/aq5lbiown/draystats.png)
Sorry image is larger than it needs to be.
-
Either it's a bug in the statistics or you're on G.INP. I thought for G.INP that the depth on the first bearer remains 1 (fastpath) but a second bearer is used which is interleaved which is used for the physical retransmission (G.INP). Is that a BT VDSL2/FTTC connection?
What's your ping like to places such as bbc.co.uk?
-
BBC pings at 14ms, allow a couple off that as I get 2ms just pinging the router!
I forgot to add that a couple of days ago, when the DLM first came back to life it was showing Interleaved on both US & DS. Then it went to Interleave on DS only, now it's showing Fastpath on both, so I guess you may be correct and G.Inp is active.
It's Sky Unlimited Pro, so yes, BT :)
Your TQM graph is interesting :)
-
If anyone wants to see a sudden rise in SNRM/Attainable try this :o
I thought at first that G.INP/PhyR had come to my rescue and got back nearly all my sync losses in the year since connection :D
However, more mundane :no:
It was a two-hour power loss in the area which left the line between me and the cab (~800m) apparently with no other active users (I'm on a UPS ) and gave a ~10db increase in SNRM. Odd maybe though that when the power came back the SNRM immediately returned to the previous level (or a bit below) with no stepping as other users came back on line. The cab has some 600 POTS lines but don't know the take up on the Fibre twin (SDHRSTP, Cab 4).
The graphs were obtained by using click-to-zoom in MDWS- they re-centre on where you click each time (for those that support it).
-
Ha, I should remove the link to my TQM, it's inactive at the moment - only really use it when there's a possible problem that I need to monitor. The ping on my connection will fluctuate a bit as I'm tweaking around with my INP and delay settings (downstream only sadly, can't control upstream :().
-
If anyone wants to see a sudden rise in SNRM/Attainable try this :o
I thought at first that G.INP/PhyR had come to my rescue and got back nearly all my sync losses in the year since connection :D
However, more mundane :no:
...
Interesting! Time to go out with the wire cutters in the small hours. :)
Roll on FTTrN.
-
I thought on FTTC u cannot tweak anything like noise margin increasing! As Openreach have disabled it at the cabinet? You can tweak noise margin on the ADSL2+ on BTw.
-
Depends on your VDSL router. Some you can, some you think you can but it does nothing.
Certainly works on the Draytek 2860 and the Asus DSL-AC68.
-
There's a thought....
With the advent of G.Inp, could the SNR level be taken down substantially?
-
Yeah. On the ASUS DSL-AC68U for example, via a tool called TC, I can actually override the maximum downstream sync rate, INP and delay configuration (even beyond the maximum sync rate set on the DSLAM). So for example, if the DSLAM only permits me a maximum downstream sync rate of 49,000Kbps and I pay for up to 80,000Kbps, I can instruct the ASUS to ignore the PMS from the DSLAM (for the downstream that is) and specify a maximum downstream sync rate of 80,000Kbps (or higher, though I wouldn't) - and this works.
As for SNRM, I don't think G.INP effects that. If anything it allows you to get a higher SNRM because it's not constantly running the overheads imposed by traditional interleaving and INP.
-
Yeah. On the ASUS DSL-AC68U for example, via a tool called TC, I can actually override the maximum downstream sync rate, INP and delay configuration (even beyond the maximum sync rate set on the DSLAM). So for example, if the DSLAM only permits me a maximum downstream sync rate of 49,000Kbps and I pay for up to 80,000Kbps, I can instruct the ASUS to ignore the PMS from the DSLAM (for the downstream that is) and specify a maximum downstream sync rate of 80,000Kbps (or higher, though I wouldn't) - and this works.
As for SNRM, I don't think G.INP effects that. If anything it allows you to get a higher SNRM because it's not constantly running the overheads imposed by traditional interleaving and INP.
Maybe time for me to get hold of an Asus again, as I think you have mamaged to sort out what the issues are/were. I was thinking of dropping my SNR to 3db to see what happens. I've already done one reset today, so I'll leave that until tomorrow.
-
I apologise, as said by the other poster, I was wrong on the 8800nl default settings,
PhyR is enabled on my DS and disabled on my US.
I see no reference to vectoring support on the billion tho, I noticed as the billion 8800AXL product page doesnt mention vectoring support either.
-
There's a thought....
With the advent of G.Inp, could the SNR level be taken down substantially?
Indeed it did work. I dropped the SNR to 5db and gained about 2.6Mbbs... Only FECS, no other errors at all after 23 hours.
Maybe I'll try 4db :)
-
There's a thought....
With the advent of G.Inp, could the SNR level be taken down substantially?
Yes. Sky were pretty aggressive in terms of revamping DLM behaviour when they rolled out g.INP on their ADSL2+ service & a lot of users are now on a 3dB profile. Most of those users (as of last summer anyway, don't know now as they finally took the hint & removed me from the beta group) had >40% lower erroring than they had on a 7dB profile with interleaving.
g.INP is the dogs wotsits on ADSL2+ & is a pre-requisite for vectoring (if BT ever get their act together on that).
-
With the advent of G.Inp, could the SNR level be taken down substantially?
Yes ...
Wouldn't it depend whether the default setting had any G.INP involvement?
If it did not, would you really want to drop your SNR to trigger DLM to turn on G.INP on your line?
-
If anyone wants to see a sudden rise in SNRM/Attainable try this :o
...
It was a two-hour power loss in the area which left the line between me and the cab (~800m) apparently with no other active users (I'm on a UPS )
I believe I have seen a similar power-loss event, but my modem wasn't on a UPS so it re-synced. But the QLN data that the modem held onto after the resync showed a suspicious change in the noise environment, suggesting that none of the neighbouring modems were synced at the time...
-
I see similar events whenever we have a power cut (not on a UPS).
We know the Huawei HG612 syncs very quickly (usually less than 20 seconds for an 'on the fly' resync).
I assume that other non-HG612 VDSL2 modems & ADSL modem/routers that are causing the crosstalk issues in my area obtain sync a little slower.
Prior to seeing the effects of crosstalk, Attainable DS rate for my connection was up to 35 Mbps, with sync speeds (Interleaved) at around 30 Mbps.
Nowadays, Attainable is usually not much more than 20 Mbps (fastpath), with sync speed pretty close to Attainable.
See the attached examples showing increased Attainable & sync speeds.
As they were both lower than my pre-crosstalk days, I assume some connections had also synced quite quickly (maybe other HG612 VDSL2 connections).
My connection held on for a few days with very low SNRM before resyncing at the usual speeds (the other non-HG612 modems must have synced shortly after mine).
Similar effects are seen following the every occasional power cuts we experience where I live.
-
Just for reference, I have attached the FULL__Monty montage for that period to show all the various error counts etc.
We can see that my connection is on fastpath these days, but some DS FECs can be seen, indicating that PhyR is now active on my connection.
Edit:
Note the expected increase in some error counts & 'interesting' decrease/lack of some during that period.
It appears that all DS RS was OFF during the period.
-
Finally, see the attached snapshot examples ('normal' stats from before the power cut, at the resync just after the power cut & after the connection resynced again after hanging on with very low SNRM for a few days.
The temporary improvement in QLN is very noticeable (still not quite as good as it was pre-crosstalk days though).
-
As an experiment to see if it's useful, a couple of days ago I changed the larger of the MyDSLWebStats All User Stats displays to show, by highlighting the two values (downstream only currently), anyone who has an FEC count > 0 and with Interleaving set to 1 that might indicate G.INP is running on the line.
There is one user at the moment with consistent FEC counts in the 600-2000 area and no Interleaving. As of today, at least four others now pop up occasionally [several attached] (including yourself).
Both cab types are affected.
-
Just for reference, I have attached the FULL__Monty montage for that period to show all the various error counts etc.
We can see that my connection is on fastpath these days, but some DS FECs can be seen, indicating that PhyR is now active on my connection.
Edit:
Note the expected increase in some error counts & 'interesting' decrease/lack of some during that period.
It appears that all DS RS was OFF during the period.
Is 'bearer 1' showing up on your stats output, not just bearer 0? If so then it's extremely likely that G.INP is active (not to be confused with PhyR, a technology unique to Broadcom DSLAM and modem chipsets paired together).
-
Is 'bearer 1' showing up on your stats output, not just bearer 0? If so then it's extremely likely that G.INP is active (not to be confused with PhyR, a technology unique to Broadcom DSLAM and modem chipsets paired together).
No. It's still showing Bearer 0 at the moment.
I have seen mention of Bearer 1 being in use on some connections, so I'm keeping an eye open for when/if it appears.
From what I can gather, G.INP is only applied if a connection actually needs it.
Maybe mine doesn't need it at the moment?
I have seen lowish FEC counts ever since my connection was switched to fastpath (quite a long time ago).
So I assumed that was proof that my HG612's Broadcom chipset is now making use of the PhyR technology.
-
I see. Unfortunately as I understand G.INP, bearer 1 must be active as retransmission is used via bearer 1 (which will have some INP and delay in comparison to bearer 0 which should be fastpath still). In addition to bearer 1 showing up, on the same stats output you'll see G.INP framing parameters output as well as the number of ReTx's corrected, uncorrected and what not. I'm eagerly waiting for G.INP to show up on mine as I believe it would work much better than the traditional interleaving.
-
Just for reference, I have attached the FULL__Monty montage for that period to show all the various error counts etc.
We can see that my connection is on fastpath these days, but some DS FECs can be seen, indicating that PhyR is now active on my connection.
Edit:
Note the expected increase in some error counts & 'interesting' decrease/lack of some during that period.
It appears that all DS RS was OFF during the period.
Is 'bearer 1' showing up on your stats output, not just bearer 0? If so then it's extremely likely that G.INP is active (not to be confused with PhyR, a technology unique to Broadcom DSLAM and modem chipsets paired together).
now I am confused, I asked if phyr and g.inp are the same and the answer was yes, but you saying they not?
-
Just for reference, I have attached the FULL__Monty montage for that period to show all the various error counts etc.
We can see that my connection is on fastpath these days, but some DS FECs can be seen, indicating that PhyR is now active on my connection.
Edit:
Note the expected increase in some error counts & 'interesting' decrease/lack of some during that period.
It appears that all DS RS was OFF during the period.
Is 'bearer 1' showing up on your stats output, not just bearer 0? If so then it's extremely likely that G.INP is active (not to be confused with PhyR, a technology unique to Broadcom DSLAM and modem chipsets paired together).
now I am confused, I asked if phyr and g.inp are the same and the answer was yes, but you saying they not?
I'm trying to find the information again that I once find sometime ago regarding the differences between PhyR and G.INP, but G.INP is just the standardised variant of Broadcom's PhyR (where PhyR only works when both the DSLAM chipset and modem chipset are Broadcom and PhyR capable). In such event that PhyR isn't available then G.INP is the fallback. I'll edit this post again if I can find the information stating the comparison.
-
just gets worse and worse for us ECI dslammers.
-
Well, shouldn't matter because BT are using the G.INP ITU standard. I can't find the information which I found sometime (year or more possibly) ago again, I should've bookmarked it. However looking at current information through Google I can't find a significant difference in the two technologies, only that G.INP is an ITU standard based on PhyR and that PhyR is a trademark by Broadcom and designed to work in tandem with paired equipment using a Broadcom chipset with PhyR capability. I'll keep looking.
-
just gets worse and worse for us ECI dslammers.
One of the ones that shows up on MyDSLWebStats is on ECI though (not BE1) ...
-
Just to add..............
I think the connection stats I have seen with Bearer 1 in use were from either a Billion or a ZyXel modem i.e. not a HG612 as I use.
I am connected to a Huawei DSLAM though.
-
Thats my understanding too - Its the same thing.
The technology was originally invented by Broadcom which they trademarked as PhyR and at first it was only available on Broadcom equipment.
In 2010 the ITU approved and standardised it as G.INP (G998.4) so it could be used on all equipment.
It may also be known as ReTransmission (or ReTX by BT).
-
It looks like the old name was PhyR, a technology originally by Broadcom sometime before G.INP was standardised based on PhyR - now currently called G.INP. I still can't find the information I had once found so perhaps that information in itself was incorrect (and later on removed from existence).
Anyway, to conclude I believe G.INP is fundamentally the same technology as PhyR - just that PhyR is the old name trademarked by Broadcom and so the correct and current name is G.INP.
-
Strictly, I think the proper name since standardisation is G.998.4, while G.INP was the provisional name during the standardisation process (similar to G.vector and G.993.5). While Broadcom came up with the PhyR idea, and had their own product based on it, I'd guess that standardisation has changed the implementation somewhat.
Also note that it is technically feasible for FEC to be turned on without interleaving - resulting in D=1, but for RScorr and RSuncorr to accumulate - with nothing to do with G.INP. If the RScorr and RSuncorr are accumulating due to the FEC process alone, you'd expect to see D=1 and R>0. It isn't going to be as effective as when interleaving is also activated, but it still works. I've seen it happen plenty of times on the upstream, but (IIRC) only once downstream (and if I am wrong, then it is zero times).
It'd be interesting to see what the values are for "INP" (and INPrein, if it is shown), "delay" and "R" when the "FEC errors without interleaving" scenario is happening downstream.
-
From what I can gather, G.INP is only applied if a connection actually needs it.
Ummm using RS first would basically negate the potential bandwidth gains to the end-user but BT don't seem too keen on vectoring which maybe is down to overall backbone network capacity problems so they may not care at this stage.
From what I know of the vectoring rollouts in other EU countries the gains are significant in terms of sync speeds - very significant in comparable infrastructure countries like Ireland. BT would probably have to offer a 120Mbps down/20Mbps up service which may be why they're behind every country in the EU bar Greece (IIRC) in terms of vectoring deployment/trials.
Sky's core network hit 2.1Tbps at 11am on xmas day (110% increase on previous year IIRC) so what was BT's core network like given they have the bulk of the VDSL2 customers?
There are very few technical reasons why BT shouldn't be a LOT further along the vectoring path. Probably a lot of beancounter reasons though - like all the cabs they'll have to retrofit?
Interestingly the good Rev's speedtester (sod.ms/fast) is now reporting a consistent burst rate of 79-80Mbps whereas a few weeks back (before a remote resync on the Sky SR102) it was around 75Mbps. I use sod.ms/fast because its unlikely to feature in the traffic prioritisation lists of the larger ISPs - the test is very basic but there's more than enough bandwidth on the server end so you can see fluctuations.
Oh and I've just noticed that my connection latency (ping) has dropped to 7ms from 9ms so I guess the last SR102 f/w upgrade & then the forced resync suggest g.INP is active. The Sky router means I can't see if that's the case but frankly it works well enough (I don't use wireless) that I cba to change it even out of curiosity.
-
Yeah WWWombat, you're right - G.998.4 is the real name for G.INP. I guess most people will still call it G.INP instead of that though as it's easier to remember than numbers I guess.
I too have had FEC once or twice while being fastpath (on downstream), and get FEC on the upstream. It seems to have happened here when I have had a high SNRM (e.g. at least around 14.0 dB or higher) - obviously no G.INP/G.998.4 at the time.
-
It'd be interesting to see what the values are for "INP" (and INPrein, if it is shown), "delay" and "R" when the "FEC errors without interleaving" scenario is happening downstream.
These are mine (quite low FEC but D = 1 for DS & US):-
D: 1 1
R: 16 12
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 4.15 17.25
OR: 61.63 26.88
AgR: 22460.42 4939.47
-
I see you are getting ready for G.INP though when it hit's your line you won't even notice the change and I suspect the same will happen when vectoring goe's live it's my belief your putting to much faith into the two different OpenReach technology's (your waiting for the eureka moment)
It may be more subtle than you think it should be on your line :-\
-
rizla they would not have to increase max speed, but I agree the likely reason for vectoring delays is due to accounting. From what BS posted the other day, it would seem vectoring is going to happen for huawei cabinets, as they just need an addon card but not for ECI which would need entire dslam replacing.
-
That'll be a pain, ECI being excluded from vectoring (for an unknown time, assuming if they ever consider their users stuck on an ECI DSLAM).
-
As far as I am aware, the Huawei cabinets are fitted with either a SmartAX MA5603 or a SmartAX MA5616 MSANs and the ECI cabinets are fitted with a Hi-FOCuS Mini-Shelf M41 MSANs. (They are all MSANs but are just configured to be used as basic DSLAMs.)
A MA5603 equipped cabinet will just require the fitting of a vectoring engine card into the relevant slot of the backplane.
A MA5616 equipped cabinet will require the fitting of an expansion card-cage and backplane thus allowing a vectoring engine card to be installed.
In the case of a M41 equipped cabinet the line card(s) can be configured to support vectoring (I believe Kitz understands the process as "on-card vectoring"). The alternative would be to remove the Mini-Shelf M41 and fit a Vectoring-Shelf V41 in its place. Once the cabinet has been upgraded, a vectoring engine card can then be inserted into the appropriate slot of the backplane.
-
so the ECI website is wrong where it doesnt state it supports vectoring? Although vectoring at a card instead of node level can be ineffective if noisy pairs are on different cards.
-
Just noticed two people inside the fibre cab over the road with a lot of equipment, I wonder what they're up to - can only assume it's possibly some upgrade work maybe ;)?
(Cabinet is ECI)
-
Just noticed two people inside the fibre cab over the road with a lot of equipment, I wonder what they're up to - can only assume it's possibly some upgrade work maybe ;)?
(Cabinet is ECI)
My! They must be getting up close and personal, and wanting to produce something. >:D ::) ;D
-
Just noticed two people inside the fibre cab over the road with a lot of equipment, I wonder what they're up to - can only assume it's possibly some upgrade work maybe ;)?
(Cabinet is ECI)
My! They must be getting up close and personal, and wanting to produce something. >:D ::) ;D
Haha, I can only hope that it might be preliminary work for vectoring later on (or if what BS's limited info gave an indication of a while ago, that vectoring may start rolling out from February). I'm highly doubtful it is related to that though.
-
D: 1 1
R: 16 12
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
I should have asked for N as well :-[
The "R" value suggests that you have FEC protection running downstream as well as upstream, using R parity bytes in each block of N bytes. That probably explains the presence of FEC errors, but doesn't give us any indication of why the modem has chosen to do this. In your case, it doesn't look like you have an excess of capacity ... unless you are banded. I don't recall you being banded though.
-
Full stats:-
xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 5077 Kbps, Downstream rate = 23916 Kbps
Bearer: 0, Upstream rate = 4912 Kbps, Downstream rate = 22399 Kbps
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
Medley Phase (Final) Band Plan
US: (7,32) (871,1200)
DS: (33,859) (1216,1764)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 5077 kbps 23916 kbps
Actual Aggregate Tx Power: 6.6 dBm 12.7 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 8.0 52.9 N/A N/A N/A 21.6 65.0 N/A
Signal Attenuation(dB): 8.0 52.0 N/A N/A N/A 30.3 64.7 N/A
SNR Margin(dB): 6.7 6.4 N/A N/A N/A 7.1 7.1 N/A
TX Power(dBm): -1.5 5.9 N/A N/A N/A 11.6 6.3 N/A
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 5077 Kbps, Downstream rate = 23916 Kbps
Bearer: 0, Upstream rate = 4912 Kbps, Downstream rate = 22399 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 6.5
Attn(dB): 24.4 0.0
Pwr(dBm): 12.7 6.6
VDSL2 framing
Bearer 0
MSGc: 26 52
B: 237 143
M: 1 1
T: 49 37
R: 16 12
S: 0.3378 0.9293
L: 6016 1343
D: 1 1
I: 254 78
N: 254 156
Counters
Bearer 0
OHF: 472100263 865751
OHFErr: 48715 385
RS: 1658064624 693178
RSCorr: 3436839 978
RSUnCorr: 250118 0
Bearer 0
HEC: 213145 0
OCD: 15868 0
LCD: 15868 0
Total Cells: 2837159271 0
Data Cells: 541078294 0
Drop Cells: 0
Bit Errors: 0 0
ES: 23825 357
SES: 63 0
UAS: 22 22
AS: 1961038
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 4.15 17.25
OR: 61.63 26.88
AgR: 22460.42 4939.47
Bitswap: 1267638/1267643 5652/5660
Total time = 1 days 16 hours 44 min 20 sec
FEC: 3436839 978
CRC: 48715 385
ES: 23825 357
SES: 63 0
UAS: 22 22
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 14 min 20 sec
FEC: 34 0
CRC: 17 0
ES: 8 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: 17 0
CRC: 10 0
ES: 8 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 16 hours 44 min 20 sec
FEC: 3322 22
CRC: 1019 11
ES: 683 11
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 7158 11
CRC: 1518 9
ES: 992 8
SES: 1 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 22 days 16 hours 43 min 57 sec
FEC: 3436839 978
CRC: 48715 385
ES: 23825 357
SES: 63 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
FWIW, my connection has managed to sustain DS fastpath with lowish FEC counts since 26th August 2014.
Prior to that it could only sustain a few days on fastpath (following DLM resets) before having Interleaving applied at a depths of around 350 to 400, with INP at 3.00 & delay at 8.
The slight amount of spare DS SNRM comes with reduced temperatures at this time of year as Line & Signal Attenuation always increase in summer & decrease in winter, certainly on my connection:-
-
I don't think I've checked attenuation graphs like that over the course of a year. Interesting!
Looking at the full stats, I can see:
Downstream, the FEC has been applied at the rate of 16/254, or about 6% - and that must be about the smallest overhead it could have. The impact is pretty effective: 93% of RS problems are being corrected - only 7% go on to trigger full CRC faults. I'm trying to figure out *why* FEC is being so effective without interleaving present...
As your daily ES count seems to reach 1,000, it seems like this FEC setting is doing a good job at keeping you under the ES thresholds for further intervention.
Obviously INP and "delay" are still set to zero, so DLM has not asked for FEC (using those parameters, anyway); I think I might have to investigate what some of the other parameters mean (PER, OR and AgR are probably good starting points).
Upstream has a small surprise... that the value of I and N are not the same. I should be a sub-multiple of N (which is true here), but it only has real meaning when interleaving is turned on (I is the 2nd dimension of the interleaving matrix, when D is the 1st dimension). You don't often see it being less than N even when interleaving is turned on, so this is a surprise.
The FEC setting for upstream is slightly stronger than downstream (12/156, or 8%), and the stats say that there were zero RSuncorr - so this setting is effective. However, they also say that OHFerr was 385 - which is odd when RSuncorr is zero!
I think your FEC counts are happening because the FEC process is turned on, rather than an indication of G.INP involvement. But *why* they are turned on is another matter...
-
I don't know what PER means, but AgR I believe is the aggregate rate and OR is the overhead rate. Beyond that you'll need to look up what purpose they serve. AgR is presumably the total rate of all OR and such on top of the actual sync rate. I think one responsibility of the OR is to communicate certain things with the DSLAM, such as the error counters or when to do bitswapping and for what bits - for example.
-
I believe this has been enabled on my line?..
Path 0
INP: 3.00 0.00
PER: 2.63 16.17
delay: 8.00 0.00
OR: 72.91 19.29
Interleave is also on, but that was triggered when OR were here disconnecting it a lot and never reset the DLM when they left :o INP seems to have just appeared as 3
-
I had 2 resyncs yesterday afternoon, currently no idea what caused them,, but I dont appear to be on a new DLM profile, was close to 100 days uptime, shame. Given both were within 10 mins of each other I suspect an engineer at the cab.
--edit--
My US snrm has dropped a bit so I wonder if was the DSLAM enforcing a new UPBO.
-
I had 2 resyncs yesterday afternoon, currently no idea what caused them,,
Odd it looks like a retrain reason 0 which is what you get when you turn off the modem for 30 minutes and then on again LOS: Loss of Service and only see 1 resync on MDWS at 16:16 27/1/2015 :-\
-
it might have only been 1 but I had 2 email alerts from the site.
-
to check when I think my line was on G.INP, check on MDWS my username for first week of sept when I had low attianable before my fault was fixed, I Was on fast path on the DS with FEC enabled.
-
To my knowlage my connection when on fastpath (90%+ ) of the time has always had FEC enabled on the upstream only
-
Seems it has kicked in on my connection now. I was always on fast path before, my pings seem unaffected (Please not my first hop has always been high as its the plusnet gateway in London and I am in north Wales so the first hop is actually most of the country.
This is on a HG612 unlocked using H-Wolfs build.
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 38593 Kbps, Downstream rate = 103048 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79999 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): 12.3 17.9
Attn(dB): 12.3 0.0
Pwr(dBm): 13.6 1.9
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 130 97
M: 1 1
T: 0 0
R: 8 8
S: 0.0518 0.1554
L: 21468 5457
D: 16 8
I: 139 106
N: 139 106
Q: 16 8
V: 14 2
RxQueue: 60 39
TxQueue: 20 13
G.INP Framing: 18 18
G.INP lookback: 20 13
RRC bits: 24 24
Bearer 1
MSGc: 186 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 5.3333 16.0000
L: 48 16
D: 3 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: 0 0
RS: 2734095472 528284
RSCorr: 24893 6707
RSUnCorr: 0 0
Bearer 1
OHF: 47402272 401648
OHFErr: 0 0
RS: 568826521 1371711
RSCorr: 3 6
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 1326 138
rtx_c: 1185 125
rtx_uc: 0 0
G.INP Counters
LEFTRS: 9 2
minEFTR: 79999 19997
errFreeBits: 929025460 232226050
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 1173293021 0
Data Cells: 4255707463 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: 1135 97
SES: 22 0
UAS: 328 306
AS: 761402
Bearer 0
INP: 48.00 47.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 80614.82 20102.08
Bearer 1
INP: 4.00 4.00
INPRein: 4.00 4.00
delay: 3 0
PER: 16.06 16.06
OR: 95.62 31.87
AgR: 95.62 31.87
Bitswap: 570441/570442 632/634
Total time = 1 days 28 min 47 sec
FEC: 24893 6707
CRC: 0 0
ES: 1135 97
SES: 22 0
UAS: 328 306
LOS: 2 0
LOF: 19 0
LOM: 0 0
Latest 15 minutes time = 13 min 47 sec
FEC: 24 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 30 2
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 = 28 min 47 sec
FEC: 54 2
CRC: 0 0
ES: 0 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: 2558 142
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 8 days 19 hours 30 min 1 sec
FEC: 24893 6707
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
HELLO HG612
xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 38593 Kbps, Downstream rate = 103048 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3959)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3959)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 38593 kbps 103048 kbps
Actual Aggregate Tx Power: 1.9 dBm 13.6 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 4.6 15.0 20.4 N/A N/A 7.6 17.6 26.0
Signal Attenuation(dB): 4.6 14.1 19.5 N/A N/A 9.5 17.4 26.0
SNR Margin(dB): 18.0 17.9 17.9 N/A N/A 12.3 12.3 12.3
TX Power(dBm): -12.3 -28.6 1.8 N/A N/A 10.8 7.8 6.9
Good Bye HG612
C:\Users\>tracert google.co.uk
Tracing route to google.co.uk [216.58.210.35]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms router.asus.com
2 17 ms 16 ms 16 ms lo0.10.Central10.ptw-bng02.plus.net [195.166.130
.203]
3 20 ms 16 ms 15 ms irb.10.PTW-CR02.plus.net [84.93.249.2]
4 16 ms 16 ms 16 ms 72.14.223.32
5 16 ms 16 ms 15 ms 209.85.252.188
6 16 ms 16 ms 16 ms 72.14.238.21
7 16 ms 17 ms 16 ms lhr14s23-in-f3.1e100.net [216.58.210.35]
Trace complete.
-
yeah new g.inp fields get added, it be nice if the modem stats tool can be updated to look for these values.
-
yeah new g.inp fields get added, it be nice if the modem stats tool can be updated to look for these values.
once HG612_Modem_stats crashes then you will know G.INP is active on your line ::)
-
newt get a DLM reset and I bet you get g.inp instead of normal interleaving :)
-
I'm hoping to get G.INP once I get up to the top of the long ladder my connection's in at the moment. 49Mbps cap at INP 7 with a maximum delay of 16ms (actual 11ms) on downstream, but about two days ago DLM made a positive change for the first time in a while since unplugging the ASUS. It was INP 8 with a 44Mbps cap before the positive change.
Currently using the Fritz!Box 7490 which is working quite nicely. Also reports whether G.INP is active or not via the web UI, and I've just found out how to get more detailed stats from telnet earlier this evening (if curious then see here (http://forum.kitz.co.uk/index.php?topic=15004.msg279722#msg279722) for the output and some graphs I made for QLN and such). I doubt I'll be returning to the ASUS and will probably keep that in storage.
-
newt get a DLM reset and I bet you get g.inp instead of normal interleaving :)
I am flipping trying my best mate have an open case being looked into by openreach at least the voice interference has been noted by the ISP operator :fingers:
-
Seems it has kicked in on my connection now. I was always on fast path before, my pings seem unaffected (Please not my first hop has always been high as its the plusnet gateway in London and I am in north Wales so the first hop is actually most of the country.
This is on a HG612 unlocked using H-Wolfs build.
Do you have any equivalent output (--stats and --pbParams) from before G.INP kicked in? It'd be educational to compare them...
-
Hi unfortunately this is all i could find, Its the graphs and modem stats log. Unfortunately i don't have a Plink log or equivalent from before (i must have deleted them)
https://mega.co.nz/#!HU9S0LrR!BpIR_xRbAbVGjUzx4jIciXm_ZUEILlR3FJK9kQpNDE4 (5.4MB)
-
Thanks.
I'll try to work through them with a copy of the spec, and see what I can work out!
-
I had a resync last night and I'm now seeing INP at 5 (from 3), and interleave depth is at 973, opposed to 509 yesterday.
However, I'm now syncing just over 3000kbps higher with a higher snr margin :-\
Yesterday - (When I last checked about 3pm) Sync - 35248kbps, SNR hanging around 3.2
Today - 38464kbps, SNR 5.7. Max attainable has jumped up to 42628kbps too
I know I need to setup 24/7 monitoring to see what's going on with my line properly it's just getting round to setting it all up ;D
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 7035 Kbps, Downstream rate = 42628 Kbps
Path: 0, Upstream rate = 7040 Kbps, Downstream rate = 38464 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 5.7 6.0
Attn(dB): 0.0 0.0
Pwr(dBm): 12.0 3.6
----- SNIP -------------
INP: 5.00 0.00
PER: 2.92 16.21
delay: 16.00 0.00
OR: 65.55 19.24
-
Unfortunately nothing in the information you have posted indicates that G.INP is active on your circuit. :no:
-
Unfortunately nothing in the information you have posted indicates that G.INP is active on your circuit. :no:
But it does indicate it is still using an old firmware version.
"Path: 0, Upstream rate = 7040 Kbps, Downstream rate = 38464 Kbps"
I wonder if it firstly needs to be updated to the current version in order to make the most of & to report whether G.INP technology has been enabled or not.
-
But it does indicate it is still using an old firmware version.
"Path: 0, Upstream rate = 7040 Kbps, Downstream rate = 38464 Kbps"
I wonder if it firstly needs to be updated to the current version in order to make the most of & to report whether G.INP technology has been enabled or not.
Good idea. I didn't take any notice of the firmware version.
-
I didn't even know there was an update! I'll look into getting up updated tonight.
I thought the INP 5 indicated it was active ???
-
BT have enabled G.INP on my line on a 288 huawei cab. My line is 20 meters from the cab on a new estate and BT have manged to screw up a 3 year old perfect max sync fastpath line.
Since the Update my ECI modem will not connect properly and when it does its running really SLOW with a 30ms ping increase! up from 9ms to 40+ to BBC.
How can BT screw mine line up sooo much?
-
Anecdotal evidence suggests the extra latency could come when the modem can't support G.INP; however, this has applied more to Huawei modems - where it is solved by flashing with new firmware (the B030SP08 seems to be OK).
Reports from inside BT suggests that ECI modems with firmware that isn't compatible with G.INP won't even sync, but perhaps they've discovered a workaround to get the sync but perform badly ... after which, an automatic firmware upgrade can happen.
Your other posts suggest you have an HG612 modem too. Can you make sure it has the right firmware, and put it back on?
-
I think i had a update to my street cabinet yesterday around 1pm, only found out when i was doing some speed test later on last night and i lost 10mbps from 73mbps and latancy jumped up abit, i'm on plusnet no matter what i do i can't get back my original speed its now stuck at 63mbps.
I tried rebooting my asus RT-N66U and tried to drop session a number of times, nothing helps.
The modem i use is a ECI telecom, BT engineer brought when i first had FTTC installed.
-
Rebooting your router or dropping session will not change your sync speed.
DO NOT REBOOT YOUR MODEM unless you have to as DLM will see the reboots as possible issues on the line.
DLM will then make changes to your line to correct the 'fault' it sees. (Usually lower sync speed and/or interleaving is applied)
Are you able to get proper stats from your modem using DSLStats or HG612 stats etc
(See: Router Monitoring Software under Broadband Related in this forum) ?
-
No not able to get into the modem stats, its locked down.
Yes i know about not touching the modem, going to wait at least 2 weeks before i do anything with my modem.
I guess i could buy one of those all in one modem/routers like a Billion BiPAC 8800AXL (or the cheaper model 8800NL) or Asus DSL-AC68U, all i want is my speed back to what its been like for the last 2 to 3 years now, rock solid stable speed.
Don't know what to do, the staff on plusnet said my line as no DLM on it, so why as it drop 10mbps since sunday.
-
I have a 10 Mb/s up/down change in sync and attainable on my line if a nearby property powers down/up. 10Mb/s could just be cross talk.
-
There does appear to be an emerging amount of users with ECI modems who are seeing a fairly substantial decrease in speed after their line has been enabled for g.inp. The problem is that because there are very few people who are able to provide stats from an eci modem, without these we are the dark as to what is going on for the line.
the staff on plusnet said my line as no DLM on it, so why as it drop 10mbps since sunday.
It may be interesting to see if you can get your profile from Plusnet. g.inp enabled lines should show up as something like
'0.128M-80M Downstream, Retransmission Low - 0.128M-20M Upstream, Retransmission Low
Another indication may be increased latency, but not showing up on the DLM profile. More info from AAISP
https://aastatus.net/search.cgi?search=retx
-
The speed banding on the profiles changed around the time when BT lost the court case regarding DLM (patents?) with ASSIA. I thought I recall reading that a line with G.INP actually showed something along the lines of 'retransmission low' or 'retransmission high' when G.INP is enabled on the line?
-
Ixel has it ....... :)
A 'paste' of a profile of a circuit I was working on yesterday .......... '0.128M-80M Downstream, Retransmission Low - 0.128M-20M Upstream, Retransmission Low
-
Oops, sorry my bad, I was misinterpreting something on the PN forums then. Im a wee bit in the dark being on an ECI cab, so I'll edit my post. :-[
However, there certainly does appear to be some issues starting to emerge for some people using ECI modems after g.inp has been enabled. Those using BCM devices seem to have seen benefits such as reduced latency, higher speeds, higher SNR etc. Those with the ECI modems are complaining of high latency and reduced speeds. AAISP has also picked up on this (https://aastatus.net/search.cgi?search=retx) and reported it to BT.
Another comment in the same thread, has made me wonder if it could be something to do with this (http://forum.kitz.co.uk/index.php/topic,15205.msg282608.html#msg282608) reported by BS and why BT are swapping out the VCMMs.
-
I have been querying about this, suspecting new profiles, as I have been pushed down to a profile that is slower than I had for past 6+ months:
0.128M-67M Downstream, Retransmission Low - 0.128M-20M Upstream, Retransmission Low
I was usually on 79897/19999 now on 66999/20000 for past 3 weeks with no change up or down.
G.INP change happened at the same time as a HR fix by OR Engineer, promised DLM reset but not convinced it happened.
OR Engineer said that the line outside my house at the JF4 (Jointbox at bottom of drive) was testing at 79xxx yet could only get 70M and has not changed to date.
Not just ECI as I am on Huawei DSLAM with Zyxel 8324 modem. (OR fix was using a HG612, swapped back to Zyxel after.)
Wondering if OR are detecting 'non-supported' modems and defaulting to a 'safe' profile.
Not daring to change to a HG612 in case DLM take umbrage.
Most interested in what the story is from BT/OR.
I am on a 64 M profile yet got a 72M speedtest from the BTW Speedtest site ??? !!!
Not a happy bunny >:(
-
Not one for monitoring my stats, as regulars will know, but I've just viewed my circuit using WHOOSH and I was G.INP'd on 27/03/15 and have gained 10Meg synch speed on my DS.
-
I spoke to a local BTOR guy last week. He only had ECI modems in the van.
Pretty sure the entire county is sporting BDCM cabs...
-
Oops, sorry my bad, I was misinterpreting something on the PN forums then. Im a wee bit in the dark being on an ECI cab, so I'll edit my post. :-[
However, there certainly does appear to be some issues starting to emerge for some people using ECI modems after g.inp has been enabled. Those using BCM devices seem to have seen benefits such as reduced latency, higher speeds, higher SNR etc. Those with the ECI modems are complaining of high latency and reduced speeds. AAISP has also picked up on this (https://aastatus.net/search.cgi?search=retx) and reported it to BT.
Another comment in the same thread, has made me wonder if it could be something to do with this (http://forum.kitz.co.uk/index.php/topic,15205.msg282608.html#msg282608) reported by BS and why BT are swapping out the VCMMs.
Yeah, this might be due to the mismatching chipset.
as a bcm device is a bcm to bcm connection.
Advanced tech on xDSL seems to always get problematic when chipset's mix, so makes me a bit concerned about those of us on ECI cabs using BCM modems, will we hit similar issues.
-
FWIW, it also seems that users with unlocked HG612s, but with older firmware versions & remote BTOR updates blocked are seeing similar issues as soon as G.INP is activated at their Huawei cabinet DSLAM.
i.e. The modem will sync, but at a quite heavily interleaved depth & thus reduced sync speeds.
The 'fix' appears to be upgrade the HG612 to the latest firmware version which does appear to be G.INP ready.
I have never blocked BTOR updates on my HG612 & despite losing the GUI (which I don't personally need), the transition to G.INP was very smooth/instant.
I haven't seen much in the way of improved speeds etc. but my connection does still appear to be capped at 22.4Mbps/5Mbps sync speeds, no doubt due to crosstalk over 1100m or so of copper.
However, I do now see incredibly few error seconds and incredibly few CRCs.
However, due to the low levels of interleaving now applied to my previously fast path connection, I do see a fair few FEC, the 'new' LEFTRS, rtx_tx, rtx_c & an occasional rtx_uc counts.
There is quite a difference between Line Attenuation & Signal attenuation, but nobody seems able/willing to tell me whether that is due to perhaps being on a 'stable' profile or not.
Maybe DLM will relent in due course?
-
Not one for monitoring my stats, as regulars will know, but I've just viewed my circuit using WHOOSH and I was G.INP'd on 27/03/15 and have gained 10Meg synch speed on my DS.
Thats how 'G.INP is supposed to work' in everyones mind. ;D
As per Life of Brian "You lucky, lucky bastard." :D ;D
Can I ask what sync you were on before ?
-
FWIW, it also seems that users with unlocked HG612s, but with older firmware versions & remote BTOR updates blocked are seeing similar issues as soon as G.INP is activated at their Huawei cabinet DSLAM.
The 'fix' appears to be upgrade the HG612 to the latest firmware version which does appear to be G.INP ready.
Does this imply that if you are not running the latest firmware and/or running the BT Agent DLM is taking a safe option that is 'G.INP safe and possibly also Vectoring Safe'
Of course if you are NOT running a HG612 or ECI modem this means you are hit, by default.
For my Information: What is the correct firmware version ?
I am tempted to put my HG612 back with the correct setup to see if things improve.
-
FWIW, it also seems that users with unlocked HG612s, but with older firmware versions & remote BTOR updates blocked are seeing similar issues as soon as G.INP is activated at their Huawei cabinet DSLAM.
The 'fix' appears to be upgrade the HG612 to the latest firmware version which does appear to be G.INP ready.
Does this imply that if you are not running the latest firmware and/or running the BT Agent DLM is taking a safe option that is 'G.INP safe and possibly also Vectoring Safe'
Not sure about vectoring, but it certainly does 'seem' to confirm the need to update (and/or allow remote updates) to the latest firmware version for HG612s.
Of course if you are NOT running a HG612 or ECI modem this means you are hit, by default.
Not necessarily.
I have seen stats from Billion & ZyXel modem users where G.INP has been satisfactorily activated.
I suppose it does depend which firmware versions they are using though.
For my Information: What is the correct firmware version ?
I am tempted to put my HG612 back with the correct setup to see if things improve.
These are the G.INP compatible versions for the HG612:-
equipcmd swversion display
software version: V100R001C01B030SP08
xdsl firmware version: A2pv6C038m.d24j
cpu version: BCM6368
cfe version: 1.0.37-102.6
-
Many Thanks. BE1
[Non-trusting OR mode on ;D]
I mentioned vectoring as the issue with the 'right' modem and G.INP is exactly what is going to raised when/if vectoring is enabled.
All the 'non-OR sanctioned' modems in use are beyond their control.
Some of these may be Vectoring non-friendly and would impact the effectiveness of the vectoring itself.
It would be very useful to 'force' change now when G.INP is rolled out and avoid issues with vectoring later.
All the 'Vectoring non-Friendly' modems could be flagged up now and a view taken of the numbers/distribution & possible impact.
[Non-trusting OR mode off ;D]
I am not a very trusting soul at times. ;D
I'll put my tin foil hat back on now. ;) ;D
-
Not one for monitoring my stats, as regulars will know, but I've just viewed my circuit using WHOOSH and I was G.INP'd on 27/03/15 and have gained 10Meg synch speed on my DS.
Thats how 'G.INP is supposed to work' in everyones mind. ;D
As per Life of Brian "You lucky, lucky bastard." :D ;D
Can I ask what sync you were on before ?
Ha ha ..... I'm wondering if it's because I can view my stats if I wished to, on WHOOSH, rather than having to 'crack' the modem ??? Anyhows, there's a picture attached of my stats pre and post G.INP.
Apologies for the size/quality ..... it's not my forte buggering about with pictures. :-[
-
Apologies for the size/quality ..... it's not my forte buggering about with pictures. :-[
I've tried (on your behalf) . . .
-
Thank you, sir. Appreciate your efforts. :)
-
I spoke to a local BTOR guy last week. He only had ECI modems in the van.
Pretty sure the entire county is sporting BDCM cabs...
There was a time about 18 months ago for a while whereby there was a distinct shortage of the Huawei modems and ECI's were being dished out regardless of which cab you were on. I think BS may have posted at around that time that BT had stopped matching equipment as they had decided it didnt really matter. The contractor who initially installed my fttc connection only had ECI modems on his van.. I asked because I specifically wanted a HG612, only to be told they were only being given ECIs by BT.
-
Not one for monitoring my stats, as regulars will know, but I've just viewed my circuit using WHOOSH and I was G.INP'd on 27/03/15 and have gained 10Meg synch speed on my DS.
Nice result there Mr BlackSheep :)
-
Yeah, this might be due to the mismatching chipset.
as a bcm device is a bcm to bcm connection.
Advanced tech on xDSL seems to always get problematic when chipset's mix, so makes me a bit concerned about those of us on ECI cabs using BCM modems, will we hit similar issues.
BCM's have always seemed to perform much better on my line, and Im on an ECI cab. Even when with Be* on an Alcatel ISAM, BCMs worked best.
-
I spoke to a local BTOR guy last week. He only had ECI modems in the van.
Pretty sure the entire county is sporting BDCM cabs...
There was a time about 18 months ago for a while whereby there was a distinct shortage of the Huawei modems and ECI's were being dished out regardless of which cab you were on. I think BS may have posted at around that time that BT had stopped matching equipment as they had decided it didnt really matter. The contractor who initially installed my fttc connection only had ECI modems on his van.. I asked because I specifically wanted a HG612, only to be told they were only being given ECIs by BT.
As always, the boss is correct. Our 'Stores' only despatch ECI Modems due to the powers-that-be dictating there was no noticeable difference with mismatched vendors equipment.
-
Yeah, this might be due to the mismatching chipset.
as a bcm device is a bcm to bcm connection.
Advanced tech on xDSL seems to always get problematic when chipset's mix, so makes me a bit concerned about those of us on ECI cabs using BCM modems, will we hit similar issues.
BCM's have always seemed to perform much better on my line, and Im on an ECI cab. Even when with Be* on an Alcatel ISAM, BCMs worked best.
on basic sync speed i agree, but we are not using things like SRA and g.inp currently.
on ukonline I remember SRA only worked with conexant chipsets. The dslams were conexant.