Print

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

[RTouris]

Could anyone provide an educated guess about what might be the underlying cause of this repetitive bitswapping that gets triggered every day at apprx. 2000 and lasts all the way up to 0200hrs? This is on a long exchange line which maxes out at ~35down/8up. It's important to note that there's no respective increase of CRC/FEC errors during this period, it's just bitswapping that goes pear-shaped...

Would I also be right to assume that the dip in D1 over the first half of the segment is attributed to crosstalk from other ADSL connections? (tones 60-600 / 215-2560kHz)

[burakkucat]

If I am remembering correctly, I think you are located in Greece? Assuming yes and, if you have an exchange based VDSL2 service, then the dip (or notch) seen in the DS1 band cannot be down-stream power back-off (DSPBO), with which we are familiar, for cabinet based VDSL2 service in the UK. Hence, logically, it must be the result of cross-talk with other xDSL services. (ADSL2+ will use sub-carriers 6 to 511.)

The cause of the bit swapping pattern that you are seeing will be down to something switched being on for a six hour period, possibly time-clock controlled. The fact that you are seeing the bit-swapping, without any errors being recorded, shows that the technique is working well and is keeping your service stable.

[RTouris]

Thanks for your input burakkucat - much appreciated, with most of your assumptions being spot on btw

On a sidenote any idea why DSLstats 6.5.9 is having a hard time differentiating between the U1 and D2 colour codes correctly? v6.5.0 is much better at this...somehow the current version misses it completely showing these as "other"...Tone-wise both are within the appropriate limits, which gives?

[roseway]

A change was made in DSLstats v6.5.2, which was intended to fix incorrect band allocation when band U0 is unused. As far as I know, this configuration doesn't occur in the UK, and I hadn't previously considered it. From what you say, it appears that I fixed the issue for the person who reported it at the time, but made it worse for your configuration.

Unfortunately the time I spend looking at screens is limited by a personal difficulty, so I can only apologise for not being able to fix it now.

[RTouris]

Thanks for the reply roseway, it appears that this is the case indeed. There's obviously no hurry in updating - I was just curious as to why this is Hope you get your troubles sorted as soon as possible

[RTouris]

[update]

no progress on the bitswapping front however..

..having made some optimisations on the cabling front I'm now pushing a further 3mbps out of this long line (38mbps).

One thing I haven't yet managed to battle is the dual interference as noticed in the QLN graph above at approximate ranges of 6.10-6.20Mhz and 7.15-7.55Mhz which both appear to have a knock-on detrimental effect on the bits the line is able to carry at those respective ranges.

Could someone provide some info as to what might be the underlying cause?

Thanks!