Print

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

[roseway]

I'll certainly give that some consideration, but plausibility is a rather difficult thing to assess.

[burakkucat]

I figured out that the reported traffic values from /proc/net/dev sometimes are unreliable. Most time they count up correctly but suddenly the download counter jumps backwards.

Could that 'backwards jump' of the counter be nothing more than 'wrap around'? 

[broadstairs]

Eric having tested the 0.0.38 interface for a few days it seems to track the internet traffic just fine. This morning I swapped to the ppp256 for a few minutes and it was recording traffic down like it was going out of fashion! See the attached snapshots of the ppp256 data over just 2 or 3 minutes. So at least on my HG622 0.0.38 seems best.

ppp256    Link encap:Point-to-Point Protocol
          inet addr:92.20.126.188  P-t-P:92.20.112.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:905517 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1196470013 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:82239046 (78.4 MiB)  TX bytes:2737753863 (2.5 GiB)

ppp256    Link encap:Point-to-Point Protocol
          inet addr:92.20.126.188  P-t-P:92.20.112.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:905562 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1196513942 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:82242151 (78.4 MiB)  TX bytes:2790484690 (2.5 GiB)

ppp256    Link encap:Point-to-Point Protocol
          inet addr:92.20.126.188  P-t-P:92.20.112.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:905616 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1196621399 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:82246124 (78.4 MiB)  TX bytes:2840064533 (2.6 GiB)         

I am wondering if this interface also sees local lan traffic although it still would not explain that sort of increase when I was not doing anything much.

Stuart

[ColinS]

Eric,

Help!  I'm thoroughly confused (which I admit is not entirely unusual  )

Here's an extract of the Telnet data from DSL stats this morning, which:
Latest 15 minutes time = 6 min 0 sec
FEC:      3084      0
CRC:      0      0
ES:      0      0
SES:      0      0
UAS:      0      0
LOS:      0      0
LOF:      0      0
Previous 15 minutes time = 15 min 0 sec
FEC:      3903      16
CRC:      0      2
ES:      0      2
SES:      0      0
UAS:      0      0
LOS:      0      0
LOF:      0      0
Latest 1 day time = 22 hours 21 min 0 sec
FEC:      568832      186
CRC:      33      69
ES:      5      65
SES:      0      0
UAS:      0      0
LOS:      0      0
LOF:      0      0
and here's the corresponding error rate averages
      Per second   Per minute   Per hour     Per day

CRC   Up   3.22      193      11578      277876   
   Down   5.27      316      18957      454959   

FEC   Up   9.67      580      34808      835389   
   Down   36885      2213112      132786728      3186881536   

HEC   Up   0      0      0      0   
   Down   0      0      0      0   

ES   Up   0      0.07      4.07      97.8   
   Down   0      0      0      0   

Huh? 

Apologise in advance if somebody else has already reported something similar, but I haven't yet had time to read the thread.

Cheers, Colin

[roseway]

Eric having tested the 0.0.38 interface for a few days it seems to track the internet traffic just fine. This morning I swapped to the ppp256 for a few minutes and it was recording traffic down like it was going out of fashion! See the attached snapshots of the ppp256 data over just 2 or 3 minutes. So at least on my HG622 0.0.38 seems best.

I am wondering if this interface also sees local lan traffic although it still would not explain that sort of increase when I was not doing anything much.

Thanks Stuart, that seems fairly conclusive. As I think I mentioned, the ppp256 interface proved not to be the correct interface on my HG612 either, but in this case it reported lower values, not higher. I wish I understood the logic (if there is any).

[roseway]

Help!  I'm thoroughly confused (which I admit is not entirely unusual  )

... etc

Colin, I think confusion is in order, because the averages still aren't right, for which I apologise. I haven't had time to devote to this area recently, but I do intend to come back to it soon.

[ColinS]

No probs, I'm easily confused. 

[krypton]

Could that 'backwards jump' of the counter be nothing more than 'wrap around'? 

No, it happens everywhere. Example:

Inter-|Receive                                               
 face |bytes    packets
br2:1250743591 64922654
br2:1251123637 64922919
br2:1251470543 64923159
br2:1251866993 64923433
br2:1252201041 64923666
br2:1242565754 64927566
br2:1247958179 64927822
br2:1247958229 64928075
br2:1247958329 64928349
br2:1259460400 64928581
br2:1259856976 64928858

