freebox-connection is broken since 43ce1ecdc838d57619783c9dc598cf3b6cf4feaa

[LudovicRousseau]

The patch in https://github.com/chteuchteu/Freebox-OS-munin/commit/43ce1ecdc838d57619783c9dc598cf3b6cf4feaa is wrong.

The problem is that the config now uses bits_up & bits_down:

graph_category freebox
graph_scale yes
graph_title bits/s up/down
graph_vlabel bits in (-) / out (+) per second
bits_down.type COUNTER
bits_down.label bits/s
bits_down.graph no
bits_up.label bits/s
bits_up.type COUNTER
bits_up.negative bits_down

and the data still uses bytes_up & bytes_down:

bytes_up.value 1358518780
bytes_down.value 8665417156

Have you checked a correct graph is generated?

Also the freebox OS documentation indicates:

bytes_up int Read-only total uploaded bytes since last connection bytes_down int Read-only total downloaded bytes since last connection

If you really want to use bits and not bytes you have to multiply the result by 8.

[quentin-st]

+1, I didn't check. Waiting for @ruliane feedback on this!

[ruliane]

That was a fast patch and, indeed, I didn't check before pushing this PR. It looks like it's more complicated than expected : data reported by Freebox API might be mislabeled as well. For now, I think it's better to rollback this change.

[airvb]

Hello, Can you lake it as an option ? I prefer old version myself !

[ruliane]

A simple workaround is to convert bits into bytes by using cdef :

print('graph_scale yes')
print('graph_title bytes up/down')
print('graph_vlabel bytes in (-) / out (+) per second')
print('bytes_down.type COUNTER')
print('bytes_down.label bytes/s')
print('bytes_down.cdef bytes_down,8,/')
print('bytes_down.graph no')
print('bytes_up.label bytes/s')
print('bytes_up.type COUNTER')
print('bytes_up.negative bytes_down')
print('bytes_up.cdef bytes_up,8,/')

I just tested it successfully :

[LudovicRousseau]

@ruliane why do you think the values returned by bytes_up and bytes_down fields are in bits and not in bytes?

[ruliane]

@ruliane why do you think the values returned by bytes_up and bytes_down fields are in bits and not in bytes?

Consider the following scenario: [NAS] --- [Freebox] --- [Internet]

NAS is downloading a large file through Freebox, at an average speed of ~10 MB/s.

This is confirmed by Freebox management interface.

But here is the result of freebox-connection:

Munin reports a average download speed of 628 MB/s, which is obviously wrong. This speed would be actually far beyond my Freebox capabilities. It appears that this speed is not in bytes/s. So, what "628 M" could be? I tried some calculation, here what I found. 628 M might be in the following units:

• 628 Mbytes/sec: as seen previously, 628 MB/S is obviously wrong
• 628 Mbits/sec: which is 78.5 Mb/s
• 628 Mbytes/minute: which is 10.5 MB/s
• 628 Mbytes/5minutes (due to Munin polling rate): which is 2.09 MB/s
• 628 Mbits/minutes: 1.31 MB/s

The only believable case is 10.5 MB/s. Considering this, the value reported by munin-connection is likely in bytes/minute.

[LudovicRousseau]

Very nice experiment @ruliane

On my side I did something similar. I downloaded many times the same big file to saturate the 1 Gb/s fibre connection. On the freebox I get around 100 MBytes/s

On Munin with freebox-connection (without your change) I get around 90M-100M or 10^8 (100 000 000) for the logarithmic scale The unit must be bytes/s.

On munin with freebox-traffic I get between 80M and 90M: Again the unit is bytes/s.

On munin with freebox-switch1 I get around 90M and 100M or 10^8: Again the unit is bytes/s.

I have no idea why you get ~600M. Maybe your freebox OS is bogus.

Note that what the script freebox-connection returns is NOT a speed but a number (of bytes here) since the freebox booted. The type of data is COUNTER for munin. The speed is computed by munin itself by using the difference of two measures divided by the time (5 minutes).

@chteuchteu please revert the commit 43ce1ecdc838d57619783c9dc598cf3b6cf4feaa I am pretty sure the unit is NOT bytes/minute (minute really?) as demonstrated by @ruliane.

[ruliane]

I have no idea why you get ~600M. Maybe your freebox OS is bogus.

I will revert to the original freebox-connection plugin and check again.

@chteuchteu please revert the commit 43ce1ec

Agreed.

I am pretty sure the unit is NOT bytes/minute (minute really?) as demonstrated by @ruliane.

That indeed sounds strange.

[quentin-st]

Thanks all for your investigations! I just reverted the commit This issue can be closed, right?

[ruliane]

Right.