Print

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

[kitz]

well dave from plusnet posted today the ECI kit can support vectoring, obviously I dont know if he is right, how he got his information, but its on the plusnet forums.

Ive said a couple of times on this forum in a few different threads that the ECIs CAN support vectoring... just that its done at line card level and not a dedicated module.  Line card vectoring isnt as efficient as a dedicated module though.

[kitz]

M41 MSAN removed and replaced with a V41 MSAN.

Its not impossible to do vectoring on the M41, as its done on the line card.
The problem with vectoring at the line card is that all lines from the pair feed must be vectored and you cant mix and match the pair feeders.

The V41 is a 'shelf based' vectoring solution which has a dedicated card responsible for mapping any pair feed to any of the line cards.  The V41 is a more efficient solution.

Shelf-based vectoring solution
 
A shelf-based vectoring platform is the preferred solution for the deployment of dynamic high-speed access networks. In such a vectored VDSL2 platform, the vectoring engine resides on a dedicated service card that controls the vectoring activity of all the VDSL2 line cards. Connect any card to any pair in any feeder!

In this case, the vectoring engine card controls ECI’s four 64-port VDSL2 line cards, without compromising performance or capacity.

Most VDSL2 vendors who have developed vectoring solutions have implemented them on a per-card basis. The vectoring engine resides on the VDSL2 line card and controls the vectoring activity on the ports of the line card. This approach has two drawbacks:

    Vectoring requires significant processing power and memory resources. These resources are allocated from the ports and may force the operator to reduce the number of ports deployed or accept a traffic performance hit.
    The card-based vectoring approach requires that all the pairs in a feeder cable be connected to the same card; if not, the vectoring engine misses out on crucial measurements and the subsequent pre-coding that ensures the efficiency of the vectoring operation is compromised. With typical feeder cables containing 100 pairs or more, this approach is highly impractical. In addition, as customers churn, card-based vectoring requires significant cable management activity, with all the relevant opex implications.

Source ECI blog

Further discussion in that thread
http://forum.kitz.co.uk/index.php?topic=13268.msg249932#msg249932

and also here
http://forum.kitz.co.uk/index.php?topic=9726.msg257560;topicseen#msg257560

The ECI cabs could prove problematic because although vectoring can be done at a line card level, its not as efficient as a standalone vectoring module.  By efficient I mean in terms of spare lines and manual intervention.  The nearest I can equate it to is wanting to add a new PCI card into your PC, but youve run out of PCI slots.  The ECI cabs dont appear to have room or capability for a new module to be added, so its anyone's guess yet how BT will proceed with the ECIs.

[c6em]

Interesting thread....
Just a point for your consumption in all of this.
BT have been putting in statutory code notice letters for FTTC upgrades to my local council.
Given notice of their intention to install the equipment on the roadside.
The letters are quite detailed about each site for the FTTC unit
ALL of them are either huawei 96 or huawei 228 cabinets
NO ECI's.

[burakkucat]

I could be wrong but isnt the MA5603T the older model?
According to this its now on its end of life?

No, there is no logic to Huawei's model numbering. The MA5603T is 'bigger', more 'advanced' and more configurable than the entry-level MA5616[T].

Yes both the MA5603[T] and the MA5616[T] -- as items of hardware -- are EOL, as far as Huawei are concerned. However due to Beattie's size and purchasing capability it is rumoured that a deal has been struck with Huawei.

[As an aside, it was due to the EOL status of the MA5616[T] that asbokid was able to purchase at least two (or maybe three) of them at, a very reasonable price, directly from a Chinese agent in 2012!]

[kitz]

there is no logic to Huawei's model numbering.

   Thanks blackcat.

However due to Beattie's size and purchasing capability

According to that document I found last night that listed the amount of units, then it would certainly appear that BT have been preferring to install the MA5603T for quite a while - probably due to their capacity.  Closer inspection today of the document talks about period jul -Dec 2012 power consumption of those unit.  The document is primarily about power consumption, but it has some nice details in

..  taken from their inventory of cabs as at March 2013 right down to how many line cards each of those cabs has installed.   Unfortunately though Ive been unable to find anything more up to date.   For at least the period Mar - Sep 2013 BT seemed to be favouring installation of ECI over the MA5616, so I would expect the ECI total to have grown a fair bit.    They now seem to be going back to the MA5603's  I should imagine this would have something to do with the easier upgrade for vectoring on the Huawei's


A copy of the doc will be winging its way to the cattery soon as you may find the info useful too for something or other.   
It would take me too long to format all the info.... but a sample.

Code: [Select]


Cabinet & card inventory records at March 2013

Huawei  MA5603T - 12,995 cabinets

1 line card        48 lines      4188
2 line cards       96 lines      7916
3 line cards       144 lines      691
4 line cards       192 lines      164
5 line cards       240 lines       23
6 line cards       288 lines       13
                            Total 12995


93% of the cabinets have 1 or 2 cards installed.
Capacity planning policy - additional card installation process is triggered when utilisation is above 75%



[burakkucat]

A copy of the doc will be winging its way to the cattery soon as you may find the info useful too for something or other.   

Thank you. Now received. 

It's just the thing to read on a wet night, when the weather precludes going out for a nocturnal prowl around Beattie's dustbins and back orifices for scraps of discarded information . . . 

