This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

CPU/Network Utilization

I want to provide some feedback for the Sophos UTM 9.1 home version.
I have it running on the following hardware:

GIGABYTE - Motherboard - Socket 1155 - GA-Z77-D3H (rev. 1.0)

CPU:  Intel Core i7 (8 Core may be overkill, but performance is incredible)
32 GB RAM
VMWare ESXi 5.1
120 GB SSD

It actually performs better in a VM environment than running it on hardware (I believe I know why….may not be what Sophos tested it with), so that’s why I sent my hardware information.
After measuring performance on 8 cores, I reduced the system to 2 cores and 1 GHz of power.  It performed nearly the same, but now I get less bottlenecks from the application.  I then added the third core (3 cores) and do not see a difference from the performance of 8 cores.  I allocated 16 GB of RAM and noticed that it does not use 16, but 11.8 GB.  I’m going to reduce the RAM use to 13 GB.

So I forgot to explain why I added the third core.  I am also using the Link Aggregation Group (I haven’t checked to measure NIC performance yet) and I have 3 Broadcom NIC’s as Uplinks to the Cable Modem.  I also turned down the power of the CPU to 800 MHz (after learning that my Netgear R6300 is a dual-core router and was shocked a bit).  The router runs at 800 MHz, so I deduced that if the UTM is running at 3.7 GHz with 8 cores, network performance may be impacted (no real data to show).  What would occur is the Uplinks would show an error and I have to reset the Cable Modem, release the IP’s, renew the IP’s, restart the UTM several times before all is well, so ‘something’ was actually going on at the Data Link layer for some strange reason.  The R6300 would not have any impact, but the Cable Modem (Motorola SBG6580 SURFboard) would reset.

I plan to run some media streaming tests across 3 different computers today and measure that data.


This thread was automatically locked due to age.
Parents
  • Morning,

    I have a couple observations from my own experiences that may help explain why your i7 performs better in a 2 vCPU VM then baremetal.

    First is CPU Frequency. Ivybridge i7's support both Turbo Boost and SpeedStep, which dynamically adjust core frequency in response to demand. On bare metal a quad core is never going to get heavily loaded so SpeedStep (supported in the OS) may never ramp up the CPU from the minimum frequency. In something like ESXi, which AFAIK does not support any form of dynamic CPU frequency change, each vCPU gets the full rated core speed when it asks for it.

    Second is scheduling within ESXi. Not sure how many other vm you have on your machine but CPU contention with the other VM's may be part of it.

    VMware has done extensive testing of multi-core VM's under ESXi and their conclusion is that except in some very rare (read specialized & controlled) circumstances, allocating more then 2 vCPU's to a guest can actually reduce the performance of the guest. The reason behind this is in how ESXi schedules CPU time slots. When CPU slots are being scheduled, the hypervisor looks for chunks of time where the host has the same number of physical cpu's available as the guest has vCPU's. They do this so the cores are sync'd which makes scheduling far easier and more transparent.

    The analogy I use for explaining their scheduling is a restaurant. In a busy restaurant it's easier for one person or a couple to walk into a busy restaurant and get a seat at a table then it is for a party of four or six. This is because (assuming there are no large party booths, just two seat tables) you have to free up several tables to make room for a larger party whereas you only need to free up one for that couple. In short you can run more couples through in an hour then you can the larger parties.
Reply
  • Morning,

    I have a couple observations from my own experiences that may help explain why your i7 performs better in a 2 vCPU VM then baremetal.

    First is CPU Frequency. Ivybridge i7's support both Turbo Boost and SpeedStep, which dynamically adjust core frequency in response to demand. On bare metal a quad core is never going to get heavily loaded so SpeedStep (supported in the OS) may never ramp up the CPU from the minimum frequency. In something like ESXi, which AFAIK does not support any form of dynamic CPU frequency change, each vCPU gets the full rated core speed when it asks for it.

    Second is scheduling within ESXi. Not sure how many other vm you have on your machine but CPU contention with the other VM's may be part of it.

    VMware has done extensive testing of multi-core VM's under ESXi and their conclusion is that except in some very rare (read specialized & controlled) circumstances, allocating more then 2 vCPU's to a guest can actually reduce the performance of the guest. The reason behind this is in how ESXi schedules CPU time slots. When CPU slots are being scheduled, the hypervisor looks for chunks of time where the host has the same number of physical cpu's available as the guest has vCPU's. They do this so the cores are sync'd which makes scheduling far easier and more transparent.

    The analogy I use for explaining their scheduling is a restaurant. In a busy restaurant it's easier for one person or a couple to walk into a busy restaurant and get a seat at a table then it is for a party of four or six. This is because (assuming there are no large party booths, just two seat tables) you have to free up several tables to make room for a larger party whereas you only need to free up one for that couple. In short you can run more couples through in an hour then you can the larger parties.
Children
No Data