SOLVED - CPU Utilization gui seems faulty

[SnakeByte]

I was doing some throughput tests on the processor of my RT-AC68U, and was surprised by the results of the GUI's CPU usage graph during the test:

'top -d1' from the cli however, shows the process fully taking up one of the cores and staying that way -- no ups and downs as that graph suggests. Oddly, the other core seems to spike in the opposite direction even though nothing else spikes in the top output.

How reliable is this CPU status GUI? Is this some type of artifact of the ARMv7 processor? Is some kind of passing of the process from core to core happening? If so, why? Heat?

This was the command I was running:
dd if=/dev/zero bs=1M of=/dev/null

I was curious to see what kind of bandwidth the processor/bus/memory was able to handle. (Turns out it's approx 174MiB/s, or 1476.4 Megabits/s .. slower than the advertised:

• The world's fastest Wi-Fi router, with combined dual-band data rates of
  1900 Mbps for three times faster performance than 802.11n routers

Also interestingly, if I ran two of those commands simultaneously, it would max out both cores, however, the total bandwidth halved for each which suggests that the bottleneck is with the memory/bus.

 

[SnakeByte]

Okay, I think I've answered my own question... When I issued this command to force the process to stick to a single core:
taskset -c 0 dd if=/dev/zero bs=1M of=/dev/null

The utilization looked like it should have:

Apparently the OS was doing some type of core to core swapping with my original command -- not sure why. Either way, this test shows that the graph is accurate.

 

[ozzed]

Okay, I think I've answered my own question... When I issued this command to force the process to stick to a single core:
taskset -c 0 dd if=/dev/zero bs=1M of=/dev/null

The utilization looked like it should have:
View attachment 5526

Apparently the OS was doing some type of core to core swapping with my original command -- not sure why. Either way, this test shows that the graph is accurate.

Regarding the throughput results I think the advertised speed is for the PHY wireless interface, and those speeds are much different from actual throughput due to massive overhead on the protocol.