Print

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

[Greybeard33]

Recently I noticed a resync in my modem log that looked different from a DLM-triggered on-the-fly one - off line for over 7 minutes from 03:07am. So I took a snapshot of the modem stats for the first time for a couple of months (the line had been boringly stable - nearly 5 months since the last resync).

Comparing the before and after stats (attached), I noticed a slight change in the Discovery Phase Band Plan. The uppermost tone in the D3 band has changed from 3959 to 3971. (My line is too long to use the D3 band, so there was no change to the Medley Phase tones.) Also the DSLAM has now started reporting the US QLN, HLog and SNR to the modem - I had understood only ECI DSLAMs supported this?

I suspect that the interruption in service was for my DSLAM to receive a firmware upgrade that included these changes. Does anyone know if BTOR is rolling out such an upgrade to its Huawei DSLAMs? Just curious.

Since the change, my DS sync and max attainable rates seem to have decreased slightly while the US rates have increased slightly. Consequence or coincidence?

[kitz]

Sorry I cant answer your question as theres no huawei dslams around here and Ive not really seen many stats from them and therefore wasnt aware of the differences.

Perhaps someone like BE or Colin who have been on fftc longer than I have may be able to say more.

[Bald_Eagle1]

Comparing the before and after stats (attached), I noticed a slight change in the Discovery Phase Band Plan. The uppermost tone in the D3 band has changed from 3959 to 3971. (My line is too long to use the D3 band, so there was no change to the Medley Phase tones.) Also the DSLAM has now started reporting the US QLN, HLog and SNR to the modem - I had understood only ECI DSLAMs supported this?

That's an interesting observation, especially the reporting of US data.

I too can't use the D3 band due to line length, but I'm quite interested in seeing my US data.
As you mentioned, that was NEVER available from a Huawei DSLAM previously.

I haven't read of anyone else seeing this band plan change, yet & mine is still showing 3959 as the highest available tone.

Your U2 QLN graph looks 'interestingly' & disproportionally 'noisy'.
Hence nothing showing in the Hlog or SNR graphs.

I'd be interested to see the Plink log for those graphs, just in case I have missed anything in plotting the data US when obtained via a Huawei DSLAM.

Could you possibly zip it & post it here?

Just for curiosity, do you know your line length from the cabinet?

[Greybeard33]

Comparing the before and after stats (attached), I noticed a slight change in the Discovery Phase Band Plan. The uppermost tone in the D3 band has changed from 3959 to 3971. (My line is too long to use the D3 band, so there was no change to the Medley Phase tones.) Also the DSLAM has now started reporting the US QLN, HLog and SNR to the modem - I had understood only ECI DSLAMs supported this?

That's an interesting observation, especially the reporting of US data.

I too can't use the D3 band due to line length, but I'm quite interested in seeing my US data.
As you mentioned, that was NEVER available from a Huawei DSLAM previously.

I haven't read of anyone else seeing this band plan change, yet & mine is still showing 3959 as the highest available tone.

Your U2 QLN graph looks 'interestingly' & disproportionally 'noisy'.
Hence nothing showing in the Hlog or SNR graphs.

I'd be interested to see the Plink log for those graphs, just in case I have missed anything in plotting the data US when obtained via a Huawei DSLAM.

Could you possibly zip it & post it here?

Just for curiosity, do you know your line length from the cabinet?

Plinks attached, zipped together with the related plots. I have added a more recent one taken after another resync at a "quieter" time of day. I am not sure the U1 QLN looks disproportionate, but the U2 curve is again way out of line with the D2 & D3 bands and again U2 does not appear on the Hlog plot (would not be expected to appear on the SNR plot, since the band is not in use?) I notice also that the shared band between U0 and D1 is not plotted on either the QLN or the Hlog graphs - is this the same as with an ECI DSLAM?

The September snapshots were taken with the v1.1 release of your program, whereas the July one would I think have been with v1.0. As a check I did try taking a recent snapshot with the batch file version from last year, and that gave similar plots of the US QLN, Hlog and SNR graphs.

The distance by road to the cabinet is 0.98km measured by the Google Maps pedometer, but I do not know how much the underground wiggles add to this. I believe it must be copper cable to give such good speeds.

[Bald_Eagle1]

