Print

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

[kitz]

Does anyone elses FTTC connection do this... 

Something I happened to notice is that by far most of my bit swap activity seems to be in the very low frequencies.

I also notice that sometimes the lower frequency tones often aren't fully bitloaded. Yet at other times they are.
See graph 1 - low bit-loading
See graph 2 - more normal bit loading.



I was looking at the SNRm per tone in DSLstats and every so often SNR for tones 32 to 95 would drop to zero. So I monitored over a period of half an hour and made an animated gif out of them.




I had noticed DSLstats doing this the other day and just put it down to a possible reporting fault in DSLstats, but I notice its sometimes there is HG612ModemStats too.
Is this something anyone else sees in that range?  Is it a modem reporting feature, or could it perhaps be something to do with my line...  or is it nothing?

[Chrysalis]

not sure, the only thing I observed is you seem to have very excellent snr across the entire range.  Also normally the lower tones get battered by the power cutback on the adsl frequencies.  Yours seems barely affected, but I dont think thats related to what you seeing.

What is odd is that when your bitloading changes the snr doesnt.  A problem that would be enough to cause that kind of change would affect your snrm for sure I would have thought.

[kitz]

>> A problem that would be enough to cause that kind of change would affect your snrm for sure I would have thought


SNRm often looks ok when viewed as an average over the 3 bands.   When you split it between the 3 frequencies it doesnt look quite so healthy.

It should be a good 80/20.   However even with an 18dB/12.5dB margin there are a few times when the SNRm goes so low it loses sync.

[roseway]

I do find on my ADSL2+ connection that the HG612 often reports zero values for the SNR in the upstream range, so this may be a bug/feature in the HG612 firmware.

[Bald_Eagle1]

FWIW, on VDSL2 services, the HG612 connected to a Huawei DSLAM ALWAYS reports zero values for upstream SNR per tone.

(Likewise for QLN & Hlog)




