Print

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

[GigabitEthernet]

Our REIN fault is resolved according to Plusnet and the SNRM certainly does seem to be dropping less at night. It drops maybe 2dB at the most now, which is the least it has ever dropped and it's winter too!

[Ronski]

With regard to total FEC errors the counter resets around 4294656929, as the next total in my log is 196094, that explains why the maths didn't work out before. With the total showing 196094, my FEC delta is 506461, so 506461 - 196094 = 310367. So 4294656929 +  310367 = 4294967296 as the maximum possible amount before resetting to zero. Which is 100000000000000000000000000000000 in binary, so actually it should be 4294967295, which is 11111111111111111111111111111111 is binary, so total FEC is stored as a 32 bit value.

Regarding SNRM ours was 9db for a long time, until the new firmware appeared.

[NewtronStar]

With regard to total FEC errors the counter resets around 4294656929, as the next total in my log is 196094, that explains why the maths didn't work out before. With the total showing 196094,

yes my fec totals seem to have been reset, but the uptime is still going on, so it not a great way to compare your total vs modem uptime 

[Ronski]

Unfortunately it does make it difficult to know the total, but do you really need to?

BE1 could alter his software to take it into account, BUT if the software wasn't on continuously then it could lose track for various reasons. Shame they don't use a 64 bit number, that would go up to 9223372036854775807 

[roseway]

Several of the values reported by the router are stored as 32-bit integers, and they all wrap round when they hit the limit of just over 4 billion. As Ronski says, you have to monitor continuously if you want to maintain an accurate count of the totals. In truth, these aren't very useful figures (apart from their curiosity value) - what's far more interesting is the per-minute rate and how it varies over time.

[NewtronStar]

Unfortunately it does make it difficult to know the total, but do you really need to?

Yes I really need total error counters to be accurate with the Modem uptime to see how my line compares from previous to current that is the fundamental of what stats meens and yes I know that my FEC errors are very large but if am having it others must also be seeing it to.

[Bald_Eagle1]

As Ronski says, you have to monitor continuously if you want to maintain an accurate count of the totals. In truth, these aren't very useful figures (apart from their curiosity value) - what's far more interesting is the per-minute rate and how it varies over time.

I have just posted more or less the same message here:-

http://forum.kitz.co.uk/index.php?topic=13078.msg250178#msg250178


I can see how my connection changes over very long periods of time, but it is being monitored 24/7 (see the attached 320 days of ongoing stats to see how it has deteriorated over time).

[Bald_Eagle1]

BE1 could alter his software to take it into account, BUT if the software wasn't on continuously then it could lose track for various reasons. Shame they don't use a 64 bit number, that would go up to 9223372036854775807 

Just to confirm, BE1 isn't about to alter his software as it does appear to provide a reasonable 'picture' of a connection's performance over time as it is 

[NewtronStar]

I see what your saying about the Stats software running continuously (PC on 24/7) but when the HG612 had it own GUI those error counts were held inside the Modem so you never had to leave BE1 stats program on 24/7 to show the errors accumulating

[Bald_Eagle1]

I see what your saying about the Stats software running continuously (PC on 24/7) but when the HG612 had it own GUI those error counts were held inside the Modem

Yes, but the ones it displayed were WRONG (FEC/CRC).

You can get the GUI back if you choose to use Wolfy's firmware (basically using BT's recent updates, but adding the GUI back in).

[NewtronStar]

I see what your saying about the Stats software running continuously (PC on 24/7) but when the HG612 had it own GUI those error counts were held inside the Modem

Yes, but the ones it displayed were WRONG (FEC/CRC).

You can get the GUI back if you choose to use Wolfy's firmware (basically using BT's recent updates, but adding the GUI back in).

Cheers BE1
I am not ready for Wolfys firmware as yet, what I am trying to understand here is your total error counts don't come from the Modem itself only from your software is that right.

[Bald_Eagle1]

