Print

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

[Bald_Eagle1]

Thanks b*cat,

I have discovered that this page does appear to provide SNRM, sync & other information:-

http://192.168.1.1/html/status/xdslStatus.asp
Maybe it could be controlled a bit better in a bash script?


Paul.


EDIT:

It was interesting to note that I appear to be able to obtain the stats WITHOUT the need to log in to the modem itself, or the need to enable Telnet etc.
I wonder if a similar method could be used for automating the obtaining all the other stats that are used for the bit loading graphs etc.

Just a quick update Folks:-

I couldn't get RouterStats to work correctly in the end.

So, with a lot of help from others who shall remain nameless (unless they wish me to name them) I have developed a batch file to gather the stats from http://192.168.1.1/html/status/xdslStatus.asp, & use a Linux script for now to graph them.

For your delight, entertainment & comment, I have attached the graphs.

I only have a few hours worth recorded for now as I only got it working in the early hours of this morning.

I believe the BT modem HAS to be unlocked to obtain this detail.


Paul.

[attachment deleted by admin]

[burakkucat]

Hmm, someone has definitely made significant progress.

The graph formats look vaguely familiar . . . I'm sure I've seen similar, elsewhere.

Putting that aside, I am concerned with the sudden drops in the SNRM this morning. Do they correlate with any electrical activity from within your domain ("The Aerie")?

[Bald_Eagle1]

Putting that aside, I am concerned with the sudden drops in the SNRM this morning. Do they correlate with any electrical activity from within your domain ("The Aerie")?

Hi b*cat,

They do indeed DIRECTLY relate to land line phone calls that Mrs. Eagle made (dialing out, not answering).

It appears that whenever any handset is picked up, SNRM drops significantly & rises again as soon as the handset is replaced.

I have today tried adding brand new, previously unused filters that came with previous ADSL modems.
The additional filtering had no effect whatsover in resolving the dropping SNRM levels.

These events have not all been captured in the modem log/graphs as data is currently only captured every 2 minutes.
I might increase that to capture data every minute.

I currently just have 3 telephones connected:-

1 is plugged directly into the "new" SSFP AT the "new" NTE/5 Master socket (downstairs).

1 is plugged in upstairs via a double adaptor at what is now an extension socket (was the master socket prior to FTTC being installed).
This extension is hard wired from the "new" master socket along a spare pair in the braided cable mentioned previously (connected by the FTTC installing engineer).

1 is plugged in downstairs at the end of another extension, from the upstairs double adapter.

I have disconnected the Sky box & FAX machine, so the total REN is now 3, but SNRM still drops immediately a handset is lifted.

During the previous documented troubles I checked all this as a potential cause.
I never noticed SNRM dropping during phone calls.

I have only noticed this phenomenon very recently.
It may have coincided with the profile switch to 17a, but I can't be 100% sure.

CRC errors are currently almost 2 Million, following 1 day 12 hours broadband connection time.

My throughput speeds do NOT seem to be affected during phone calls & the FTTC connection is maintained despite dropping SNRM levels.

I wonder if the filtering in the SSFP is "faulty" (could lightning have damaged it?), or simply not suitable for the higher frequency 17a profile.

Am I correct in assuming the SSFP filtering should work both ways?
i.e. it SHOULD stop the broadband messing up phone connections & SHOULD also stop phone connections messing up the broadband?

Could THIS be a pointer to the issue that has attenuated my sync/throughput speeds for the last few months?

A graph of now around 19 hours worth of connection time is attached.
The most recent SNRM drop was at around 8:30 this evening,  when I simply picked up the handset that is plugged directly into the SSFP at the "new" master socket, with just the dial tone until it cut off.

Paul.

[attachment deleted by admin]

[burakkucat]

Something is not right.    (Apart from your scale on the X-axis of the graphs, that is. Perhaps you should awk '{ print NR+2, $4 }' or something similar . . . probably an easy fix.)

The SSFP filtering should, indeed, be operating "both ways". Just a moment -- I've had a sudden thought. Remembering discussions from the past with Messrs Ezzer & Razpag, I think what you are describing is symptomatic of an HR joint in the D-side cabling. Loop the line by picking up a handset and some current then flows around the circuit. Iffy joint, either HR or semi-conducting, reacts to the loop current and changes characteristics. Hence change in observed SNRM. I wonder if, by a spot of "fiddle faddle", you could log and then graph the downstream attenuation. (I'm sure Mrs Eagle wouldn't mind helping with the test by making telephone calls to her sister, first cousin once removed, great uncle Horace, hairdresser, etc.    )

Perhaps a weeks worth of graphs, both SNRM and Attenuation, presented to Plusnet will finally provide them with the evidence that OR will have to trace your D-side from the PCP to your NTE5/A, remaking each and every joint along the way! 