I notice also that the shared band between U1 and D1 is not plotted on either the QLN or the Hlog graphs - is this the same as with an ECI DSLAM?

Yes, it's the same with the ECI DSLAM.
If you zoom in, you can just see a tiny bit of blue shared band between U0 & D1 in the QLN & Hlog graphs.

That's the way the Huawei modem reports the raw data, but I don't know if is a modem glitch or not.

The distance by road to the cabinet is 0.98km measured by the Google Maps pedometer, but I do not know how much the underground wiggles add to this. I believe it must be copper cable to give such good speeds.

I am a similar distance from the cabinet, but your connection performs much better than mine.

Mine was O.K. at around 30 Mbps when it was repaired in May 2012.
It stayed like that until January 2013 when it started dropping in stages to its current 20 Mbps.

This speed reduction is being put down to crosstalk as other users have been connected, although a number of visiting engineers couldn't actually prove it as such.
Roll on Vectoring that seems to be my only hope of seeing higher speeds again.

[Greybeard33]

I notice also that the shared band between U0 and D1 is not plotted on either the QLN or the Hlog graphs - is this the same as with an ECI DSLAM?

Yes, it's the same with the ECI DSLAM.
If you zoom in, you can just see a tiny bit of blue shared band between U0 & D1 in the QLN & Hlog graphs.

That's the way the Huawei modem reports the raw data, but I don't know if is a modem glitch or not.

Oh yes, I see it now. The U0 band looks a bit peculiar too. (Sorry - I was muddling the upstream band numbers in my previous post - will correct it.)

Mine was O.K. at around 30 Mbps when it was repaired in May 2012.
It stayed like that until January 2013 when it started dropping in stages to its current 20 Mbps.

This speed reduction is being put down to crosstalk as other users have been connected, although a number of visiting engineers couldn't actually prove it as such.
Roll on Vectoring that seems to be my only hope of seeing higher speeds again.

Crosstalk seems to affect some lines much more than others. I was an early adopter of FTTC, yet the performance of my line has (touch wood!) changed very little over two years. I guess it is "the luck of the draw" as to how the cables lie in the ducts (except where crosstalk might be being cited as the "catch-all" excuse to avoid expensive investigations of poor performance!)

[Black Sheep]

I guess it is "the luck of the draw" as to how the cables lie in the ducts (except where crosstalk might be being cited as the "catch-all" excuse to avoid expensive investigations of poor performance!)

I think the cross-talk is more to do with the amount of users within the cable, rather than how they lie separately within a duct. But with the major factor being FEXT, actually at the FTTC DSLAM. I've seen images taken by thermal cameras that show the difference to a DSLAM with vectoring applied. It's far from being a 'Catch all' excuse, although I will admit some engineers may wittingly or unwittingly make this statement when faulting a circuit. Poor training and knowledge share being the main culprits. 

[Greybeard33]

I think the cross-talk is more to do with the amount of users within the cable, rather than how they lie separately within a duct. But with the major factor being FEXT, actually at the FTTC DSLAM. I've seen images taken by thermal cameras that show the difference to a DSLAM with vectoring applied.

Yes, of course you are right that that it is the proximity of pairs within the same cable that affects the severity of Far End X-Talk. From a bit of googling I gather that it is short lines, which use the highest tones, that are the worst affected by crosstalk and so benefit most from vectoring, whereas the effects are proportionately much less on lines that are too long to use the D3 and U2 bands.

Which might explain why my long line has not been much affected by FEXT, and also suggests that BE might be over-optimistic in hoping for a big improvement from vectoring on his long line.

[Black Sheep]

Again, my bad, I meant to type 'NEXT' .......... not 'FEXT'. So hopefully BE will see noticeable changes ??

[Greybeard33]

Again, my bad, I meant to type 'NEXT' .......... not 'FEXT'. So hopefully BE will see noticeable changes ??

Hmm. I am no expert, but from what I have read vectoring is intended to reduce FEXT not NEXT. Near End X-Talk can be mitigated by band-pass filtering in the DSLAM and modem to attenuate interference between the upstream and downstream tone frequencies - I presume this is already implemented?

[NewtronStar]

I presume this is already implemented?

I think vectoring is wee bit behind schedule if my link is correct ?

