Print

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

[Chrysalis]

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.

[Chrysalis]

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

[GigabitEthernet]

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.

[ejs]

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.

[kitz]

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 to Jan 16th 2015.  So the change to the ECI's could have happened anytime during that time.

[konrado5]

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

[kitz]

Thanks konrado.   

[kitz]

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


 

[WWWombat]

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.

[Sparx]

Signed up as also curious why the drop happened!

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!

[Chrysalis]

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.

[konrado5]

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?

[kitz]

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.

[ejs]

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.

[ejs]

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.