Print

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

[WWWombat]

Ta.

I wonder why there isn't a straight policy about whether the tie pairs should be in strips.

Do strips ever get retro-fitted in PCPs? Is there any sort of "tidy everything up" policy?

[Black Sheep]

Considering the amount of working circuits in any one Cabinet, it's surprising there aren't a plethora of faults raised every time we enter such a structure. It's a fact that 'Human intervention' in any part of the network, has a potential to inadvertently affect other circuits ........ but we don't have as many Cab faults as you would maybe imagine ?.

That said, there are always anomalies ........ and we have a system in place called 'Play your Ace' whereby every month a high-fault node will be identified and submitted to our other departments for an uplift ........... not just Cabs, it could be a faulty length of cable, a weak joint etc etc .......

As with any business, there are always budgets ............ and the money has to be appropriated to where there will be maximum gains. It works, by the way. 

[NewtronStar]

Well there you go that's were crosstalk comes from inside the PCP cabinet

[WWWombat]

That said, there are always anomalies ........ and we have a system in place called 'Play your Ace' whereby every month a high-fault node will be identified and submitted to our other departments for an uplift ........... not just Cabs, it could be a faulty length of cable, a weak joint etc etc .......

Haha - we would have something similar.

The code we wrote was in systems that had longevity - so stayed around for a long time, being added to again and again. Each new project would spend (of course) the bulk of time & money developing the new features that the marketing people had figured was best - though we always had to figure out how to add that in ways that stayed maintainable. But we also had some budget that we were allowed to spend on fixing our own blunders. Something that didn't turn out too well in a previous project, or something that was getting a lot of attention in the maintenance group.

As one of the architects, one aspect of my job was to figure out the candidates in our subsystem, and justify to the managers why it was worth spending some money on it. It even worked sometimes, but boy - did the marketing guys try to keep pushing that stuff out again!

[WWWombat]

Well there you go that's were crosstalk comes from inside the PCP cabinet

Crosstalk between lines is inversely proportional to the distance between the lines. That is, crosstalk is worst when the wires are squished together tightly, next to one another, and least when the wires run separated by a gap.

The air gaps in the PCP help reduce crosstalk; wires running next to each other within one cable are worse; in fact wires running next to each other within a subgroup of a cable (aka a "binder"; for example, a 100-pair cable is probably internally sub-divided into 4 binders of 25 pairs) is worst.

The worst place for crosstalk is likely to be a pair in the middle of a binder surrounded by pairs that are all carrying VDSL2 too ... which would be in the tie cables between PCP and DSLAM. Thankfully, the tie pairs are fairly short - which helps limit crosstalk. Yes - crosstalk is another reason why the PCP and FTTC cabs shouldn't be far apart!

Take a look at this crosstalk "heatmap" of a 100-pair cable, subdivided into 4 binders:


You can see the worst crosstalk happens between pairs in the same binder (the "squares" apparent on the diagonal).

If a second 100-pair cable was pulled into the duct in parallel to this one, there would be very little crosstalk between pairs in the separate cables. There would be just too much of a gap between the,.

[broadstairs]

Well DLM seems to have its act together at the moment  it intervened again this morning reducing the impact of interleaving again. I hope I'm not being too optimistic to think it might reduce further over the next couple of days 

Stuart

[broadstairs]

Going to have to keep an eye on my line as the phone still causes a glitch on both u/s and d/s SNRM, not huge but certainly noticeable, had a call at around 09:30 today which shows up the glitch.

Stuart

[broadstairs]

Just had DLM intervene a while ago to reduceinterleaving again but now my u/s sync has gone silly again with U1 & U2 bands at zero and a sped of just over 400kbps.

Stuart

[WWWombat]

And again attenuation rises.

Strangely, when looking at the line attenuation figures for the individual bands, they all follow this increase except U1, which does the opposite.

Time to push TalkTalk.

[NewtronStar]

And try to get the OR Engineer to run one of those CIDT tests (Copper Integrated Demand Testing) on your line

[broadstairs]

Well I did get a unsolicited text from TT this afternoon saying they knew I had a problem so that might just be hopeful. I have not yet rattled their cage as there is usually no one there at weekends unless I speak to the Indians (not something I want to do really!)

Stuart

[Black Sheep]

And try to get the OR Engineer to run one of those CIDT tests (Copper Integrated Demand Testing) on your line

A CIDT test should be run at the 'Fault reception' level.

[broadstairs]

Another re-sync tonight and all 3 u/s bands have come back but my speed is well below what it should be at 6586kbps.

Stuart

[broadstairs]

DLM intervened again this morning and u/s back to normal d/s at just under 60000kbps and fastpath. So looks like the problem has cleared again --- for now.

Stuart

[WWWombat]

Yes, it looked like the line cleaned up around 6am, and the removal of FEC+interleaving bumped speeds up to a 60/20 banded speed, with attenuation back to the normal level (a drop of 0.5dB from Sunday's level).

However, things went wrong again at 08:52; attenuation jumped by the 0.5dB amount (so still not up to the "fully bad" level), and SNRM was haywire. Then another resync 5 minutes ago.