http://www.ispreview.co.uk/index.php/2013/08/bt-make-final-adjustments-for-faster-fttc-broadband-vectoring-trial.html

[burakkucat]

I think vectoring is wee bit behind schedule if my link is correct ?

http://www.ispreview.co.uk/index.php/2013/08/bt-make-final-adjustments-for-faster-fttc-broadband-vectoring-trial.html

Looking at that link, I am amused to see a hard-hat (with chin strap fastened) and safety spectacles being worn by the Engineer 'attending to' (or 'posing in front of') that Huawei cabinet.

. . . preparations have apparently taken slightly longer than expected. The good news is that Openreach have now finished installing the necessary DSLAM hardware into six street cabinets around Barnet (London) and Braintree (Essex) in England.

So those six cabinets have now been fitted with their Huawei MA5603 subracks.

[Black Sheep]

Again, my bad, I meant to type 'NEXT' .......... not 'FEXT'. So hopefully BE will see noticeable changes ??

Hmm. I am no expert, but from what I have read vectoring is intended to reduce FEXT not NEXT. Near End X-Talk can be mitigated by band-pass filtering in the DSLAM and modem to attenuate interference between the upstream and downstream tone frequencies - I presume this is already implemented?

I've no idea with vectoring, tbh. I keep seeing the odd snippet of info but can't be bothered with getting 'in deep' with it, until it's implemented. Having seen the pictures of the DSLAM thermal imaging, before and after vectoring was applied, i assumed that it eradicated NEXT as much as FEXT, but you've informed me otherwise now, so I'm a little bit more educated in it all.

The only bits I know are, 'aliens' or 'disturbers' are completely counter-productive to vectoring, well anything over 5 'aliens' that is. Therefore, from what I gather, all CP's will have to agree to have their lines vectored ?? Even our testers will have to have some kind of update, or different module to attach in order not to become a 'disturber' whilst we carry out faulting techniques.
The graphs that I have seen show that short to medium lines gain massive improvement, but that longer lines also show some improvement as well.

That is about as much as I know at this moment in time. I get to know more info on here, than I do from official work-streams !!     

[Chrysalis]

on my line if the issue is crosstalk the tones affected the most are D1 and D2, D1 the worst.  D3 barely affected at all. 

When I had a 90mbit attainable my D1 had higher snr then D2 as one would expect and also higher bitloading, now crosstalk has made D1 and D2 almost equal.  Its D1 and to a lesser extenct D2 where my sync speed has been lost.

I think when people say crosstalk affects short lines more they rather mean crosstalk is the biggest issue for short lines as when attenuation is low external interferience has less affect.  I would expect vectoring to help all lines not just short lines but shorter lines will see bigger speed increases due to the fact they use more tones.

eg. even tho Greybeard33 has a longer line than me and cannot even use D3, his snr on D1 is comparable to mine as crosstalk has trashed my D1 signal. But my D2 is higher than his D2 and I have a D3.

[Greybeard33]

on my line if the issue is crosstalk the tones affected the most are D1 and D2, D1 the worst.  D3 barely affected at all. 

When I had a 90mbit attainable my D1 had higher snr then D2 as one would expect and also higher bitloading, now crosstalk has made D1 and D2 almost equal.  Its D1 and to a lesser extenct D2 where my sync speed has been lost.

I think when people say crosstalk affects short lines more they rather mean crosstalk is the biggest issue for short lines as when attenuation is low external interferience has less affect.  I would expect vectoring to help all lines not just short lines but shorter lines will see bigger speed increases due to the fact they use more tones.

eg. even tho Greybeard33 has a longer line than me and cannot even use D3, his snr on D1 is comparable to mine as crosstalk has trashed my D1 signal. But my D2 is higher than his D2 and I have a D3.

I have not seen your stats, but are you sure the issue you have in D1 is caused by crosstalk from other VDSL2 lines, not just the power mask applied to your line at the DSLAM, up to Tone 512, to protect adjacent long ADSL2+ lines from crosstalk? Theory says that crosstalk increases with frequency, so the D3 band should be the worst affected if the source is another VDSL2 line.

My cabinet is actually closer to the exchange than to my house, so adjacent ADSL2+ lines presumably have a fairly strong signal and so the power cutback needed on my line may be less than on yours. I used to get 18Mb/s sync when I was ADSL2+ myself.