Finally, if I lived in your "Aerie" rather than my "Cattery", I would: (a) replace the front of the old NTE5/A (upstairs) with an LJU3/3A or, even better, an LJU4/3A (see this page) (b) earth the screening on your "link cable" (discussed above). 

[Bald_Eagle1]

Something is not right.    (Apart from your scale on the X-axis of the graphs, that is. Perhaps you should awk '{ print NR+2, $4 }' or something similar . . . probably an easy fix.)

Hi b*cat,

Thanks for spotting my "deliberate" mistake

I have now done it again using '{ print NR*2, $4 } & correctly shown 1440 minutes for a full 24 hours (not the 720 I had before)

I think it looks right now?

Graphing downstream attenuation might be a bit tricky as we don't have a single value for VDSL2. It is split over 3 frequency band plans now with profile 17a.

I suppose I could include all 3 into one graph.
The highest frequency band will be really easy to graph for my connection though.
The attenuation at those frequencies is that high it is classad as N/A

Paul.

[attachment deleted by admin]

[burakkucat]

Thanks for spotting my "deliberate" mistake

My pleasure.

I have now done it again using '{ print NR*2, $4 } & correctly shown 1440 minutes for a full 24 hours (not the 720 I had before)

I am pleased to note that you spotted my "deliberate misguidance" which, of course, I inserted to ensure that you pay attention.

I think it looks right now?

It looks very useful evidence, indeed.

Graphing downstream attenuation might be a bit tricky as we don't have a single value for VDSL2. It is split over 3 frequency band plans now with profile 17a.

I suppose I could include all 3 into one graph.
The highest frequency band will be really easy to graph for my connection though.
The attenuation at those frequencies is that high it is classad as N/A

Go on. Just do it. You know you want to do so! 

[Bald_Eagle1]

It looks very useful evidence, indeed.

All forwarded to Plusnet.
There had been a re-sync during the early hours of this morning - result was lower sync & higher SNRM, with errors currently quite low.

The attached graph shows matters following a modem reboot with the some stuff still connected & a subsequent reboot with nothing connected

The drop in SNRM at around 1320 minutes was with everything else disconnected (SSFP removed, so not even the extension to upstairs connected).
I tried a couple of handsets in the master socket's test socket (next to my PC) & made a couple of phone calls.

The drop in SNRM lasted for the exact duration of the phone calls.


Paul.

[attachment deleted by admin]

[Bald_Eagle1]

It looks very useful evidence, indeed.

On the basis of that evidence, along with evidence of a "massive" error count (over 2 Million CRC errors in a 38 hour period), Plusnet agree that an engineer's visit is now required to test my line again.

Just take a look at today's graph (attached).
All the weirdness occured AFTER I had posted the previous evidence to Plusnet.

The net result is that I am a good few Mb down on DS throughput compared to this time yesterday.

Thanks again to the unnamed people who developed the initial stats collecting / graphing scripts & modem unlocking methods.
Without their help I would have absolutely no evidence to work with.

Paul.

[attachment deleted by admin]

[burakkucat]

The attached graph shows matters following a modem reboot with the some stuff still connected & a subsequent reboot with nothing connected

The drop in SNRM at around 1320 minutes was with everything else disconnected (SSFP removed, so not even the extension to upstairs connected).
I tried a couple of handsets in the master socket's test socket (next to my PC) & made a couple of phone calls.

Sorry but you have confused the b*cat.    Your "master socket" is the NTE5/A at the end of the shielded cable. With the SSFP removed, how is the HG612 connected to the line? With an adaptor in the the NTE5/A's test socket? How was a telephone connected? Dingle-dangle microfilter, perhaps? With the lower front panel removed from the SSFP, all telephony wiring is disconnected. You could then plug a telephone into the socket, now exposed, in the lower half of the SSFP. The HG612 would still be connected to the upper, data, socket of the SSFP.

If necessary you could send some photographs of your office wiring, NTE5/A onwards towards the telephone and 'puter, for my consideration at "The Cattery". 

[burakkucat]

On the basis of that evidence, along with evidence of a "massive" error count (over 2 Million CRC errors in a 38 hour period), Plusnet agree that an engineer's visit is now required to test my line again.

If only you could have an OR engineer with either Messrs Ezzer's or Pag's knowledge and ability, this saga might just be drawing to a close.

[Bald_Eagle1]

Sorry but you have confused the b*cat.    Your "master socket" is the NTE5/A at the end of the shielded cable. With the SSFP removed, how is the HG612 connected to the line? With an adaptor in the the NTE5/A's test socket? How was a telephone connected? Dingle-dangle microfilter, perhaps? With the lower front panel removed from the SSFP, all telephony wiring is disconnected. You could then plug a telephone into the socket, now exposed, in the lower half of the SSFP. The HG612 would still be connected to the upper, data, socket of the SSFP.