However, upstream SNR per tone is occasionally reported following a resync when connected to an ECI DSLAM (as per Kitz's connection).

DS & US SNRM are always reported regardless of the DSLAM though.

See the attached example montages from another user's ECI DSLAM connection, 24 hours apart, having resynced in between.

 

[kitz]

I do find on my ADSL2+ connection that the HG612 often reports zero values for the SNR in the upstream range, so this may be a bug/feature in the HG612 firmware.

irrc some of the ST585 versions do the same on adsl2+ :/

However, upstream SNR per tone is occasionally reported following a resync when connected to an ECI DSLAM
...
See the attached example montages from another user's ECI DSLAM connection, 24 hours apart, having resynced in between.

Thank you for supplying those, its interesting to note just how low my bit loading is in the 1st 500 tones.  I thought it may have been some sort of PSD mask, but looking at the other, mine is quite poor in comparison. Power cut back could account for some of it..  but there definitely is a lack of bit loading at times in those lower tones and its where I see the most bitswap going on.

---

I'm assuming you mean the lack of figures in the graph labelled 'Signal to Noise Ratio' rather than 'SNR per tone'.

I've looked through my past graphs, and there seems to be no rhyme nor reason as to when the upstream SNR per tone is displayed.  It certainly doesn't seem to follow a resync on my own connection and can be a wee bit random.  I even have a couple of graphs when it displays just some of the upstream bands (see attached).

During the period I was logging it seemed to report 0db in approx 1:5.   I'm therefore wondering if its a 'feature of the HG612 on ECI Dslams' were perhaps a figure isn't returned every-time.   This is what I meant when I said "but I notice its sometimes there in HG612ModemStats too."

The fact that its not reported sometimes on other connections too, gives me some assurance that its more likely that for some reason or other it returns a 0 figure.


----
edited.

As I look back through previous bit loading.... I actually had some more decent bit loading graphs in the earlier days than what Ive been getting the past week...  and I was at times seeing something that looked more like Id expect     

[Bald_Eagle1]

I'm assuming you mean the lack of figures in the graph labelled 'Signal to Noise Ratio' rather than 'SNR per tone'.

Yes, that's the one. It does report SNR on the y axis per tone on the x axis.

I've looked through my past graphs, and there seems to be no rhyme nor reason as to when the upstream SNR per tone is displayed.  It certainly doesn't seem to follow a resync on my own connection and can be a wee bit random.  I even have a couple of graphs when it displays just some of the upstream bands (see attached).

During the period I was logging it seemed to report 0db in approx 1:5.   I'm therefore wondering if its a 'feature of the HG612 on ECI Dslams' were perhaps a figure isn't returned every-time.   This is what I meant when I said "but I notice its sometimes there in HG612ModemStats too."

The fact that its not reported sometimes on other connections too, gives me some assurance that its more likely that for some reason or other it returns a 0 figure.

From what I have witnessed, whenever US SNR, QLN & Hlog per tone are reported following a resync (not every resync though), it continues to be reported dynamically until the next resync, when it might cease until the next resync & so on.

The fact that on your connection, sometimes the lower frequency SNR per tone data is completely absent yet higher frequency US per tone is still reported does seem to further confirm the line fault.

We have also seen your US SNRM per band graphs where the plots cross over & demonstrate other unusual behaviour over time.

I have never seen any of these issues previously & I have studied plenty of data & graphs from quite a number of VDSL2 connections (from the very best, to the very worst).



So no, I don't believe that what you are witnessing is anything at all related to a 'feature', rather it is clear proof of an intermittent fault.

Additionally, the issues you are now experiencing with telephone communications & the effect they are having on your VDSL2 service further reinforces the fault theory.

It really is a shame that the recent engineer's visit wasn't more fruitful, as it has just prolonged the inevitable.



With a bit of 'luck', you will soon completely lose broadband and telephone services as the SLA for reinstating telephone services should then kick in & the fault will have to be located & repaired within a reasonable timescale (unless there is actually more than one fault  ).

[ColinS]

Just to add my bit of confusion to the debate:

I believe that I too have noticed that the shared tones (particularly 32-95) seem to be most affected by (i.e. selected for) bitswapping.  Sometimes they're there, sometimes they're not.  I too have wondered whether it was a modem/DSLAM artifact as BE has seen, or (no accusation here) it was a DSL/HS612_Modem stats artifact.  However, I managed to convince myself (if only at the time!) that it was actually happening as there was clearly bitswapping activity recorded against those tones.  However, if the data was here one minute/gone the next, it would be impossible for any program to know if this had actually been caused by swapping, or just because it wasn't there, and so would report it as bitswapped.
Nevertheless, I have seen this (appear to) happen consistently over several months.  The only time it didn't seem to happen (at least, not as much) was when either using the new BLOB on the 612 or using the 622.  Both firmwares are thought to prefer to avoid using the shared tones in favour of higher bitloadings in the US or DS bands.

[Chrysalis]

kitz I do believe on the best lines BT are reducing power output on the early tones to help longer lines.  A good FTTC line has a lot of headroom over 80/20.  You can see much of your 2nd upstream channel unused instead it loaded up the 3rd channel.

Regarding your snrm, my comment was that if the line was somehow losing the available signal on those tones causing the bitloadign to go down then this would be reflected on your snrm, even if a 0.1db drop I would expect to see something, yet your snrm doesnt budge.

[kitz]

>> So no, I don't believe that what you are witnessing is anything at all related to a 'feature', rather it is clear proof of an intermittent fault.

I think I misunderstood what you were getting at by showing the other graph in that sometimes it didnt show up on theirs too.

>> With a bit of 'luck', you will soon completely lose broadband and telephone services

Well it does seem to have deteriorated further this week, its a damn shame in situations like this, that it cant be picked up before it fails completely.


>>> I too have noticed that the shared tones (particularly 32-95) seem to be most affected by (i.e. selected for) bitswapping.  Sometimes they're there, sometimes they're not.  I too have wondered whether it was a modem/DSLAM artifact as BE has seen, or (no accusation here) it was a DSL/HS612_Modem stats artifact.

This is why I thought I'd ask if anyone else has seen this happen, it seems rather strange, but as BE says, I am seeing rather strange things happening with my line atm so its a case of trying to find out if its related to the line fault or something else.


>> my comment was that if the line was somehow losing the available signal on those tones causing the bitloadign to go down then this would be reflected on your snrm.

Yes I agree - in normal circumstances I would too...  but my SNRm seems to be doing rather weird things when you look at the 3 bands individually..  they will even cross over.  Its like when say band U1 looses a load of SNR, then from somewhere band U2 will magically be able to find some more SNR from somewhere and the agregate SNRm will stay the same. 

The fact that BE's HG612 modem stats splits and shows the 3 bands separately, we can see that something strange is occuring,  theres a classic example of this in my post here.
I love DSLstats because you can see what is happening 'real time', but it shows aggregate SNRm which will sometimes stay the same despite what's happening in the 3 separate bands. 


So where does U2 suddenly get the additional SNR from when its lost in Band U1.  First thoughts would be an increase in gain for U2, but no my power levels remain the same so its not that.  I dont think anyone before has seen this weird band-crossing that Im getting.   It could be that some people do, they just arent using BE's scripts, because it doesnt show in programs like routerstats and dslstats etc.

I guess Im just trying to see if I can pick anything up which could possibly help pinpoint my line fault.