Print

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

[ColinS]

Here are 2 examples from a high speed connection where remote monitoring commenced last night.

The stats were harvested on a schedule at 22:00 last night & at 06:00 this morning.

The bitloading differences at the lower frequencies are very clear.

I can only put it down to the modem not having completed its own update at the time my program harvested the stats for our monitoring as SNR was only very slightly lower last night.

I  have two almost identical examples  (albeit different loop lengths), one taken as one of your manual snapshots about 22:07 last night, and the other scheduled at 08:00 this morning:
Is any one on the forum a statistician?  8) If (say) the HG612 harvests the stats from the line once every 10 secs, and this takes (I don't know) say 2 secs & you harvest once a minute from the HG612 (at an offset no. of secs), how often should the missing stats be caused by you harvesting at the same time as the HG612?  All the time? Quite often?  Sometimes? Almost never?
This is a very important point you are making Bald_Eagle:  This is spurious ... the 'apparent' bitswapping is not real, just caused by a harvesting clash that means not all the data subsequently presented to us by either your or Eric's tools has actually been (fully) collected by the HG612 at that point.  If so, and I am in absolutely no position to be able to know, how can we 'prove' it? By sampling the HG612 less frequently, or somehow finding out the HG612 schedule and avoiding it?  Would that mean that it would become much less likely that there would be 'missing' tones.  If so, if there were (say more than once in a reasonable period), would that mean that bitswapping was actually happening?
But I also notice that it's not just that some bins are empty ('missing'), some of the other adjacent bins also have values, albeit different (lower/higher).  Could a clash cause that too? And why is it that (only) the shared tones 32-98 seem to be affected more than others? 
This is a fascinating debate, but I know you have by far much more extensive experience with all this than many of the rest of us put together. 

[ColinS]

how often should the missing stats be caused ...?  All the time? Quite often?  Sometimes? Almost never?

I though I would take a look at the data I have already collected using B_E's can't_do_without ongoing stats logging, and see what sort of occurrences I have had. 
Since I started monitoring on 28 March, I configured his package to take 3 scheduled snapshots a day, at midnight, 8am and 4pm.  To date that's a total of 25 snapshots including 1 real DSLAM resynch, one false positive resynch, one manual snapshot and the occasional missing one.

Of those 25 snapshots, 11 have no shared tones and lower bit loadings in the lower half of D1, and 14 have the shared tones and higher bit loadings.  So, empirically answering my own question, it seems to happen 'quite often' - almost 50-50%. 
That seems higher than I would expect (but what do I know).  The 'clocks' for harvesting in the modem and on the machine from where we take our snapshots are unlikely to be in sync (are they?), so if the time taken by the modem to update the bitloadings is small compared to the interval between updates, would a harvesting clash occur as often as this?  I really don't know, but it kind of 'feels' unlikely.  However, common sense, to paraphrase what Wilde said, is not so common, and quite often not very sensible either!    (Well, at least mine, anyway!)
On the other hand, looking at the bitswapping stats, it seems (on my line) to happen at a rate of ~10-12bits/min.  So, over (say) 2mins, that's only about the same as 2 'fullish' tone bins - not enough to explain how they appear to 'vanish' in that same time period.
Does any of this help the debate?  I'm as confused as I ever was. 

[krypton]

On my connection it occurs extremely rarely. Now rs-w is running since 12 hours with a sampling time of 15 seconds. No wrong values were sent since this time.
I noticed that it affects exactly the first 1024 tones.

[Chrysalis]

My opinion is crosstalk is most evident on the lower tones when it occurs, and crosstalk on vdsl can be brutal I mean brutal.  If there is no fault with the software collecting those stats and the isnt banded (capped) then my first thoughts are crosstalk.  Need to see full stats really.

[ColinS]

My opinion is crosstalk is most evident on the lower tones when it occurs, and crosstalk on vdsl can be brutal I mean brutal.  If there is no fault with the software collecting those stats and the isnt banded (capped) then my first thoughts are crosstalk.  Need to see full stats really.

If you were referring to my own observations, then I'm sure that you're absolutely right, it is crosstalk. You can tell because my QLN noise floor is 10-20dBm higher than (say) BEs at ~-120dBm as opposed to his ~-140dBm.

I'm not surprised at all.  In fact it's what I expected atm.  Where I live is an area of significant broadband penetration of all kinds.  Although I can't know exactly what the mix of VDSL and ADSL is on my PCP, it would not surprise me if it were >50:50 already, a matter of some discussion elsewhere.  And it can only get worse until vectoring cancels some of it out.  Nevertheless, because I am (fortunate to be) ~150m from a (Huawei, sorry ) cabinet, my attainables are of the order of 92/32 Mb/s  (obviously capped lower).  So, from my personal point of view, the technology is working well, within its capabilities and limitations.

[waltergmw]

@ Coin,

As far as I'm aware there is only one physical size of ECI cabinet which can also be identified externally from a Huawei one, as it has many more ventilation slots especially designed for friendly "visiting" dogs !

The internals are also identical for ECI 128s and ECI 256s, except for terminating IDC connector blocks and, more importantly, the number of dual Telco 64 cables/connectors. Why they haven't put all four dual Telco 64 cables in beggars belief as any that require upgrades now must require a degree of dismantling live-working cabinets. They also seem to have ignored any cross-patching capability to overcome line card faults. I can't fathom why BT don't include at least dual ducts nor why they throw away 28 or 56 connections as they never seem (at least in this part of Surrey) to install 100 pr AND a 50 pr tie cable sets.

BT were especially stupid in Ewhurst as they only installed ECI 128s despite VERY strong comments as our Vtesse Networks project BT destroyed has specified cabinets with a total capacity of 500 services EACH. Two of the cabinets have run out of capacity already and they only have single ducts to the PCPs whereas BT always install double ducts when 2 pairs of 100 pr tie cables are installed initially. The third cabinet BT "saved money" by using an existing duct with other cables installed. They got the tie cables and the fibre one in but then had to try three separate visits before they managed to insert a rod to pull in the 5 pr telemetry cable. Only the Almighty knows (at least at present) how much damage the other cables have suffered. When any expansion of ANY service - including the mythical FoD (Ha Ha Ha) fibre cables - is required, road excavation will be mandatory.

Kind regards,
Walter

[Chrysalis]

looking at ECI's product profile the M41 seems the cheapest of the lot and combined with walter's observations it does seem BT still lack forward thinking and simply go for the cheapest of whats available again and again.

I have emailed ECI to ask if the M41 has any upgrade path to vectoring or if a complete swap of hardware is required.

[chuffer]

Just getting started with monitoring my stats.
BT/OR tell me my line length is 1400m but my 3 year old pole is not on their records and I think is 1100 at most.

would somebody please pass comments on how good/bad my stats are ?.

Main question is the small number of tones in use.

Thanks

[NewtronStar]

Well your able to use the D1 Band but the line attenuation on the D2 band is to high so the modem is unable to make use of this Band and hence the small number of tones, this would confirm your on a long line so I would go with the OR line length of 1400 meters.

There is one thing I noticed your still using the older firmware on your VDSL modem have you blocked the update or has it not been introduced to your area ? as the update may give you a slight increase in sync for the longer line EU.

[Bald_Eagle1]

I was once led to believe by a visiting engineer that my line length from the cabinet ws around 840m.

However, I am now aware that he hadn't taken any detours into account.

A different engineer showed me BT's actual Network Records that confirm my line firstly travels away from the direction of my home to a convenient road crossing.

It then goes past my house to a joint chamber, before doubling back to the pole mounted DP.
These detours add somewhere around 150m to 200m (maybe a little more) to my line's length, thus my physical line length is somewhere between 1000m & 1100m (or slightly more).




As mentioned by NewtronStar, the attenuation in the D2 band is too high for any use to be made of it & so high that not all the U1 band can be used.

You have a lower baseline of background noise than my connection, although it is quite 'spiky'.

I also see that quite unusually, Interleaving (albeit at quite a low depth) has been applied to your US, probably the reason for such low US attainable (Max) & sync speed (Path).




Unless you have blocked it, your modem's firmware is likely to be remotely updated within a few days.
The update, using a slightly different configuration of tones does appear to slightly assist longer connections.

Increased DS bitswapping is seen when using the updated firmware & FEC errors generally increase.
However, it does appear to make longer connections slightly more stable & able to slightly improve sync speeds.
 



Have you started logging/monitoring ongoing stats 24/7?
If so, you may be able to see patterns of fluctuating SNR, error counts etc.
Although, it does appear that your connection is longer than maine and/or it may include section(s) of aluminium cabling.




Is your connection stable, usually managing to stay up for many days at a time?

Mine used to resync every few days, but it recently stayed up for 50 days before I forced a resync & it has been up for over 16 days at the time of posting.

Before crosstalk started to affect my connection, it was able tosync at not much below 30/7.
However, I did see from monitoring ongoing stats, that noise has worsened (QLN) & Attainable/sync speeds deteriorated.
This happened in a few steps over around 8 months, which is probably attributed to additional users being connected at my cabinet.

I was one of the first to be connected, June 2011, so I didn't see much of an effect from crosstalk.



I have attached my snapshot montage from 10:00 this morning for you to compare against your own.

[burakkucat]

. . . thus my physical line length is somewhere between 100mm & 1100m (or slightly more).

<Cough!>   

[Bald_Eagle1]

Wishful thinking? 

[burakkucat]

. . . thus my physical line length is somewhere between 1000mm & 1100m (or slightly more).

<Double cough!>   

[Bald_Eagle1]

Struggling with a furball there b*cat?

O.K. 3rd time lucky then   

[burakkucat]

Struggling with a furball there b*cat?

<Nods.>

O.K. 3rd time luck then   

Shall we make that "lucky"?