Print

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

[kitz]

Very interesting. If you look at Chrysalis' stats on http://www.mydslwebstats.co.uk/ the U/S and D/S power outputs are now exactly the same, identical.

In fact, there are now 3 people on the above site with the low but identical power outputs on ECI cabs. One Sky, one BTW and one Plusnet customer.

That sounds suspiciously like a presentation bug in the modem, rather than anything else.

I wonder why the "Power" column is the only one you can't sort on MDWS?

Either that or its now the DSLAM is now reporting back the wrong figures.   The individual bands haven't changed so its highly likely that the aggregate is wrong.  Im in agreement with you that its reporting the wrong aggregate figure - ie the upstream rather than downstream.   Theres now 4 on MDWS showing what looks like an impossible downstream TX.  If it really had lowered that much then it would have an effect on the sync speed. 

[kitz]

I've no idea exactly  what caused the erratic SNRm for a short while, but I wonder if it could be related to a load of modems all syncing up at the same time.

Ive seen something similar a several times after a power failure...  its not something recent, its something Ive seen on my own line on BE equipment and even in the days of adslmax.    Ive found that a resync will usually clear it.

[Chrysalis]

heh was going to challenge you to find someone with worse crosstalk than me as I am hitting an insane -105 now on QLN, but I already found someone, tristanC's is worse than mine.

[kitz]

Mine hits -105 too.   
Most of my crosstalk is in the 8Mbps region.   Always has been even prior to me getting FTTC, I first noticed it about a year or so after getting adsl2+.
I used to read crosstalk from the bitloading graph - (this was way before we got QLN figures).

Mine hits the adsl tones more than yours, but yours goes to higher tones across D1.
You also have a couple of spikes suggesting something like EMI? 

[Weaver]

Kitz' explanation of FPGA is exactly dead on, soft hardware, which is field-configurable enough to allow the complete change of the design by the rewriting of the innards of a chip, a bit like blowing a PROM. But FPGAs are very flexible as to what they can do, unlike PROMs which can never be anything other than a PROM.

[ejs]

The trouble is, a line card being "vectoring ready" doesn't necessarily mean it can do any vectoring itself. It could be vectoring ready in the sense that it could supply all the needed data to a vectoring engine located on a separate card, which the M41 doesn't have a slot for.

[tbailey2]

There are some more sortable columns now in the full page All User Stats.

See:
http://forum.kitz.co.uk/index.php/topic,14361.msg311707.html#msg311707

[kitz]

The trouble is, a line card being "vectoring ready" doesn't necessarily mean it can do any vectoring itself. It could be vectoring ready in the sense that it could supply all the needed data to a vectoring engine located on a separate card, which the M41 doesn't have a slot for.

Agree.  It is capable of vectoring at a line card level, but it is unlikely that BT would due to inefficient use of lines.  System based vectoring with a specific vectoring module is far more efficient.   The problem with the M41 is there is nowhere to slot in a vectoring card.   What I was saying with my statement is that the line cards themselves are VTU-C64s with the Vinax V3 chipset and are capable of the latest technologies.. therefore it is unlikely to be physically swapped out for anything else.  It is far more likely they have made some changes by FPGA and that number is an indication of what the linecard is programmed to do.

Those changes could be the ability to perform retransmission it could also be something else for example bonding.  (I am not saying they have applied bonding - it was just purely another example of what can be changed using FPGA!) aiui Broadcom's PhyR could be enabled using FPGA and firmware upgrade to the DLSAM, so g.inp could be a likely candidate.

What we observed with g.inp on the Huawei's is that this time last year over a period of weeks the Huawei cabs were upgraded.   Once all the cabs where done, then they started transferring lines over to the DLM retx profiles. 

[Chrysalis]

Mine hits -105 too.   
Most of my crosstalk is in the 8Mbps region.   Always has been even prior to me getting FTTC, I first noticed it about a year or so after getting adsl2+.
I used to read crosstalk from the bitloading graph - (this was way before we got QLN figures).

Mine hits the adsl tones more than yours, but yours goes to higher tones across D1.
You also have a couple of spikes suggesting something like EMI? 

I meant in the same range, where you hit -105 I cannot even use much due to adsl power cutback hence that area having lower crosstalk, but if you look at the rest of the range your cross talk is lower.

[WWWombat]

On the timing of this...

Some networks employ a network freeze over Christmas - essentially preventing any software upgrades being rolled out from the beginning of December through to the end of January.

Given we saw this timing last year for Huawei, and repeated this year for ECI, I wonder if Openreach have this kind of freeze?

[JamesK]

The ECI DSLAM I'm connected to was upgraded on Jan 19th. The chipset version changed to 0xb206.

Since the upgrade there's been a noticeable drop in the SNRM for both up and down. Previously down held steady around 6.6-6.4 it's now around 5.6, and up was at 6.8 and it's now at 6.0. My stats are on MDWS as JamesK.

I've not resynced the modem since the update and I may do that today to see what happens with a resync done during the day when the SNRM is at its highest.

[Bowdon]

I've looked at my last stats and noticed I'm still on chipset version 0xb204

I wonder if all ECI cabinet people were on 204.

I wonder what the reason is to update people to 206 ?

[kitz]

've looked at my last stats and noticed I'm still on chipset version 0xb204

Im still on 0xb204 too.  My uptime is currently 52 days.

iirc it took them about a month or so to upgrade all the Huawei cabs.   Then if it is DLM related it could take another couple of months to apply line profile changes. 

[ejs]

If the 0xb206 change is related to the changes in the EMP3050 ECI Release Notes, then there is nothing much of interest for end users.

[kitz]

I think you may be right

If you note, they have been messing with power so that may explain where the upstream Power reporting bug has crept in.