BUG REPORT: Average is incorrect in Traffic monitor for the first 10 minutes

[JoeSchmoe007]

This is observed on RT-N66U running Merlin's 3.0.0.4.374.35_4 SDK 6 firmware with wired streaming client. I don't know if it present in Asus firmware as well.

Summary:

If you start streaming a large video or downloading large file (should take at least 10 minutes) and then switch to "Traffic Manager"/"Traffic Monitor"/"Internet" page the Average value is incorrect for the first 10 minutes. That is it starts too small and linearly raises as time goes by reaching correct value by the end of 10th minute even though it should settle to correct value within a minute or two.

Detailed description:

Start start streaming a large video (preferrably with higher bandwidth usage, like Vudu HDX or Netflix HD) or downloading large file from provider with more or less constant download speed, like Microsoft (should take at least 10 minutes). Switch to "Traffic Manager"/"Traffic Monitor"/"Internet" page.

The reason I mentioned 10 minutes is that it takes 10 minutes for graph page to scroll all the way horizontally. It is split by 4 vertical thin grey lines. The rightmost is reached in about 2 minutes, the next to the left - in 4 minutes, etc.

By the time it reaches first line the Average will show X KB/s. However, Current by this time will fluctuate around 5X KB/s (or you can check your browser download speed - I only tested streaming but am fairly positive browser download will average 5X at this time).

By the time it reaches second line the Average will show 2X KB/s.

By the time it reaches left edge of the screen the Average will show 5X KB/s and only at this point will be about equal to Current, even though it should've settled equal to the Current very soon (under a minute or two) after you switched to this page.

After reaching the left edge of the graph grid the Average will stay around 5X.

Possible reason for this incorrect behavior:

I think what happens is that Average is ALWAYS calculated as Total bandwidth (in KB) divided by 600 seconds (10 min). This, however, is incorrect. Until the graph reached left edge the time used should be the time elapsed since user switched to this page. So when graph reached rightmost vertical line the time used should be 120 sec (2 minutes), 240 sec for the second line, etc.

PS - I just tested it on file download more and it is easier seen than on streaming because download speed barely fluctuates (downloaded Android ADT from Google, ~600MB)

 

[icece]

Thank you for sharing. This specific page have other issues too. But this have no impact to routers functionality.

 

[JoeSchmoe007]

Thank you for sharing. This specific page have other issues too. But this have no impact to routers functionality.

I disagree. Yes, it doesn't affect routing but it should be fixed.

 

[JoeSchmoe007]

RMerlin: is that difficult to fix?

Thanks.

 

[RMerlin]

RMerlin: is that difficult to fix?

Thanks.

I don't know, I haven't checked yet. Other things are currently more important, and this project is currently a one-man show.

 

[JoeSchmoe007]

I don't know, I haven't checked yet. Other things are currently more important, and this project is currently a one-man show.

Thank you for responding. Didn't mean to rush you or anything. Just wanted it to be put on the list or passed to be put on Asus list.

 

[nimzoking]

I think what happens is that Average is ALWAYS calculated as Total bandwidth (in KB) divided by 600 seconds (10 min).

Yes, would concur this is what is happening, certainly in the "real-time" mode.

This, however, is incorrect. Until the graph reached left edge the time used should be the time elapsed since user switched to this page. So when graph reached rightmost vertical line the time used should be 120 sec (2 minutes), 240 sec for the second line, etc.

Yes, and no. I can understand where you are coming from. However, if the graph is to represent the activity of the last 10 minutes, then the average is correct - as it starts with 10 minutes of zero activity. It depends on your viewpoint of what you are expecting this graph to represent.

So personally, IMHO, I do not think this is a bug. Unless I am misunderstanding your observed behavior?

 

[JoeSchmoe007]

Yes, would concur this is what is happening, certainly in the "real-time" mode.



Yes, and no. I can understand where you are coming from. However, if the graph is to represent the activity of the last 10 minutes, then the average is correct - as it starts with 10 minutes of zero activity. It depends on your viewpoint of what you are expecting this graph to represent.

So personally, IMHO, I do not think this is a bug. Unless I am misunderstanding your observed behavior?

You correctly understand my observed behavior. I just disagree with this statement about "it starts with 10 minutes of zero activity". I see how one can try to use it to justify observed behavior but it just doesn't make sense to me.

 

[ikoul]

I agree with you JoeSchmoe. While the page might be working as designed with that ten minute value hardcoded, from a usability point of view it makes no sense to include time when there could not have been traffic because the router wasn't on.

The fix could be as simple as adding a check like "if router uptime < 10 minutes then average over the uptime instead". It really depends on what the existing code looks like.

 

[JoeSchmoe007]

I agree with you JoeSchmoe. While the page might be working as designed with that ten minute value hardcoded, from a usability point of view it makes no sense to include time when there could not have been traffic because the router wasn't on.

The fix could be as simple as adding a check like "if router uptime < 10 minutes then average over the uptime instead". It really depends on what the existing code looks like.

"if router uptime < 10 minutes then average over the uptime instead" is incorrect fix.

Correct fix is:

if time "Traffic Monitor" page has been open < 10 minutes

average over the time "Traffic Monitor" page has been open​

else

average over 10 minutes​

 

[ikoul]

That's what I get for making assumptions without actually ever having used the traffic monitor. I figured it would show the average over the time range even if you didn't have it open at the time (though keeping ten minutes of bandwidth data at any given time wouldn't necessarily be a good idea, so I dunno why I assumed that), and the "first ten minutes" was the first ten minutes of the router being on. You're right.

 

[RMerlin]

It's not about time or uptime, it's about how many samples have been collected. The bug lies in the average calculation always being based on the maximum number of samples (300) rather than keeping track of how many samples have been collected so far.

The bug probably also exists in Tomato, since I saw the same issue in its code.

I suspect this is something that the Tomato devs originally started to work on (I see them setting a counter to 0 when they initialize the array), but they never finished since nowhere are they incrementing that counter, or referring to it.

In any case, fixed with this commit.

 

[JoeSchmoe007]

It's not about time or uptime, it's about how many samples have been collected. The bug lies in the average calculation always being based on the maximum number of samples (300) rather than keeping track of how many samples have been collected so far.

The bug probably also exists in Tomato, since I saw the same issue in its code.

I suspect this is something that the Tomato devs originally started to work on (I see them setting a counter to 0 when they initialize the array), but they never finished since nowhere are they incrementing that counter, or referring to it.

In any case, fixed with this commit.

Thank you for fixing it.