Print

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

[burakkucat]

VTU-C64 . . . VDSL2 Transceiver Unit - Central Office 64 Ports

[kitz]

Also we dont know if the chipset in the ECI devices is as new as in the t-link's.

The chipsets are the same -  as is the HH5A.   Those that had problems contained the Lantiq VRX-268, this is what Ive been saying for the past 6 months    What does differ though is other equipment in those modem/routers which may have more processing power and memory than the ECI modem. 

Regarding the dslam's it may be something similar, often hardware vendors will use software features to sell new hardware, so it could be ECI have told BT the M41 will only do downstream g.inp, if you want upstream support buy newer kit.  Or it could actually be a hardware limitation.

That doesnt make sense... Read my post again as to why it doesn't make sense... but to repeat..
For downstream (>80Mbps) its the DSLAM which is doing all the hard work.  Its the DSLAM which has to have sufficient processing power and ability to encapsulate & store data in the retransmission buffer.    Upstream (>20Mbps) for the DSLAM is easy, it only needs to send a re-request to the CPE if a data packet is corrupt.   
It makes no sense to me how it can cope with all the processing and buffer storage for up to 256 user lines, yet be incapable of sending a re-tx request. This is hardly any more difficult for the DSLAM than recording a CRC or FEC.

See attached flow diagram of the steps for g.inp - See how much there is for the DSLAM to do for the downstream.   The bit Ive circled in red is the Re-request for upstream re-tx. 


Its the CPE which is responsible for doing the processing and buffering for the upstream.   
Downstream g.inp for the CPE is easy as all it has to do is send a re-tx request upon detection of a corrupt packet.   If the modem doesnt have sufficient hardware resources to be able to do upstream retransmission then all it has to be capable of is sending a RRC.

To be able to do downstream g.inp the CPE doesnt need to do any scrambling or buffering, just capable of sending a re-request.   Image 2 shows the process for modems which do not have hardware resources & capability to do upstream g.inp.

For the CPE modem to do upstream and downstream g.inp it needs to be capable of the whole lot (image one again). 

This is why I am puzzled about how the ECI DSLAMs would do everything in Image one - except be able to do the easy bit and send an RRC. 

[kitz]

Our special agent (codename Wheelbarrow) was active "in the field" when some ECI based cabinets were installed in Ewhurst, Surrey, a few years ago. Being a sociable person and able to establish a rapport with installers, some interesting images were thus obtained.

Example below . . .

Thank you b*cat
As expected, it looks very much like the one in my cab.   I also took the opportunity to approach a friendly OR installer...   and its how I knew they were using VTU-C64's.


--

PS
Ive been trying to read the labels and see if it was any clearer on yours than mine to see if it gives more info, but I think not.
All I can make out from mine is:
Date of Manufacture 04/2012   SN 55xxxxxxxxxxx
VTU-C64.  BT [something] code xxxxxxxxxx  Warranty EXP 04/2017

iirc it was ejs who found a document stating they contained Lantiq Vinax V3 chipsets...  which is where Im assuming the V3 mentioned in BS's post comes from.   

[burakkucat]

I think those labels can be read. 

On the LH board --

Y33361  Date of Manufacture    06/2012  SN:   5501780879
CFU - M41a  BT  Item code 058802 A01   Warranty EXP.   09/2017

On the RH board --

Y33301  Date of Manufacture    06/2012  SN:   5501793758
VTU - C64P  BT  Item code 058801 E04AE Warranty EXP.   09/2017

Note the VTU - C64P on the RH board's label.

The attached, below, are excised from the original high resolution image --

[ejs]

I haven't found any information about the ECI VDSL2 line cards. The vinax v3 seems to be the current offering from Lantiq, I'm not sure if it would be too recent to have been used in the ECI line cards. I did find a Russian price spreadsheet that lists a ECI VDSL2 line card as:

VDSL2, 64-port, POTS, male DIN 160-pin front connector, Lantiq VINAX-M 2.2, 17a, V41 - ECI Telecom - Y33563

It doesn't list it as a VTU-C 64 v3.

I also found this weird "ECI open orders parser" website, which looks like it shouldn't even be on the public Internet, which says unsupported in the status column for some of the VTU-C 64 V3 line card entries:

VTU-C64V3 - Y33564 - unsupported

[kitz]

Thanks ejs

