Print

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

[roseway]

I also noticed the SNRm per tone seems to show 0DB for tones 1-30, yet bitloading shows those tones in use. Is this just a limitation of the modem reporting?

Yes, the HG612 often fails to report SNR for the first 31 tones. You can see the raw data from the router in Telnet data --> SNR.

[plexy]

Cool, yep seems that way 0Db for the first 30 in the telnet data.

Cheers!

[kitz]

this morning at 6:58 the upstream SNRm went to 1.6dB for about 5 minutes.

That is the type of thing I was looking for... because that is what will cause your line to drop and resync at lower speeds.   Once thats happened a few times then the DLM will start to take over and restrict attainable speeds. 

I have already considered the possibility that your speeds may be banded, due to at one point seeing some surplus SNRm, but you said a resync didnt give you any higher speed.   We'd need more information over a longer period though to say this for sure.

If you can get a pattern forming from DSLstats then it gives you something to go back to Plusnet with.

[plexy]

Great, thanks very much again!

This is the SNRm graph since last night, all stable but as you can see theres the massive dip im guessing between 6:55 and 7:05. You can also see an incoming phone call just after 11:32. between about 10am and 11:30 we ran the dishwasher, the washing machine, the plasma TV, both sky boxes and the boiler (with central heating turned on and using the thermostat). Minor changes in SNRm, but looks completely acceptable to me. BTW all times are GMT.

Im quite surprised to see all of the CRC errors and significant SNRm changes are only happening on the upstream. Any initial hunch as to why that is?

[burakkucat]

Yawn . . . b*cat awakes and attaches some graphs which have been generated from the data provided by plexy.

[plexy]

Morning B*cat and thanks for the graphs hope you had a pleasant catnap.

[kitz]

>> m quite surprised to see all of the CRC errors and significant SNRm changes are only happening on the upstream. Any initial hunch as to why that is?

Usually an indication of filters, internal wiring, or a physical line fault (HR). 

I'm also getting a feeling of deja-vu...  its a shame HG612 modem stats wont work on linux. 

I'd love to know if your upstream is doing anything like the graph in this post
http://forum.kitz.co.uk/index.php/topic,12660.msg240778.html#msg240778

[plexy]

Thanks for the info - filter is the one BT supplied that fits onto the NTE5 (with the separate vdsl connection on rj11 at the top) but I did hear there were some bad batches floating around. There is no other wiring on the line, though there is some extension wiring behind the NTE5 its not actually connected to anything, could that contribute?

Ill fire up a windows VM and run HG stats from that I tried wine but there seems to be some issues with it in the current unstable branch of debian.

*edit HG stats seems to be running now in a VM.

[plexy]

HGstats is now making graphs - dont seem to have a SNRM graph though? got SNR, bitloading, the portrait/landscape one, SNR per tone etc.. just no SNRM - have I mucked up the config?

[burakkucat]

Morning B*cat and thanks for the graphs hope you had a pleasant catnap.

You're welcome. And yes, thank you. I'm now thinking about my next meal. 

>> m quite surprised to see all of the CRC errors and significant SNRm changes are only happening on the upstream. Any initial hunch as to why that is?

Usually an indication of filters, internal wiring, or a physical line fault (HR).

I'm getting a preliminary sensation of frequency-dependent semi-conducting joint . . . 

I'm also getting a feeling of deja-vu...  its a shame HG612 modem stats wont work on linux.

I do have the new, revised version of a HG6xx_stats utility tucked in my 'what-not'. It will harvest the data from Huawei HG610, HG612 & HG622 devices and writes to a log file in the Eagle-specified format. It is fully functioning for any Linux kernel based OS -- the user would be expected to compile the source code for her/his target system -- but I have not yet fully incorporated the BGW compatibility code that my Avian colleague has requested.

When I last used the HG6xx_stats utility, I had it executing on a Raspberry Pi. Once sufficient data had been harvested from my HG622 modem/router (operating in ADSL2+ mode), I passed a copy of the log file to No-Feathers and he processed it with his code, running on BGW.

