In reply to a post by eddie1150:

so how can i improve it?

Just like ADSL - with correct filters, decently made joints, no ring wire etc. Take care with routing telecom cables near mains cables. Beg the neighbour to stop transmitting their radio-ham or CB sets.

Your only way to measure the effect you are having is to watch the FEC and CRC error rates.

If you reduce your CRC rate, then DLM will notice (it might take 2, 3 or 4 weeks to change though).

In reply to a post by WWWombat:

...

Wow, that's some post.

I wonder if Bald_Eagle1 can incorporate this into his HG612 stats

perhaps you could add it to your blog, before it gets lost amongst all the other posts, although I have saved a link to it.

In reply to a post by BatBoy:

Wow, that's some post.

I wonder if Bald_Eagle1 can incorporate this into his HG612 stats

How do you mean?

I think he's taking the mickey out of the poster.

I'm hoping it wasn't really supposed to be a reply to me, just a lazy last-post reply.

I've also been out and not had time to look for some stuff that shows how wrong he is about error stats on FTTC, which could well be what BatBoy is on about. I can't be bothered tonight.

Thanks guys.
Not much i can do then!
THe line from the drop wire to the bt box was changed when BT came, so guess there isnt much that can be done, unless his joint wasnt up to much?
But not really mcuh way i can change that eh!?

In reply to a post by Bald_Eagle1:

In reply to a post by BatBoy:

Wow, that's some post.

I wonder if Bald_Eagle1 can incorporate this into his HG612 stats

How do you mean?

I mean can the graphs show whats stated in the post in order to aid troubleshooting?

In reply to a post by BatBoy:

I mean can the graphs show whats stated in the post in order to aid troubleshooting?

In a new version that I am still working on, I don't graph any ongoing data from the GUI any longer as the errors are reported incorrectly.
Instead, I just graph data from xdslcmd info --stats

The harvesting is also now done via a compiled .EXE program that is more efficient, reliable & quicker.

Quite a bit of what WWWombat has mentioned is graphed, particularly OHFErr (CRC), RSCorr (FEC), HEC error counts along with Error Seconds, attenuation per band, power levels etc............

Here's an example from my own connection:-
Ongoing Stats from 25th November

You will see that some graphs are duplicated. That's just to demonstrate that certain error types have two names. e.g RSCorr & FEC errors are the same thing & increase at the same rate.

One of them retains cumulative values following a resync & the other doesn't.
That doesn't really matter for graphing though, as the graphs just show the difference from one minute to the next.


I hope to release this new version some time after Christmas (once I have sussed out how to easily implement the use of a configuraion/ini file for easy setting up of bespoke folder/drive locations & so on).

I might also add a few more graphs for some of the other stats too - when I get round to it.


EDIT:

I believe ADSL connections use the term SuperFrame (reported as SF via Broadcom routers such as Netgear DG834GT & the HG612 itself when used in ADSL mode) whereas VDSL2 uses the term OverHeadFrame (OHF)

Edited by deleted (Sun 25-Nov-12 21:53:38)

I finally found a copy of the VDSL2 specification, so I understand the parameters better now - and also realised I made a small mistake, so don't graph it directly

However, I think there *might* be something worth graphing that is a little better than the "D" (interleaving depth) parameter.

In reply to a post by Bald_Eagle1:

EDIT:

I believe ADSL connections use the term SuperFrame (reported as SF via Broadcom routers such as Netgear DG834GT & the HG612 itself when used in ADSL mode) whereas VDSL2 uses the term OverHeadFrame (OHF)

Yes, I think this is correct.

In the VDSL2 spec, the data transferred is split into two components - the user-data and the OH (OverHead data). The CRC code is captured and sent as part of the OH data... and as far as I can work out, there is one CRC per OH frame.

In ADSL, there is one CRC code per SF.

I think the two frames are constructed in rather different ways, but the fact seems to be that one "error" count in ADSL implies the CRC went wrong for one superframe. In VDSL2, the one error would mean a CRC mismatch in one OH frame.