From looking at that russian site you found and b*cats ability to extract the code from the high resolution image  (mine was taken by my phone so not high res), it would appear that Y33301 is possibly the manufacturers code for the BT ECI line cards.

Goodness knows what that other site is, but like you say it doesnt look like it should be for public viewing...  it looks like someone's list of all ECI parts that are being repaired & replaced.    There seems to be a heck of a lot of Replaced fan assy for ECI fan units.
I havent a clue though what Y33564 unsupported could mean for the VTU-C64V3.


I think looking at the blurred SN from mine again it could be 550177xxx7  which puts it about 20k away from the one walter photo'd.   It looks like those SN's arent just for line cards though, so not much help of identifying a batch, to see if those SN's on the open orders site could belong to BT.  It is possible they could be... but I havent spent any time digging to see if I can find any no's near to mine or walters. 

[Chrysalis]

kitz you need to look at the business not just the technical reasons.

Vendors do use software to sell hardware. So yes it does make sense.

Also g.inp, vectoring etc. need development time, experience etc,. to get right, what were ECI before vdsl got launched? a military company.  End of the day ECI's stance is its downstream only, thats all that matters.  BT went cheap buying ECI, where else is ECI deployed in the world?.

Chipsets do matter, this has been proven again and again in XDSL kit, everytime new tech arrives the chipset makes a big impact e.g. in all these scenarios I have seen chipsets impact how well the functions work.

bitswapping
SRA
g.inp
vectoring

Even the revision of a chipset from the same vendor can impact things.

[kitz]

kitz you need to look at the business not just the technical reasons.

End of the day ECI's stance is its downstream only, thats all that matters.

I'm not convinced.    It does not compute in this instance.    Did you read the technical stuff I posted, as Im not sure if Im making myself clear with what Im trying to say
Let me try again.

1) For any line to use G.INP then the DSLAM must be capable and have sufficient hardware resources to do both upstream and downstream retransmission.  For the DSLAM  its the downstream that needs sufficient resources.   Upstream is easy and no harder than recording a CRC.   The software construction is this



The dslam can turn on or off g.inp in either direction. It can turn both of or it can turn upstream off.   There is no point just turning just downstream off.  If upstream retransmission is off then its just not doing the bit in red that I circled.


2) For any line to use G.INP then the MODEM must have
   (a) Sufficient hardware resources to do upstream OR
   (b) If the modem doesnt have sufficient hardware resources then it can do downstream only retransmission by additional of a small piece of code in its firmware.   (Alarm bells ringing why the ECI modems had to have those firmware updates rolled out yet?)




Now lets imagine this scenario:   

Here we have BT which have ECI DSLAMs powerful enough to do downstream retransmission and therefore by default must also be able to do upstream transmission.  The catch is Openreach think that all the EU's attatched to the ECI cabs have ECI modems.   ECI modems which last year were incapable of any  form of retransmission at all.   So Openreach rolls out a firmware update which enables them to do downstream only.  So what if because of the situation with the ECI modems, then BT themselves set the ECI DSLAMs to do downstream only in the belief that 99% of EUs are using ECI modems which cant do upstream G.INP.


I wouldnt be too surprised if later modems such as the HH5A or TPlink by default have that [item 2] piece of code pre-installed by the manufacturers.    To be fully compatible then it must have [item 1 code] and sufficient hardware resources.  I wouldnt be surprised if thats all that TPlink had to do, get that item one code and add it to their f/w knowing that the TDW9980 had sufficient CPU and memory to cope. 

Openreach dont seem to care much about the ECI modems, we already know they wont be supporting them for much longer.     

[kitz]

what were ECI before vdsl got launched? a military company ../snip/..
where else is ECI deployed in the world?

Erm theyve been in the Teleco business since 1961.  Have you seen some of the firsts in telco innovations that they are responsible for? - wiki link.

They are also who France Telecom and Deutsche Telekom have used for many years (pre fttc), and also whom they use for their FTTC DSLAMs .  From what I can gather Deutsche telekom started using M41's many years ago, but switched within the past few years to using the vectored DSLAMS... and aim to replace their older M41s with V41s by 2016.


The first system level chip for vectoring was only released in Jan 2012 by Lantiq.


In 2012 ECI supplied V41's using those Lantiq chipsets to a Latin American carrier who became one of the first SPs in the world to be able to offer vectoring to their customers. - link.