Below is an image of my R-Pi, upon which HG6xx_stats was executing. All communication to/from the R-Pi was via the Ethernet cable and the log file was written to the USB memory stick.

[Bald_Eagle1]

When I last used the HG6xx_stats utility, I had it executing on a Raspberry Pi. Once sufficient data had been harvested from my HG622 modem/router (operating in ADSL2+ mode), I passed a copy of the log file to No-Feathers and he processed it with his code, running on BGW.

Yes plexy, by all means, if you obtain sufficient ongoing data & snapshot data via your Linux system, I'll be happy to plot it for you if you could zip it & post it here.

I also believe HG612 Modem Stats will indeed work in a Windows VM on a Linux box, but I don't have a Linux system to test it on.



FWIW, I'm also with Plusnet who have recently had engineers investigating my loss of 10 Mbps from 30 Mbps to 20 Mbps.

It was interesting to see these test results on your connection from Plusnet:-

Bridge Tap   Not Detected
Radio Frequency Ingress   Not Detected
Repetitive Electrical Impulse Noise   Not Detected
Cross Talk   Not Detected


They didn't provide any results for those elements when testing my connection, although the speed loss HAS been put down to crosstalk (probably).

I can see the results of the speed loss in various graphs for my connection, but unfortunately, no-one has been able to actually confirm the cause(s).

[Chrysalis]

this morning at 6:58 the upstream SNRm went to 1.6dB for about 5 minutes.

That is the type of thing I was looking for... because that is what will cause your line to drop and resync at lower speeds.   Once thats happened a few times then the DLM will start to take over and restrict attainable speeds. 

I have already considered the possibility that your speeds may be banded, due to at one point seeing some surplus SNRm, but you said a resync didnt give you any higher speed.   We'd need more information over a longer period though to say this for sure.

If you can get a pattern forming from DSLstats then it gives you something to go back to Plusnet with.

kitz he is banded, can see in the plusnet info he pasted on the profile where it says 37-74.

[kitz]

Cheers... Must have missed that.. got distracted looking at the Bridge Tap, REIN, Crosstalk info which I'd not seen before. 

PN normally paste info of any tests run in your ticket and even the engineers notes if you ask..  but Ive not seen that particular test before.
I have KBD, GEA Service Test, RADIUS logs and a few GEA Test Detail reports - the last one of which was on the 05/09 ... none of which contain that info.

although the speed loss HAS been put down to crosstalk (probably)

Im still not convinced BE,  IMHO thats rather a lot to suddenly lose from x-talk.    I guess you will find out - if vectoring ever gets rolled out. :/

[Bald_Eagle1]

Im still not convinced BE,  IMHO thats rather a lot to suddenly lose from x-talk.    I guess you will find out - if vectoring ever gets rolled out. :/

I'm not 100% convinced either.
It wasn't exactly sudden though as the attached 240 day graphs show.

It looks like more of a power cut back, but no-one has been able to explain why.

[kitz]

Looking at sync theres 3 noticeable dates...  but that wont show the full picture as SNRm could have been on the decline anyhow.

Your power graph is weird, crosstalk does _not_ cause power-cutback.  Power-cutback does however cause lower SNR and lower sync speeds.  Having seen your power graph Im even less convinced its x-talk.

So just what has triggered power cutback on your line.  What does ring a bell is something called low power state which can cause FEXT for a neighbouring line.. iirc though it mostly only affects short lines.. and I didnt think BT employed it anyhow, preferring to auto-set the parameters based on min/max SNR figures.

Something to note ..  see when the engineer swapped my pair, look what happened to my power that day..  and why although I now have a steady line, yet the attainable stats and SNRm arent as good.  Why should a different pair to the same premises suddenly have more cutback applied to give a line that wont be able to attain as much speed as the previous?   It certainly implies all lines are not equal in areas where they should be, and could raise doubt about what parameters they are using for auto power cutback.


** HG612 stats doesnt ever show my U1 band because its too low for the graph...  I keep forgetting to ask if theres any way I can adjust the 'y' axis graphing parameters.


------

oops forgot to add graph