Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Darren]

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.

[Chrysalis]

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?

[Chrysalis]

Thinking further about ECI vectoring, apparently a single IVE1000 vectoring chip can handle a maximum of 48 lines.

One VINAX^TM 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 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.

[kitz]

[kitz]

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. 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 - 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.

[ejs]

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".

[kitz]

[ejs]

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.

[konrado5]

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

[Chrysalis]

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.

[babis3g]

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

[hagrid]

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

[ejs]