If necessary you could send some photographs of your office wiring, NTE5/A onwards towards the telephone and 'puter, for my consideration at "The Cattery". 

Hi b*cat,

I'm getting really good at confusing people.

What I really meant was:-

With the lower front panel removed from the SSFP, all telephony wiring was disconnected.
I then pluged a telephone into the socket, now exposed, in the lower half of the SSFP.
The HG612 WAS still connected to the upper, data, socket of the SSFP.

I incorrectly stated the SSFP was removed, when I should have stated the lower front panel was removed from the SSFP.

My bad

No photos necessary.


Paul.

[Bald_Eagle1]

If only you could have an OR engineer with either Messrs Ezzer's or Pag's knowledge and ability, this saga might just be drawing to a close.

I have every confidence that the right sort of engineer will be sent, with the right sort of equipment, the right sort of tests will be carried out, the right sort of repair will be effected, & the right sort of re-tests will be carried out just to make sure ALL faults have been rectified, thus returning my connection to me in A-1 working condition.

& Voila! 40Mb for the Baldy one

Paul.

[burakkucat]

& Voila! 40Mb for the Baldy one

"And the band played 'Believe It If You Like'." 

[.Griff.]

Hi Paul,

We seem to have exactly the same issue. The only difference is mine was cured by switching to 17a and yours was caused by switching to 17a. Weird..

On 8c I accumulated 12 CRC and 4 HEC errors every second of every day or roughly 1 million CRC errors every 24 hours. As soon as I was on 17a instead of 12 CRC errors every second it dropped to 0.02 CRC errors a second.

I've put together a quick screen shot to demonstrate the dramatic reduction in errors below -

[Bald_Eagle1]

Yes, mine is/was  the opposite way around, the deterioration possibly starting with the switch to profile 17a (still not 100% sure though).
Unfortunately, I don't really have any records of error counts from when they were recently exceeding 1 Million per day.

With the aid aid a batch file & graphing script, I have very recently started logging errors / SNRM / Sync.

I have collected the stats at every 2 minutes over a period of a few days & attached graphs from one 24 hour period, with the CRC errors provisionally shown as the average errors per second.

This doesn't really highlight when the errors peaked or by how much.

e.g. At 10:17 this morning, following an earlier automated re-sync, CRC errors were running at 677 over 4965 seconds = an average of 0.136 errors per second.

However, 2 minutes later, CRC errors had shot up to 11430 over 5085 seconds =  an average of 2.247 errors per second.
That doesn't sound too bad, until considering that 10753 errors had occured in only 120 seconds = 89.6 errors per second.

Between 10:43 & 10:45, errors shot up again from 24883 to 57099 somewhere within the 2 minute sample.
That equates to 268.467 errors per second, but only shows as an overall average of 8.592 in the graph.

As these errors probably occured in less than 2 minutes, the burst count is probably very high indeed.

At 20:47, the total CRC errors was 58174 over 42765 seconds = an overall average of only 1.36 errors per second for the whole duration of the VDSL2 connection since the last re-sync.

I think, to prove a point to Tuesday's engineer, the bursts of CRC errors & loosely associated SNRM fluctuations & re-syns etc. would carry more weight.

Any thoughts anyone regarding the best/most typical method of showing errors to aid with fault diagnosis, & is anyone interested in helping to code this for graphing purposes (prior to Tuesday's visit)?

Log snippets:-

13/11/2011 10:17 19904 4999 4.3 6.3 10.9 6.3 21596 5168 G.992.3_Annex_K_PTM) 677 0 16 0 200 0 4965 0.136
13/11/2011 10:19 19904 4999 4.9 6.3 10.8 6.3 22208 5194 G.992.3_Annex_K_PTM) 11430 0 156 0 4351 0 5085 2.247
:
:
:
13/11/2011 10:43 19904 4999 5.2 6.4 10.9 6.3 22432 5209 G.992.3_Annex_K_PTM) 24883 0 278 13 8516 0 6525 3.813
13/11/2011 10:45 19904 4999 7.3 6.6 10.9 6.3 24560 5334 G.992.3_Annex_K_PTM) 57099 0 440 13 14957 0 6645 8.592
:
:
:
13/11/2011 20:45 19904 4999 9.3 6.8 10.8 6.3 26468 5401 G.992.3_Annex_K_PTM) 58174 0 469 42 15184 0 42645 1.364
13/11/2011 20:47 19904 4999 9.1 6.8 10.8 6.3 26224 5389 G.992.3_Annex_K_PTM) 58174 0 469 42 15184 0 42765 1.36


Paul.

Edit:
Can everyone actually see the graph curves?
They are dark blue & dark red, but may display as much paler colours for some.

[attachment deleted by admin]