Print

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

[Chrysalis]

Ok

So I load my hg612 gui up to show line stats and this auto refreshes every second or so.

I then start an outgoing call.

During the call the downstream snrm drops from about 6.5db to about 5.6db.  (Approx 3mbit of attainable speed).
When I hang up the downsotream snrm recovers but the upstream snrm temporarily loses a huge chunk of snrm, down from 14.6 db to 8.4db. (Approx 10mbit attainable lost).  The upstream snrm recovers after about 2 seconds.

I had a line drop 2-3 days back when the upstream lost too much snr margin to hold sync, I wasnt here at the time, I now wonder if it may have been an incoming call or something.

[kitz]

The SNRm shouldnt change during a call, although I have seen downstream wobble on occasion by up to 0.5db which BT dont class as a fault.

In my mind though there is something going on, that dip in the upstream is weird..  out of interest do you know which band it affects (wondering if its the shared /0 band).  Ive seen some weird compensating across the bands happen on my own line and a phone call would cause the bands to 'cross over' in an attempt to compensate.    My fault was different in that it primarily affected the upstream and then would knock-on to the downstream.

If that happens each and every-time a call comes in then this is something that a decent engineer should be able to replicate.  Has your NTE been checked (thinking filtering)  there was apparently a whole faulty batch that where shipped out.   I hadnt heard of many NTE fails until a few weeks ago, but Ive since heard there was a whole batch of them that were shipped out around the time fttc started.    However, didnt you also have probs when on adsl too?  (cant recall now)

>> I wasnt here at the time, I now wonder if it may have been an incoming call or something.

It is possible.   I actually joked with my ISP on one of my tickets..  who needs an ansafone to check if anyone rings, when you have a line fault & DSLstats.   I presume that its too late to check 1471 now?

[Chrysalis]

yeah I am thinking of trying to find out if its certian frequencies but I think will be diffilcult to get that data as I have to time fetching the data right, probably inside telnet.

Of the 2 engineer visits I had since install the NTE wasnt checked or swapped.  I do know though that swapping the filter doesnt affect the downstream snrm changing (its done this for months), but the upstream going down I think is a new thing, I dont remember seeing that before.

I had huge issues on adsl but they were entirely different.  On adsl I didnt have variance during calls but the line was bad almost 24/7.  Whilst my vdsl is generally stable.  When the upstream snrm did drop the 3 times i tested today not a single crc error was logged from it, so it wasnt causing stability issues but the drop was pretty big and caught my attention.  My thinking is if its all squashed to a few tones, then it would be generating a huge burst of bitswapping which could make a modem resync.

So to recap I have swapped out the faceplate and tried alternate filters (when testing the downstream snrm on calls) and tht made no affect on that, havent tried doing this for the upstream and I havent touched the NTE socket itself, since the filter swap before did nothing the openreach vdsl faceplate is back on now.

[kitz]

My thinking is if its all squashed to a few tones, then it would be generating a huge burst of bitswapping which could make a modem resync.

Bitswapping in itself should cause a loss of Sync..  only if there wasnt enough SNR across tones to support the bitswap. 
However it wouldnt be unexpected to see lots of bitswap trying to auto-correct a noise burst issue.. before one of the more serious type errors is reported, which in turn will cause the resync.

With adsl bitswap can borrow across all the upstream or downstream channels.  With VDSL I would imagine it can only borrow over the relevant band.   
Not sure how it treats the shared band though... and thats whats making me go hmmm and ask about band 0

[Chrysalis]

yeah but I am wondering if its simply too much bitswapping at once to handle since bitswapping is designed to handle small shifts not large chunks at once.

I suspect as lower band because.

(a) its close to voice
(b) my lower band has low bitloading as my highest loaded upstream band is U2.  So problems on this band the line will tolerate better and I didnt even see 1 crc error during the drop.