Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Bald_Eagle1 on August 14, 2015, 06:41:37 AM
-
My connection resynced with Retrain Reason 1 at 00:49, 11th August.
I have only just noticed 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?
-
Yes my chipset seems different last time i checked.
DSLAM/MSAN type: BDCM:0xa459 / v0xa459
Modem/router firmware: AnnexA version - A2pv6C038m.d24j
DSL mode: VDSL2 Profile 17a
-
firmware update or new DSLAM line card.
-
Mine has gone to 0xa459 too. I don't know when it happened, but there was an unexplained resync in the middle of the night a week or so ago.
-
I've had similar change.
I do not think that is indicative of a firmware upgrade but suspect that the line card has been swapped out -- possibly for a newer revision.
The other, but less likely, reason would be a swap over to a different DSLAM.
If you could have access to the appropriate technical people at your ISP then they would be the ones to ask.
http://forum.kitz.co.uk/index.php/topic,15374.0.html
-
mine is currently 0xa44f
-
Also changed to 0xa459 here, had a resyncs 3 days ago, first resync in 32 days, plus I've gained a few more Mb's. :o
Had OR bod either Tuesday or Wednesday or poking around in my cabinet for some time, coincidence you can only take so far.
Got talking to him about vectoring coming,he just grinned & said no comment.
-
As konrado said. Either F/W update or line card.
The fact your'e all reporting it during the wee small hours and short downtime, more likely to be f/w.
-
mine has always been
DSLAM/MSAN type: BDCM:0xa485 / v0xa485
Modem/router firmware: AnnexA version - A2pv6F039g1.d24m
DSL mode: VDSL2 Profile 17a
-
Mine is currently
DSLAM/MSAN type: BDCM:0xa48d / v0xa48d
-
makes me wonder why they need to update F/W from 0xa44f to 0xa459 as my line has used 0xa44f since my 1st day on fttc 3 years ago maybe it's to iron out some bugs :-\
-
This might explain why my line resynced the other night at 10Mb above max! Last time is was this high was 2012.
Don't know what it was before but now it's
ChipSet Vendor Id: BDCM:0xa459
ChipSet VersionNumber: 0xa459
Stat logs attatched from the 4th, the 13th AM just after resync and just now. For anyone who wants a gander. Let us know if there is anything interesting. I've cetainly not seen it do this before. Sync so far above max, just 3.6 SNR, it's like it's now targetting 3dB. Much more bitloading now aswell.
Unually when it's synced so far above max it's not long before it resyncs at a lower rate.
Stats Before
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 21558 Kbps, Downstream rate = 70064 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 70646 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): 6.3 6.5
Attn(dB): 15.5 0.0
Pwr(dBm): 13.4 6.6
Stats After
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 21901 Kbps, Downstream rate = 69744 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 79826 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): 3.6 12.5
Attn(dB): 15.6 0.0
Pwr(dBm): 13.5 6.8
-
Sync so far above max, just 3.6 SNR, it's like it's now targetting 3dB. Much more bitloading now aswell.
Have had that happen 4 times in 3 years it seems to be when the modem's Bit Allocation Table gets confused
-
I'm on 0xa48c and my cabinet is relatively new if that helps at all.
-
[quote author=Darren link=topic=15950.msg296743#msg296743 date=1439573426]
This might explain why my line resynced the other night at 10Mb above max! Last time is was this high was 2012.
[/quote]
Funny you mention that, because I did a speed test either Tuesday/Wednesday morning, & I got 90.67Mb, which is about 15Mb above my normal figure.
Got the same results on two other speed sites, but at the time I dimissed it as a glitch.
-
Sync so far above max, just 3.6 SNR, it's like it's now targetting 3dB. Much more bitloading now aswell.
Is there a chance the cabinet went down temporarily and your line was the first to reconnect to it? The temporarily reduced noise would have meant a higher sync at the standard 6dB target.
When the other lines connected the noise increased and so your SNR dropped.
I've seen this after a power cut so that's why it caught my eye.
-
Is there a chance the cabinet went down temporarily and your line was the first to reconnect to it? The temporarily reduced noise would have meant a higher sync at the standard 6dB target.
When the other lines connected the noise increased and so your SNR dropped.
I've seen this after a power cut so that's why it caught my eye.
That would come in under crosstalk issue and Kitz has given you a rundown on that.
So lets see a currently running Hawuai cabinet gets and the f/w update all users on that cabinet will need to resync, I can't believe all lines would just retrain all at once on that cab like a power outage.
there could be 4 line cards in the cabinet but i am sure each card would get the update and resync the customers line before it go's onto the next line card.
-
It wouldn't just be crosstalk though it would be all background noise, if there was a power cut.
I saw a similar thing on ADSL.
-
Have had that happen 4 times in 3 years it seems to be when the modem's Bit Allocation Table gets confused
That's a shame, I guess this speed is only temporary then.
Funny you mention that, because I did a speed test either Tuesday/Wednesday morning, & I got 90.67Mb, which is about 15Mb above my normal figure.
Max as in max attainable not throughput.
There wasn't a power outage at least not to the house. Surely if mains was lost to just the cab the battery backup would kick in and there would be no loss of sync.
I was using the connection at the time, total downtime was 7 mins 11 sec.
A phone number that doesn't have FTTC reports on the checker "Sorry your cabinet is temporarily unavailable, capacity will be restored as soon as possible." Availability Date is 02-Sep-15, so it appears the cab is awaiting extra capacity or is full and a new one will be erected. It's a 288 port Huawei with at least 3 cards, probably at least 4 but can't say for sure. Sync was on the lowest end of the estimate (infact the min dropped on the estimate together with the actual sync dropping over the years) suggesting it's getting close to full if not now full.
Anyway, will enjoy the extra bit of speed while it lasts. Thanks all.
-
funny all this work for hauwei users and ECI seemingly left to rot :D as if BT want to pretend ECI never happened.
By the way I am pretty sure its a hardware swapout.
chipset version is not firmware version, I will check with a contact if he knows anything.
If BT can afford to swapout hauwei then I damn well hope they can do ECI given there is less ECI than hauwei cabinets, are we second class customers?
-
There is less ECI than hauwei cabinets, are we second class customers?
Is there any figures for actual number of each cabinets ECI & Hauwei, are they still installing ECI, or have gone over to Huawei cabinets completely, after all the problems.
-
I think ECI is roughly 1/3 of total commercial rollout.
Some say I am wrong but as far as I am aware BT have stopped rolling out ECI now, there may be a few infills in ECI areas but thats probably it.
ECI seemed to stop the moment openreach announced they were working on vectoring.
-
Was buying ECI a cockup by BT ?
-
A sleepy purr from b*cat to mention that this thread is about Huawei equipped cabinet hardware and an observation made by an Eagle eye . . . <Yawns> :sleep:
-
@Burakkucat - apol, off topicness ;D
-
Sorry B*Cat. :-[
I must not go off topic...
I must not go off topic...
'Ditto' ;D
-
A sleepy purr from b*cat to mention that this thread is about Huawei equipped cabinet hardware and an observation made by an Eagle eye . . . <Yawns> :sleep:
sorry :p was trying to get attention from those who talk alot about hauwei as everyone seems to think ECI doesnt matter.
-
I'm wondering if this has just happened to my line. A re-sync at 12:57am with no real gains noticed apart from a slight increase in speeds on the down and upstream. I'll need to double check stats to confirm though.
-
I've gone from
BDCM:0xa485 / v0xa485
to
BDCM:0xa48c / v0xa48c
How come the versions are so different? people are on a489 or a48c and I think I saw one post with someone on a48d, unless that was a typo.
-
I've gone from
BDCM:0xa485 / v0xa485
to
BDCM:0xa48c / v0xa48c
How come the versions are so different? people are on a489 or a48c and I think I saw one post with someone on a48b.
I guess there are 3 or 4 types of Huawei cabinets (DSLAM) out there so depending on which your currently on the H/W version number will be different.
-
Mine just changed to 0x459
-
Still no answer as to why the version numbers are changing and all i know any new firmware change is to make a new product compatible or an older product even more compatible ;)
-
Openreach Chief Executive Joe Garner say the new chipset is to improvement DLM as a new line card replaced. That's all he say it. He say this is nothing to do with vectoring.
Mine just updated this morning
DSLAM/MSAN type: BDCM:0xa459 / v0xa459
Modem/router firmware: AnnexA version - A2pv6F039g1.d24m
DSL mode: VDSL2 Profile 17a
-
Improvement to DLM and it giving more speed not taking it away something not right there ;)
-
Improvement to DLM and it giving more speed not taking it away something not right there ;)
it took speed away from me. reduced my ds attainable by about 4mbps and my us attainable by 1mbps and actual by 0.5mbps
-
By the way I am pretty sure its a hardware swapout.
chipset version is not firmware version, I will check with a contact if he knows anything.
Are you 100% certain on that. I thought it could also indicate f/w if a major change has been applied. :hmm:
We've also seen recently in another topic that its firmware that reports the 'type' and not the hardware. You can also easily change this type of output by putting on different f/w. See the thread how you can swap ECI f/w for OpenWRT and the modem will now report its using a different chip.
The other reason why I suspected f/w rather than hardware is the fact its done in the middle of the night and happens so quick. It would take a bit longer to swap out a line card and afaik they dont send engineers out in the streets in pitch black to do that sort of thing.
If BT can afford to swapout hauwei then I damn well hope they can do ECI given there is less ECI than hauwei cabinets, are we second class customers?
All of the ECI's had something similar happen between late last year and the beginning of this year, as the ECI's have gone from
IFTN:0xb203 / v0xb203to
IFTN:0xb204 / v0xb204
Do a google and it confirms that v0xb203 was pre-2014, and v0xb204 only started showing up fairly recently
-----------------------
@BaldEagle - Is there any way I can check from HG612 modem stats where it records this so I can pin-point the exact date. Currently this info is displayed in dslstats, but I cant see where it is in HG612 stats.
I dont know enough to understand what those figures mean and cant find any info that explains it, but I find it interesting that v0xa = Huawei and v0xb= ECI - thats a hell of a co-incidence. Its also interesting to note that searching on any of those 'types' be it ECI or Huawei all pull up lines which are belonging to Openreach.
Surely if those numbers related to a specific chipset then you would at least see some instances outside of the UK? Therefore Im beginning to suspect it is something more specific to Openreach than the manufacturers -possibly Openreach configured firmware...
... similar to how the same router SoC will report another manufacturer depending on which f/w version is used.
-
It's the hardware line card replaced Kitz not f/w
-
Openreach Chief Executive Joe Garner say the new chipset is to improvement DLM as a new line card replaced. That's all he say it. He say this is nothing to do with vectoring.
Just seen this after I typed out the above. Now Im well and truly puzzled because that doesnt quite make sense to me. Why would it take a new chipset to improve the DLM?
I could understand if he meant they rolled out new firmware to support DLM.
@max. Would you mind doing me a favour and PMing me exactly what he said in his words? tyvm.
-
I find it unlikely that openreach would be in my cabinet swapping line cards at half past midnight ???
-
True! I never seen any openreach attend the cabinet at midnight or after midnight ( never is )
-
Further to what kitz said, hardware is often hidden as far as interfaces are concerned, software is visible because of either new behaviour or capabilities or because of new bugs. So a software version is often the thing you want to see.
-
Openreach Chief Executive Joe Garner say the new chipset is to improvement DLM as a new line card replaced. That's all he say it. He say this is nothing to do with vectoring.
Just seen this after I typed out the above. Now Im well and truly puzzled because that doesnt quite make sense to me. Why would it take a new chipset to improve the DLM?
I could understand if he meant they rolled out new firmware to support DLM.
@max. Would you mind doing me a favour and PMing me exactly what he said in his words? tyvm.
A mad idea.
Maybe BT is evolving DLM to monitor different things that are supported by a new chipset.
I more 'intelligent' set of hardware would possibly need a new chipset.
It is the norm that chipsets evolve to support supersets of capabilities that previously needed multiple chips or interfaces to external hardware.
Maybe the hardware is getting 'better'.
I did tell you it was a mad idea! ;D ;D
-
I find it unlikely that openreach would be in my cabinet swapping line cards at half past midnight ???
Me too. BS is possibly the best to know but Ive never heard of them going out to work on the cabs at night.
The only thing I have heard when it comes to night work, is say if they are putting in an LLU MSAN, then contractors will work in a nice safe cozy environment with plenty of light outside of hours so that they arent interfering with the jobs that the frames engineers have to do during the normal working day. They also did similar with 21CN - again so they arent in the way of the guys who work on the MDF throughout the day.
----------
Re hex like strings of numbers, Ive not been able to find out anything to indicate what they relate to. I have however been looking at the following 2 string types
I have spent over half an hour searching and every single one of the partial strings 0xa or 0xb belong to Openreach. Other countries /ISPs have different strings for the first 3/4 chars. I did have a list, but unfortunately I lost a post I was making when the server went down and Im not about to search again.
Now if that string related to the chipset on the line card - or even the line card itself, then surely there would be some other showing of that partial string. Ive not been able to find anything. I found one which at first I thought was in Italy, but it turned out the user was posting on an italian site but he said he was in GB.
IIRC, ECI only do two types of vdsl line card, so surely if that string relates to a chip or linecard then some other ISP somewhere around the globe would also show up the partial string IFTN:0xb but no nothing. Its not 100% conclusive, but it leads me to believe that the string may at least partially have something to do with the SP rather than manufacturer/chipset/linecard.
-
Hi adslmax
This is to let you know that a resync/restart occurred on your line at 21-08-2015 02:11 local time (+/- 1 minute).
Reason: 0 Loss of Service
Current Downstream Sync Rate is now 79999kbps
Current Upstream Sync Rate is now 19999kbps
These alert e-mails are active by default, if you want to turn them off then use the Options link at the bottom of the MyDSLWebStats window. You can also view your recent Resyncs and other related data in the Resync/LOS data pane.
The chipset remain the same as I don't know what BT doing to my line resyncs (2 last night) and (1 just now)
-
@BaldEagle - Is there any way I can check from HG612 modem stats where it records this so I can pin-point the exact date. Currently this info is displayed in dslstats, but I cant see where it is in HG612 stats.
Using the attached versions of HG612_current_stats.exe and GRAPH6.exe, the information will be recorded at the bottom of each Plink log & also reported with the pbParams data when a snapshot montage is created (be it scheduled, manually initiated or immediately following a resync).
EDIT:-
I can't recall exactly when the information was added to Plink logs, but it is possible that you may already have it, just not displayed in the montages.
Replotting the graphs by dragging & dropping a Plink log onto the latest GRAPH6.exe icon would pick up the info (if it's there) & include it with the pbParams data.
-
kitz unless the firmware has a bug, then yes chipset version would be a static value to match the actual hardware, meaning if it changes the hardware has changed.
-
I find it unlikely that openreach would be in my cabinet swapping line cards at half past midnight ???
so you think it be more likely at 12.30pm when everyone is using it?
maintenance will be done at night to minimize disruption.
If you think it doesnt happen I have twice seen BT doing work on my cab and a cab across the road from me during dusk.
I also seen VM some weeks back working on their cab at about 1am.
--edit sorry for using word instead of road-- due to my illness
-
I agree with Chryalis, it would make sense to do the maintenance when few people are using the cabinet, i.e. after midnight until about 6AM.
-
These two bytes are just defined as "vendor-specific information" in G.994.1 section 9.3.3.1.
There's also a longer version number in G.997.1 section 7.4.5, but again for the xTU-C it's just described as containing vendor specific information, so what's in it and what it means will vary between vendors.
-
Using the attached versions of HG612_current_stats.exe and GRAPH6.exe, the information will be recorded at the bottom of each Plink log & also reported with the pbParams data when a snapshot montage is created (be it scheduled, manually initiated or immediately following a resync).
EDIT:-
I can't recall exactly when the information was added to Plink logs, but it is possible that you may already have it, just not displayed in the montages.
Replotting the graphs by dragging & dropping a Plink log onto the latest GRAPH6.exe icon would pick up the info (if it's there) & include it with the pbParams data.
Thanks BE. Someone kindly PM'd me last night to say where it should be, but I still could see it.
Your post explains why as it was 25th of May 2015 is the first time it started recording in HG612 stats for me.
I was looking between the period 18th Aug 2014 (http://forum.kitz.co.uk/index.php/topic,14283.msg267900/topicseen.html#msg267900) to Jan 16th 2015 (http://forum.kitz.co.uk/index.php/topic,14806.msg278070/topicseen.html#msg278070). So the change to the ECI's could have happened anytime during that time.
-
I have spent over half an hour searching and every single one of the partial strings 0xa or 0xb belong to Openreach. Other countries /ISPs have different strings for the first 3/4 chars. I did have a list, but unfortunately I lost a post I was making when the server went down and Im not about to search again.
Now if that string related to the chipset on the line card - or even the line card itself, then surely there would be some other showing of that partial string. Ive not been able to find anything. I found one which at first I thought was in Italy, but it turned out the user was posting on an italian site but he said he was in GB.
IIRC, ECI only do two types of vdsl line card, so surely if that string relates to a chip or linecard then some other ISP somewhere around the globe would also show up the partial string IFTN:0xb but no nothing. Its not 100% conclusive, but it leads me to believe that the string may at least partially have something to do with the SP rather than manufacturer/chipset/linecard.
But I also have 0xa.
DSLAM/MSAN type: BDCM:0xa48d / v0xa48d
Best regards
konrado5
-
Thanks konrado. :)
-
These two bytes are just defined as "vendor-specific information" in G.994.1 section 9.3.3.1.
There's also a longer version number in G.997.1 section 7.4.5, but again for the xTU-C it's just described as containing vendor specific information, so what's in it and what it means will vary between vendors.
Thanks ejs, After my post, I'd also started looking at G.994.1 last night but got tired and went to bed.
One of my other thoughts, was it would be interesting to see if someone such as Asbo who had MA5616 MSAN could see what it was reporting from that end.
I'd looked on his blog (https://insidehuaweima5616msan.wordpress.com/) and theres some quite interesting settings in there for the configs, but unfortunately not any stats that I could see taken from say a HG612 to see what his MA5616 was reporting.
-
I agree with Chryalis, it would make sense to do the maintenance when few people are using the cabinet, i.e. after midnight until about 6AM.
In all my time, maintenance work on live systems tended to happen overnight. However, that was on systems with far bigger impact than a single cabinet, and was predominantly software-oriented maintenance.
Hardware changes would be made, if possible, in a non-live environment before being swapped into the live environment (as a software change) overnight.
However, I'm quite prepared to believe that hardware changes that cannot be swapped in this way (via software) and in systems as small as a cabinet DSLAM, and in outdoor/street environments, will be done in daylight hours.
-
Signed up as also curious why the drop happened! :o
My home is a new build, nice shiny thick copper line fitted just over a year ago. I've had over a 3 month uptime (since I switched the HG612 off last) and it dropped 7 days ago with this retrain reason 1.
Checked pbParams and the only difference I see is I have gone from chipset version 0xa451 to 0xa48c whatever this means? I have a Huawei cabinet, also newly fitted late last year just before Xmas...
EDIT: I also lost 2Mb of my sync from 67Mb to 65Mb! :(
-
I asked my engineer, and he confirmed it be done overnight, it would only be done in the day if they had an ongoing outage and such an emergency.
-
hecked pbParams and the only difference I see is I have gone from chipset version 0xa451 to 0xa48c whatever this means?
This is almost the same version as my DSLAM. I have BDCM:0xa48d. Is it hardware change or rather software change?
-
I could be wrong, but Im still not convinced that this is a full line card swapout or change of linecard model.
The linecard chipsets are capable of doing some very clever things and even capable of making hardware type changes to the chip itself via a remote session. Im not talking general firmware updates like as per on our routers, nor that the number is an actual f/w version, but possibly how the dslam is configured to be able to update to certain new technologies from within the chip itself.
I was hoping to pinpoint the date of the IFTN update to a closer time frame to be more certain, but those numbers changing on the ECI's too is what is making me think that its not in specific relation to the line card, but more some sort of configuration to the line card.
Ive just looked on the ECI site and as far as I can see there is only 1 type of VDSL2 line card for the M41 which BT could possibly be using and that is the VTU-C-64. I just checked the photo from inside my cab and its clearly marked VTU-C64. So if there isnt any other line card that they could be using in my cab, how come I went from IFTN:0xb203 to 0xb204 a couple of months ago. How can the same set of numbers change on ECI's when there isn't anything else BT could update to other than a V41. I think the later is extremely unlikely and Im quite sure I would notice some down time if it was a full DSLAM swap out. Therefore that number can and does change without a physical swap out of hardware.
Also if it was vectoring, then as we've already discussed many times in the past, we know that the Huawei's are already capable and it only requires the addition of the vectoring engine module, not a change of line-card.
Even the VTU-C64 line cards in the M41's are capable of doing vectoring. The M41 could do vectoring at a line card level, but its a waste of ports. The V41 is practically the same as the M41, same size, even uses the same line cards it major difference is the layout of the ports to make additional room to slot in a vectoring line card. The obstacle with the M41 is purely no room to slot in the VEC256 vectoring card to be able do shelf based vectoring.
I'm therefore inclined to think that this is some sort of remote session to set or change something on the chip.
-
I think VTU-C 64 is a fairly generic label. VTU = VDSL2 Transceiver Unit, VTU-C and VTU-R would designate central (DSLAM) and remote (end user's modem). The ADSL standards used ATU-C and ATU-R, although the VDSL standard actually uses VTU-O, the O indicating optical, since VDSL DSLAMs aren't usually centrally located. 64 is the maximum number of lines that each ECI line card can handle.
-
Thinking further about ECI vectoring, apparently a single IVE1000 (https://www.lantiq.com/access-networks/dsl-portfolio/vectoring/vinaxtm-ive1000/) vectoring chip can handle a maximum of 48 lines.
One VINAXTM IVE1000 device allows full cancellation for up to 48 ports in profiles 17/12/8 and up to 32 ports in profile 30.
So a 64 port ECI line card would need to contain two IVE1000 chips to do vectoring on all its ports.
I also found this (http://blog.ecitele.com/Pages/Post.aspx?PostID=67&Author=ECI%20Staff) which seems to imply line card level vectoring wouldn't have 64 port line cards, or not in 2011 at least.
-
I could be wrong and I'm not convinced either way if new hardware has been added but, I imagine if there is a spare line card slot, a new card could be added, lines from an old card mapped to the new card via software during quiet time (overnight) and then the old card removed. Repeat untill all cards have been swapped out.
My line resynced at 10Mb above attainable over 3 weeks ago and held on fine but has just rebooted with Retrain Reason: 0 at 21:30, strange it's done it at this time of night. Back down to the previous sysn which is no better or worse, unlike some people who have had their sync reduced. That may of been because it was due to fall anyway because of increasing crosstalk.
-
I could be wrong, but Im still not convinced that this is a full line card swapout or change of linecard model.
The linecard chipsets are capable of doing some very clever things and even capable of making hardware type changes to the chip itself via a remote session. Im not talking general firmware updates like as per on our routers, nor that the number is an actual f/w version, but possibly how the dslam is configured to be able to update to certain new technologies from within the chip itself.
I was hoping to pinpoint the date of the IFTN update to a closer time frame to be more certain, but those numbers changing on the ECI's too is what is making me think that its not in specific relation to the line card, but more some sort of configuration to the line card.
Ive just looked on the ECI site and as far as I can see there is only 1 type of VDSL2 line card for the M41 which BT could possibly be using and that is the VTU-C-64. I just checked the photo from inside my cab and its clearly marked VTU-C64. So if there isnt any other line card that they could be using in my cab, how come I went from IFTN:0xb203 to 0xb204 a couple of months ago. How can the same set of numbers change on ECI's when there isn't anything else BT could update to other than a V41. I think the later is extremely unlikely and Im quite sure I would notice some down time if it was a full DSLAM swap out. Therefore that number can and does change without a physical swap out of hardware.
Also if it was vectoring, then as we've already discussed many times in the past, we know that the Huawei's are already capable and it only requires the addition of the vectoring engine module, not a change of line-card.
Even the VTU-C64 line cards in the M41's are capable of doing vectoring. The M41 could do vectoring at a line card level, but its a waste of ports. The V41 is practically the same as the M41, same size, even uses the same line cards it major difference is the layout of the ports to make additional room to slot in a vectoring line card. The obstacle with the M41 is purely no room to slot in the VEC256 vectoring card to be able do shelf based vectoring.
I'm therefore inclined to think that this is some sort of remote session to set or change something on the chip.
yeah I am not convinced its hardware either, my engineer wouldnt say. But he confirmed to me if it was a hardware change it be 95% chance at night.
Usually in things like bios versioning in comoputing, chipset version = hardware version, so it never ever changes if the hardware isnt changed. So my opinion is if it was software,, then its either a bug or the change is non standard to expected versioning behaviour.
By the way you saying ECI cabinets have also had a chipset version change?
-
Thinking further about ECI vectoring, apparently a single IVE1000 (https://www.lantiq.com/access-networks/dsl-portfolio/vectoring/vinaxtm-ive1000/) vectoring chip can handle a maximum of 48 lines.
One VINAXTM IVE1000 device allows full cancellation for up to 48 ports in profiles 17/12/8 and up to 32 ports in profile 30.
So a 64 port ECI line card would need to contain two IVE1000 chips to do vectoring on all its ports.
I also found this (http://blog.ecitele.com/Pages/Post.aspx?PostID=67&Author=ECI%20Staff) which seems to imply line card level vectoring wouldn't have 64 port line cards, or not in 2011 at least.
yep on M41 ECI (think I told kitz in pm) they have to disable a load of ports to enable vectoring, which BT may consider as cash thrown down a pit.
-
-
By the way you saying ECI cabinets have also had a chipset version change?
Yes... and No.
This is the whole reason why I dragged ECI's into the conversation more than 2 weeks ago (http://forum.kitz.co.uk/index.php/topic,15950.30.html). Some time early this year, the ECI's went from IFTN:0xb203 / v0xb203 to IFTN:0xb204 / v0xb204. Yet there hasn't been a physical hardware swap of the line cards. There isnt (afaik) any other line card that BT could be using in their M41's.
So yes because the number string has changed too for the ECI's. No because all indications are that its not an actual physical hardware change of the chipset or linecard.
Remember in my earlier post I mentioned about how linecard chips were very clever and they can make 'hardware like changes via a remote session' and how I deliberately said its not just a change of firmware its far more than that. The correct term is Field-Programmable Gate Array (https://en.wikipedia.org/wiki/Field-programmable_gate_array) - Read the link.
So back to why I think the change is a remote software update and not a physical swap out.
I am not sure what that string of numbers represent, but particularly with having seen those numbers change on the ECI's, its why I'm thinking that its something to do with remote [software type] configuration changes that BT are making to the chip itself.
----
ETA
Thinking about it, FPGA may be the reason why ECI only has one type of VDSL2 card (bar the port nos), and why they use the rather generic naming convention.
I should also say that I was always previously under the belief that the string related to a specific chipset on the line-card, but now Im leaning towards at least some part of it being configuration of the chipset on the linecard.
-
I thought it was implying that the 64 port line cards didn't have a vectoring chip on them, and that the port wastage was due to how the cables had to be arranged, rather than that there's only one vectoring chip on a 64 port line card, and it can only vector 48 of the ports. For example, for line card level vectoring, if there were 3 cables each with 30 lines, that would require 3 48-port line cards, you wouldn't be able to use more of the ports across 2 line cards, because you couldn't connect half of the lines in one bundle to one line card and the other half in that bundle to the other line card.
The "vectoring ready" line cards (192 port system) in the IVE1000 product brief don't have a vectoring chip on them, all the vectoring chips are on the vectoring card.
What's labelling those 0xb204 bytes as the "chipset version"? The G.994.1 PDF just says they are "vendor-specific information". It does not say they indicate the "chipset version".
-
-
It just seems a bit odd, for ECI to promote all the advantages of system level vectoring, but then put a vectoring engine chip in each line card anyway, and not put multiple vectoring engine chips in each line card to do all 64 ports.
I read it a bit like: ECI can squeeze 64 VDSL ports into a single line card because all the vectoring engines go on a separate card. But then it does mention usable ports with line card level vectoring, presumably due to the limited amount of vectoring processing capacity in each line card.
-
Perhaps it will be helpful. When my chipset version was changed to 0xa48d from 0xa32f, I noticed my router begginned reporting SNR values for upstream on "adslctl info --SNR". Furtermore, it has no longer reports strange upstream SNR margin for upstream during the first minutes of new connection as I've described in this old thread.
http://forum.kitz.co.uk/index.php/topic,13446.msg253639.html#msg253639
Best regards
konrado5
-
its possible that chipset version is short for chipset software version in this case.
In the past my ECI cards did get swapped out as I posted on here about it when I caught a guy doing it during a night, but it was quite a while go now that happened.
-
OFF topic but related ... from Greece
from vdsl users i have seen
DSLAM/MSAN type: BDCM:0xa41b / v0xa41b
adsl otenet (so far there is not vdsl at my end as far i know)
before broadcom 0xa188 (an old thomson has recored as BRAS JUNIPER ΙΟΑ 2 Ε350) ...
lately appearing as
DSLAM/MSAN type: BDCM:0xa3a7 / v0xa3a7
(i don't have any longer the thomson to confirm the dslam make if is the same)
Modem/router firmware: AnnexA version - A2pv6F039o1.d26a
(zyxel vgm 1312 ... V100AAJZ7.C0 firmware)
VDSL line (wind)
DSLAM/MSAN type: IFTN:0xd087 / v0xd087
-
My Huawei DSLAM had a firmware update at approx 2:30 am this morning
previously DSLAM/MSAN type: BDCM:0xa59 / v0xa459
now DSLAM/MSAN type: BDCM:0xa48c / v0xa48c
-