[Chrysalis]

well dave from plusnet posted today the ECI kit can support vectoring, obviously I dont know if he is right, how he got his information, but its on the plusnet forums.

Ive said a couple of times on this forum in a few different threads that the ECIs CAN support vectoring... just that its done at line card level and not a dedicated module.  Line card vectoring isnt as efficient as a dedicated module though.

yeah and if what was said here about line card vectoring is true, it doesnt bode well unless openreach are prepared to organise pair bundles so all neighbouring pairs are on the same card.  So if thats the solution that ends up been used whilst better than nothing it seems will be inferior still to H cabinets.

What is really bugging me tho is why only one vendor is been tested so even if ECI gets used, is it going to be deployed without any testing at all and just hoping H configurations work on it?

Does feel like anyone unlucky enough to be in that late 2012 to mid 2013 period with ECI's is going to be on the 2nd class service.  This is why splitting vendors is always bad.  It was the same with BT adsl, I remember having all sorts of problems then aaisp got me a forced move to another dslam which happened to be BT's 2nd vendor and it was way better, in terms of the stability and performance.  (that 2nd vendor of course was a broadcom chipset).

[Chrysalis]

Interesting thread....
Just a point for your consumption in all of this.
BT have been putting in statutory code notice letters for FTTC upgrades to my local council.
Given notice of their intention to install the equipment on the roadside.
The letters are quite detailed about each site for the FTTC unit
ALL of them are either huawei 96 or huawei 228 cabinets
NO ECI's.

yes ECI seems to have been abandoned since around the date vectoring tests were first announced.

[Chrysalis]

I could be wrong but isnt the MA5603T the older model?
According to this its now on its end of life?

No, there is no logic to Huawei's model numbering. The MA5603T is 'bigger', more 'advanced' and more configurable than the entry-level MA5616[T].

Yes both the MA5603[T] and the MA5616[T] -- as items of hardware -- are EOL, as far as Huawei are concerned. However due to Beattie's size and purchasing capability it is rumoured that a deal has been struck with Huawei.

[As an aside, it was due to the EOL status of the MA5616[T] that asbokid was able to purchase at least two (or maybe three) of them at, a very reasonable price, directly from a Chinese agent in 2012!]

check the EOL notice, you notice its a certian revision thats EOL, specifically look at the reccomended replacement products, they the exact same model number but higher revision, this is why I asked what revision they using.

[Ragnarok]

I've stuck my Hg612 back in as my INP has risen. and my speeds dropped again because of it.

Now I'm forcing a higher SNR by limiting my speeds at my end. with a hope to get fast path and maybe INP reduced.

Thanks to les for this template command

xdslcmd configure --maxDataRate <downstreamKbps> <upstreamKbps> <totalKbps>

xdslcmd configure --maxDataRate 45000 18000 63000   , is what i sent and......

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason:   6
Last initialization procedure status:   0
Max:   Upstream rate = 18116 Kbps, Downstream rate = 60708 Kbps
Bearer:   0, Upstream rate = 18000 Kbps, Downstream rate = 44994 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.9       6.0
Attn(dB):    17.7       0.0
Pwr(dBm):    13.6       6.8
         VDSL2 framing
         Bearer 0
MSGc:      36      159
B:      31      236
M:      1      1
T:      64      2
R:      10      16
S:      0.0226      0.4188
L:      14872      4871
D:      1441      1
I:      42      255
N:      42      255
         Counters
         Bearer 0
OHF:      401855      126664
OHFErr:      0      0
RS:      154137524      4063861
RSCorr:      30289      0
RSUnCorr:   0      0

         Bearer 0
HEC:      0      0
OCD:      0      0
LCD:      0      0
Total Cells:   75635014      0
Data Cells:   526090      0
Drop Cells:   0
Bit Errors:   0      0

ES:      17      6
SES:      14      0
UAS:      257      243
AS:      875

         Bearer 0
INP:      3.50      0.00
INPRein:   0.00      0.00
delay:      8      0
PER:      2.17      6.93
OR:      154.31      190.27
AgR:      45147.83   18190.41

Bitswap:   566/567      0/0

Successfully limited at my end

I've set DSL stats to tweek to xdslcmd configure --maxDataRate 45006 18000 63006

when the DSL is down, hopefully that doesn't happen again unless DLM intervenes.

Very worryingly, just after I put the HG612 back in this morning, I had a noise burst that managed to take down the DSL even with the higher SNR margin.


I also have another neighbour who got FTTC but his line is very sick, he had better Down-speeds and line attenuation on the longer line all the way to the exchange on ADSL2+. The Kelly communications guy didn't even think line fault.

[tickmike]

Thanks for the warning as I was going to tell my neighbors that we may soon get FTTC in our village. 

[Ragnarok]

I fixed my neighbours sick line temporally. the MK2 Bt filter was DOA, causing the VDSL2 to drop out when the phone line was in use.

I removed it and disconnected all other internal extension wiring( it's no longer used anyway),  put a regular ADSL2 filter in place. it's only syncing at 18mbit/s for now but the attainable rate is now 56mbit/s and the snr is upto 23db. Thankfully you can get this info on a talk talk super hub.

I worry when it re-syncs at the proper speed eventually, more big bad crosstalk and all our lines get hammered once again.