Now Im as unhappy as you are to be on an ECI cab... but as I said in another post a few days ago, the issue here isnt really with ECI who do have the technology.  The problem is that BT in 2012 ordered M41's and someone didnt have the foresight to order V41's.   

Vectoring really only really took off that year.  None of us here knew about or talked about vectoring until 2013, by which time BT had already been busy installing M41s

If ECI were the first company to manufacture system level DSLAMs, you can hardly blame ECI for the fact that 1/3rd of the cabs in the UK are stuck with M41s.   If you are pointing fingers of blame, then youre pointing the finger in the wrong direction at ECI.

The same doesnt apply to Huawei because their DSLAMs have sufficient space to slot in a separate vectoring engine.  We've been banging on for ages that the problem with the M41's is purely nowhere to slot in a vectoring engine.

[Chrysalis]

ok thanks for the history lesson on ECI.

But my point stands, ECI will have specified a spec for the M41s, if they dont want to support full g.inp and vectoring on it then its tough luck to BT. (and ultimately the end users on ECI cabs).

I am not blaming ECI, I am blaming BT.

I think what you still dont understand tho is that ECI will have vectoring capable kit, but that kit may not work the same way as broadcom capable kit, everyone will have their own variant.  Indeed studies have even shown that different vendors have different results with vectoring as some have better quality implementations than others.

[burakkucat]

Openreach dont seem to care much about the ECI modems, we already know they wont be supporting them for much longer.   

Supporting both ECI and Huawei modems until January 2017. (Unless there has been a recent change of plans which I have not "picked up".)

[burakkucat]

I think what you still dont understand tho is that ECI will have vectoring capable kit, but that kit may not work the same way as broadcom capable kit, everyone will have their own variant.  Indeed studies have even shown that different vendors have different results with vectoring as some have better quality implementations than others.

I believe that the ITU are working towards ratifying a G.Vector standard . . . Or have I completely misread and misremembered some information?

Do you know the current standing, please, Chrys?

[kitz]

ECI will have specified a spec for the M41s, if they dont want to support // vectoring

Its not that they dont want to, its that the M41s cant take a vectoring engine because there isnt room for one.   The V41 is very similar to the M41, only there is space to insert the vectoring card.

ECI will have specified a spec for the M41s, if they dont want to support full g.inp

D'oh..  Thats what I keep harping on about!!!1  *Bangs head on desk* 

I think the M41 may be able to support it.
If any device (be that MODEM or DSLAM) can support retransmission on its outbound traffic, then by default it should be able to support inbound traffic.
Thats why I was showing the images from the ITU-T G.998.4 documentation.   


...  and that is also why I asked if I was missing something obvious and wondering if it could be an Openreach decision to turn it off.   I was asking if anyone could think of any reason why this would be..  ie if it could be because of the ECI modems not being able to support it so they thought no point enabling it on the ECIs

[kitz]

BTW

There's something a bit weird about DLM detection of G.INP compatible modems.  Look how that went pete tong on the Huaweis. Strictly speaking, theory was the Huaweis should have been able to properly detect non-compliant modems and gone over to bog standard INP.   But the fact DLM was giving those lines an INP value in the 40's suggests it was applying G.INP values rather than INP.

Note how it should have been able to implement on the fly, yet now it can take several days or more before the DLM system is convinced that the modem is g.inp compatible and before it will turn on retransmission.    Note how now the default profile is interleaving - http://www.kitz.co.uk/adsl/ginp-retransmission.htm

Theres also something weird with G.INP and communication with the BRAS.  Deutsche Telekom had to turn off G.INP on their vectored lines because too much overhead was being lost and it was reducing the rate at which modems could sync at.   Remember how with the Huaweis how those lines lost 10Mbps of sync?   On Duetche Telekom lines it was knocking off about 10Mbps from the headline rate (103 > 93 Mbps)

https://translate.google.co.uk/translate?hl=en&sl=de&u=http://www.onlinekosten.de/news/vdsl100-telekom-wird-fehlerkorrektur-g-inp-abschalten_199787.html&prev=search

I dont speak German, but if someone wants to interpret that better.


--
Edited typo.

[Black Sheep]

Very informative posts, Kitz. Had a giggle at the 'Pete Tongue' comment ......  ........ was it a predictive text  moment ??

https://en.wikipedia.org/wiki/Pete_Tong