(sample every 15 seconds)

I'll certainly give that some consideration, but plausibility is a rather difficult thing to assess.

I thought to compare the current up/down values with those from the previous sample to check if they got smaller. imho this should never happen (except after 2³²-1 bytes). Maybe I am not the only one with this issue so I thought this function could warn others before they get false traffic data. But probably this is more difficult to solve than it seems for me. If this gets too complicated don't waste your time with this

[roseway]

If this gets too complicated don't waste your time with this

It's not a waste of time. There's no point in doing this unless I try to get it right. In your example, the byte counter seems to have lost about 10 million bytes with the red item, yet the packet counter continued to increment. It's difficult to believe that it's anything other than a router firmware bug.

What I'll try to do is keep a record of the last 10 samples (say) and analyse them to see if they show an illogical pattern. If so, I'll endeavour to repair the error and give a warning about the possibility that the reported data is inaccurate.

[roseway]

Could that 'backwards jump' of the counter be nothing more than 'wrap around'? 

No, it happens everywhere. Example:

Inter-|Receive                                               
 face |bytes    packets
br2:1250743591 64922654
br2:1251123637 64922919
br2:1251470543 64923159
br2:1251866993 64923433
br2:1252201041 64923666
br2:1242565754 64927566
br2:1247958179 64927822
br2:1247958229 64928075
br2:1247958329 64928349
br2:1259460400 64928581
br2:1259856976 64928858

(sample every 15 seconds)

I'll certainly give that some consideration, but plausibility is a rather difficult thing to assess.

I thought to compare the current up/down values with those from the previous sample to check if they got smaller. imho this should never happen (except after 2³²-1 bytes). Maybe I am not the only one with this issue so I thought this function could warn others before they get false traffic data. But probably this is more difficult to solve than it seems for me. If this gets too complicated don't waste your time with this

I think I've established a workable solution without getting too complicated. I've done two things:

1. I've slightly changed the way in which the program deals with the situation when one of the counters returns a lower value that the previous one. I did assume that it was a wraparound or a re-boot or whatever, causing the counter to start from zero again, so I just added the new value to the total. This accounts for the large values reported in your situation. Now I add nothing to the total, so a small amount of traffic data may be lost, but it won't report silly values.

2. I do a simple plausibility check (comparing the new counter value with the previous value to see if it looks like a wraparound) and if it appears to be non-sequential, as in your example, then I add an entry in the event log to say so.

I've also adopted the same approach with CRC, FEC and HEC errors, because the same problems could exist with these, but I don't make entries in the event log for these items.

[krypton]

Thank you.

I saw another problem: After wraparound the program keeps crashing with an integer error, as long as the download counter is below something around 10'000'000 bytes. If the counter rises above, it doesn't crash anymore.

[roseway]

I saw another problem: After wraparound the program keeps crashing with an integer error, as long as the download counter is below something around 10'000'000 bytes. If the counter rises above, it doesn't crash anymore.

I'll see if I can trace that.

[roseway]

Help!  I'm thoroughly confused (which I admit is not entirely unusual  )

... etc.

Colin, I have hopes that the latest modifications (as described in my reply to Morphium, above) will deal with this issue.

[roseway]

I have the graph set to display 4hrs per page, so I lost practically the full 4hrs when he pulled the plug.  Is there a way to do a quick manual save of all graphs (like the take snapshot button) , or is the auto save totally linked in with the display time per page.

The next version will have a button on the toolbar to manually save all the active graphs.

[kitz]

>>> The next version will have a button on the toolbar to manually save all the active graphs.

Thank you Eric - appreciated... same thing happened again whilst the engineer was here on Sat and DSLstats crashed when he pulled the telephone cable out from the modem.

I note that DSLstats automatically grabs screen shots based on the 'Time per page' setting which appears to control the current view and the captures.   
I like to have the view set at 4hrs as that gives a good overall trend without having to scroll back, and covers a good period of time for when Im not at the PC.   But it would be nice to auto grab at say 2 hours.

I fully understand that in most monitoring only situations then it makes total sense for the 2 figures to be the same and if I didnt currently have a line fault I would be entirely happy with the current set up.