The last time I had to dig around high cpu load conditions I learned that F5s split the core usage by relegating the tmm 'worker' processes to the even numbered cores while the odd cores were held in reserve for their even numbered partner, ie. Core0 active paired with Core1.
If any of the even core hit 80% they would grab almost all of the odd numbered core's resources and assign them to the tmm instance running on the even member. At least that is what was observed and my understanding after digging around the KB articles about core handling.
With this in mind, are you seeing the same results repeated over repeated tests? What is the per core load when running the tests? Have you checked to see which TMM worker is handling the majority of the traffic while the tests are being carried out?
My bet is that the lower core instance is potentially balancing the load across the various cores a little more evenly under the load conditions whereas the higher core number instance is loading the cores a little more before splitting off the load.
Based on this I would suggest running tests with higher TPS volumes to see how the behavior changes.
Also, bear in mind that the TMM system is essentially a virtual environment so when checking core load stats and the connection distribution do so via tmsh because the OS commands such as top are not able to see how the TMM environment is being used.
Altostratus
