|
|
|
My connection resynced with Retrain Reason 1 at 00:49, 11th August.
I only noticed yesterday that the Chipset version changed to 0xa459 from 0xa44f
I can't see any significant differences in performance or my connection stats, but I wonder if this could be pre-preparation for Vectoring?
|
|
|
Mine is still 44f
The indispensable man or woman passes from the scene, and what happens next is more or less the same thing as was happening before.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 57584/13846kbps @ 600m. - BQM
|
|
|
|
Vectoring doesn't need new line cards on Huawei kit. A rapid Google indicates that chipset ID has been around since February. No evidence that the chap who posted it is on the vectoring pilot now.
Vectoring on Huawei is adding a vectoring engine board, the existing VDSL line cards should remain untouched.
That said the line cards are FPGAs, so a software upgrade could increment the chipset version, as could simple software misreporting. No guarantee any hardware change was involved.
I will make some enquiries.
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
|
Also 0xa459 here, changed on Tuesday, Wednesday this week.
|
|
|
Mine is DSLAM/MSAN type:BDCM:0xa459 / v0xa459
Been that way since last re-connect 8 days ago.
Not sure if it was anything different before that tho.
TalkTalk 80Mb
Current Line Stats
Attainable Rate: DL: 101776 UL: 27921
Connection Speed: DL: 79650 Kbps UL: 19999 Kbps
SNR: DL: 8.8 UL: 14.6
Attenuation: DL: 8.8 UL: 2.9
|
|
|
Mine changed from 44f to 459 on 28-Jul. Initially I got a significant increase in sync speed and attainable so my hopes were up re vectoring, but it reverted to the previous values at the next resync when I accidentally powered off the modem.
Kevin
plusnet Unlimited Fibre - sync approx 65000/20000 at 450m - BQM
Using OpenDNS
Domains and web hosting with TSOHOSTEdited by kasg (Sun 16-Aug-15 00:04:06)
|
|
|
|
How many chipset versions are there as mine is different?
Stats recorded 15 Aug 2015 19:47:16
DSLAM/MSAN type: BDCM:0xa485 / v0xa485
Modem/router firmware: AnnexA version - A2pv6F039g1.d24m
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 45 days 12 hours 19 min 47 sec
Resyncs: 0 (since 15 Aug 2015 00:36:14)
Downstream Upstream
Line attenuation (dB): 11.9 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 79999 19999
SNR margin (dB): 7.0 12.5
Power (dBm): 14.0 -0.9
Interleave depth: 16 1
INP: 48.00 0
G.INP: Enabled
RSCorr/RS (%): 0.0074 27.7419
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 0.21
Paul.
|
|
|
|
DSLAM/MSAN type: BDCM:0xa48c / v0xa48c
|
|
|
I wonder if I should do a re-sync tomorrow. Though it's only been up ten days.
The indispensable man or woman passes from the scene, and what happens next is more or less the same thing as was happening before.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 57584/13846kbps @ 600m. - BQM
|
|
|
DSLAM/MSAN type: BDCM:0xa48c / v0xa48c
Same as mine.
Just out of interest, how long has your cabinet been up?
|
|
|
Also 0xa459 here, changed on Tuesday, Wednesday this week.
Changed in the early hours of Wednesday here also.
Looks like a software change. I find it unlikely there are masses of Openreach guys working in the early hours replacing line cards nationwide.
EDIT: Some research indicates that chipset IDs were changing around G.inp rollout time too. This didn't need new line cards either. I have a strong suspicion these IDs are quite a long way from being hard coded.
Either way I can't see how it's a preparation for vectoring. There should be a change request raised against the DSLAM in question, and the vectoring programme manager at Openreach has not indicated a widespread rollout of the technology.
Much as though many would love to see vectoring I think Openreach know that VDSL doesn't have anywhere near the lifespan they were hoping it would, and their plans are centred around G.fast and FTTPoD version 2 with vectoring used to hit local authority coverage targets.
EDIT 2: Add to that that Virgin Media are expanding their coverage again, and in the not too distant future their lowest speed will be faster than FTTC, with their high end package 4 times faster. There is no mileage in spending money speeding up FTTC en masse.
Openreach went for the fastest and cheapest option to deliver higher speeds, it's been proven insufficient for the future by BT's own retail arm and their 4k TV product. Deeper fibre is needed, and/or, depending on distance from node, retrofitting of the DSLAMs or new ones built next to them for G.fast.
Edited by deleted (Sat 15-Aug-15 23:21:58)
|
|
|
I don't suppose it brings back upstream G.INP?
The indispensable man or woman passes from the scene, and what happens next is more or less the same thing as was happening before.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 57584/13846kbps @ 600m. - BQM
|
|
|
I don't suppose it brings back upstream G.INP?
That was a CPE caveat, not a DSLAM one?
EDIT: I guess you're wondering if software changes have been made so that the DSLAM can handle CPE that don't do upstream G.INP by just applying it to downstream and leaving upstream fast path instead of applying interleave to both?
I guess that's possible; however given that this chipset ID was seen as far back as February, way before the issues came to light, it seems unlikely.
Edited by deleted (Sat 15-Aug-15 23:25:53)
|
|
|
Rats!
The indispensable man or woman passes from the scene, and what happens next is more or less the same thing as was happening before.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 57584/13846kbps @ 600m. - BQM
|
|
|
|
Strangely I had G.INP on the upstream and downstream, just under a month ago.
My cabinet (Huawei) was enabled at the end of May so never had G.INP MK1 so it was very odd.
I probably would still have it if I hadn't had DLM reset on a fault...
|
|
|
have you asked this manager about ECI?
It seems anyone with the ability to ask these questions only cares about hauwei  Since you are in a position to ask I would appreciate some answers. Thanks.
Also vectoring isnt that incapable. If they rolled it out and enabled pair bonding, then most FTTC users would be able to reach speeds like 150/50.
The problem with VM of course its all marketing, real performance with their congestion issues is usually quite a bit different.
Of course I dont disagree with you with openreach going for the cheapest option, thats in BT's DNA. I still smile about your payday loan comment as ironically it is right in how they act with investment.
|
|
|
|
Mine still unchanged DSLAM/MSAN type: BDCM:0xa44f / v0xa44f
|
|
|
Just rebooted my modem, still a44f on both.
The indispensable man or woman passes from the scene, and what happens next is more or less the same thing as was happening before.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 57970/13958kbps @ 600m. - BQM
|
|
|
I don't suppose it brings back upstream G.INP?
That was a CPE caveat, not a DSLAM one?
EDIT: I guess you're wondering if software changes have been made so that the DSLAM can handle CPE that don't do upstream G.INP by just applying it to downstream and leaving upstream fast path instead of applying interleave to both?
I guess that's possible; however given that this chipset ID was seen as far back as February, way before the issues came to light, it seems unlikely.
Yes that's what's happening. It just won't be applied when G.INP on the upstream isn't supported by the modem.
|
|
|
|
Yes my understanding is that AT&T use pair bonding on their VDSL2 U-Verse service in The States. Their speeds tend to be lower than ours though even with the bonding so maybe their cabinets are more spaces out.
But I'm not sure why Openreach never went for bonding also.
|
|
|
|
Mine is BDCM:0xa459 / v0xa459, IICRC i think it was 44f previously
|
|
|
|
January 2015
|
|
|
Also BDCM:0xa48c / v0xa48c here - cab went live in mid March 2015.
Just wondering if it's just an incremental software version - e.g. 0xa44f > 0xa459 > v0xa48c, or if there are differences to the hardware used.
I think (although completely unsubstantiated) we're probably on BDUK/newer cabs, if we've got the higher number. Like I say, completely unsubstantiated, just a hunch...
rob | PlusNet
|
|
|
|
BDCM:0xa48c / v0xa48c here as well. On a BDUK cab that went live in April 2015.
|
|
|
|
Sorry but how do you get the chipset version on an unlocked HG612? Couldn't find it in the web gui so guess i would need to telnet the HG612? I'm connected to a Huawei cab.
|
|
|
telnet in as usual
xdslcmd info --vendor
The indispensable man or woman passes from the scene, and what happens next is more or less the same thing as was happening before.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 57970/13958kbps @ 600m. - BQM
|
|
|
telnet in as usual
xdslcmd info --vendor
Thanks, worked a treat! Mine is 0xa459
|
|
|
My parents FTTC Chipset version changed to 0xa459 from 0xa44f this morning on their Netgear DG3700v1
Before:
Max Rate: 78458 / 28769
Sync Rate: 74626 / 19999
SNR: 6.0 / 10.5
Chipset: 0xa44f
G.INP: Enabled
Now:
Max Rate: 79024 / 29648
Sync Rate: 79999 / 19999
SNR: 5.9 / 10.7
Chipset: 0xa459
G.INP: Enabled
That's was a massive difference in sync rate increasing from 74626 to 79999. I am not sure if it was to do with vectoring or g.inp changed? As my parents FTTC huawei cabinet is approx 600m away! Their line is always on 74Meg since June 2014 installed.
See three screenshot here:
1) http://postimg.org/image/mnheexw0b/
2) http://postimg.org/image/fmjaltkvt/
3) http://postimg.org/image/5h9q4kfdh/
Edited by adslmax (Thu 20-Aug-15 17:17:50)
|
|
|
|
Look at the maximum attainable, it's not changed much.
Your parents synched up before some others, so didn't have 'full' crosstalk affecting them. Hence they were able to lock at full rate. As other modems came online their maximum rate has dropped a little back to about the same as before.
Nothing to do with vectoring or G.INP.
|
|
|
|
Mine has been on the newer A459 value for at least 15 days.
I have a vague recollection that a whole batch of Huawei linecards were being swapped, due to some incomparability with BT's line testing system.
The fact Openreach has a programme manager for vectoring tells us how it was once thought of, but I think you're right that focus has moved on.
|
|
|
I guess you're wondering if software changes have been made so that the DSLAM can handle CPE that don't do upstream G.INP by just applying it to downstream and leaving upstream fast path instead of applying interleave to both?
I guess that's possible; however given that this chipset ID was seen as far back as February, way before the issues came to light, it seems unlikely.
Doesn't the DSLAM just implement the settings dictated by the line profile?
The choice of whether retransmission, interleaving and/or error correction are to be used is made by DLM, and configured into the line profile. The DSLAM doesn't make the choice.
|
|
|
|
They haven't changed all of the cards yet. You're right though they cause hand held tester tests to fail every time.
|
|
|
|
It's the handheld testers, then? I thought it was the exchange testers, but the recollection is definitely vague.
|
|
|
|
I recall that there is one type of handheld tester which when used with a Huawei cabinet, detects an earth and throws up a test failure when in fact it isn't an error at all.
|
|
|
|
I am also on BDCM:0xa48c / v0xa48c
FTTC went live on my line on 17 August this year but the FTTC cabinet has been live since April 2012
|
Pages in this thread: 
Print Thread