All the data comes from the modem.
My software then calculates the differences each minute.

e.g:-

sample 1 - RSCorr = 100
sample 2 - RSCorr = 150

Difference = 50

The graph reports 50 for that minute.



sample 3 - RSCorr = 175

Difference = (175 - 150) = 25

The graph reports 25 for that minute.



The connection then resyncs, so RSCorr = 0

sample 4 - RSCorr = 40

Difference = (40 - 0) = 40

The graph reports 40 for that minute.


& so on & so on.............................




Even if the modem's data isn't reset at a resync, the difference between the samples is calculated & reported in the graphs.

So, let's say RSCorr wasn't reset to zero, sample 4 would have been 215.

Difference = (215 - 175) = 40

The graph would still report 40 for that minute.






A special case is when the maximum value the modem can store is reached.
The value is then reset to zero.

Whatever data is stored by the next minute's sample is recorded & if there is only 1 minute difference between samples, whatever is recorded is reported in the graph.


However, if the data hadn't been harvested for a while, the first new sample could be a huge value & a great big spike incorrectly reported in the graph.

So, whenever there are 2 minutes or more between samples (e.g. the software/PC has been switched off), the data at the next sample is ignored to avoid the misleading spike, although the data is still recorded in modem_stats.log, ready to calculate the difference when the next minute's sample data is obtained.


So, between samples when the software isn't running, the difference could be say 100,000,000.
Reporting that as a minute by minute difference would be clearly wrong, so the very first sample after re-starting the software is ignored.
But the next sample is say 100,000,040

The one minute difference would then be only 40, which would be correct so it is reported in the graph.




The only graphs that don't work like that are DS & US OHF.
They aren't actually error counts as such, so whenever a few samples are missed, for whatever reason, the graphs intentionally report a spike, which acts as a visual 'flag' to indicate that there had been a pause or delay in sampling.


I have attached an example of the DS OHF graph from when my virus scanner slowed the PC down at 04:00 that much that a sample or two were missed or were delayed.
Thus spikes are seen

I have also attached the DS CRC graph from the same period. Spikes are not seen at 04:00.

The spikes that are shown in the DS CRC graph from earlier on are actually genuine CRC error spikes.

 

 

[NewtronStar]

All the data comes from the modem.
My software then calculates the differences each minute.

Have been using your software for years without questioning it's results, your explanation and the workings behind your software and the modem is remarkable.

Maybe one day in the future I'll be able to leave the PC on for 51 weeks @ 24/7 it's just not viable at the moment  so it looks like the software does not work to well for an energy saving EU like me.

[Ronski]

Have been using your software for years without questioning it's results, your explanation and the workings behind your software and the modem is remarkable.

I concur with BE1, there really is very little point in altering the logging software, we have to work with what the modem gives us. I've been using his software for well over a year, testing things and developing the GUI, but I still don't understand what the majority of the information means 

Maybe one day in the future I'll be able to leave the PC on for 51 weeks @ 24/7 it's just not viable at the moment  so it looks like the software does not work to well for an energy saving EU like me.

I'm also an energy saving EU, my wife and daughters will tell you how much I nag about lights and things left on. Last thing I do before bed is to make sure everything is turned off/standby - the media PCs have a habit of staying on even when they are set to go to sleep after X minutes.

My logging is done on my server which is on 24/7 for various reasons, but it only draws 40 - 50w, so probably costs around £60 a year to run. I certainly wouldn't leave my desktop system on 24/7.

[ryant704]

I actually had a cool idea the other day, though I have no idea if it's possible.

Most routers are supplied with a USB (For firmware, software updates, etc?)... here comes the question.

You create a bootable of your or roseways program upon putting the USB into HomeHub it will then boot the program and gather the line stats from this location using the HH's power. It will save all files onto the USB, when you want to look at the line stats you take the USB out and plug it in your computer and bobs your uncle all your information is saved.

Though as I said I have no idea if this is possible, I'm assuming it's not.