Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #7269

Re: OpenSSL speed benchmark discrepancy

Show all headers | View raw

[lack of line wrap corrected where feasible]

On 2013-02-08, Wojciech Pietruszewski <w.pietruszewski@gmail.com> wrote:
> Hi,
>
> I'm comparing several x64 virtualization platforms and I've
> noticed some major differences in the results.
>
> For simple cpu test I used OpenSSL library and md5 algorithm. 
>
> For example on ESXi the summary is as follow:
> md5              43962.70k   134233.75k   310670.64k   460008.45k   537597.27k
> but on the host:
> md5              19932.33k    60678.78k   139943.51k   209213.78k   242518.70k
> it is noticeably slower.
>
> I run it a couple of times, each time it showed similar
> results, almost half of what ESXi shows, the same as on KVM or
> Xen.
>
> I then focused on server, itself. When I run two or more
> openssl speed md5 test in background, prior to main test, I was
> able to get results similar to those from ESXi.
> md5              46037.71k   137434.13k   316198.06k   463614.29k   541970.66k
>
> The server is based on i5 750 processor and Linux 2.6.32
> kernel. I've been trying to investigate cpu scaling on 2.6.32 but
> with no luck, according to /proc/cpuinfo the frequency is
> constant, no additional cpu-management software installed, all
> bios cpu enhancements disabled.
>
> Any ideas what may influence such behaviour, is it hardware related or kernel?
>
> Best regards,
> w.

From this posting, it's not entirely clear to me what the numbers
represent.  Are they bytes at different points in time?  Is the
time measurement in units of CPU time or wall-clock time?

So, you're seeing it run more slowly on bare metal physical
machine than in a VM on that same physical machine?

One possibility for such a situation could be if the VM presents
a different CPU type to the kernel than the bare metal.  It is
possible the software can take advantage (or maybe disadvantage)
of some instruction set extensions, based on the processor type
the kernel sees.  If the software makes a bad decision on bare
metal, that could explain the observation.

Another possibility is that the VM gives you two layers of disk
caching and buffering, and that can sometimes benefit a VM more
than it does bare metal.  When a userspace process writes a bunch
of data to disk, the kernel buffers it for a while before
actually sending it to the physical disks.  (There are kernel
parameters that control time and memory size/percentage limits
for the buffering.)  The buffering can let the userspace process
run faster than it would if it had to wait for disk writes to
complete.  In a VM, you have _BOTH_ the userspace process inside
the VM buffering into VM kernel memory _AND_ the virtualizer
process on the host machine buffering into its memory.  There's
also a less likely possibility that caching of the read traffic
might have an effect that _MIGHT_ help the VM more than bare
metal.

HTH

(Wojciech, I guess maybe it's a small world.  Is there somebody
with my name in the US group you work with?)

-- 
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

Back to comp.os.linux.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

OpenSSL speed benchmark discrepancy Wojciech Pietruszewski <w.pietruszewski@gmail.com> - 2013-02-08 15:18 -0800
  Re: OpenSSL speed benchmark discrepancy Robert Riches <spamtrap42@jacob21819.net> - 2013-02-09 05:31 +0000
    Re: OpenSSL speed benchmark discrepancy Wojciech Pietruszewski <w.pietruszewski@gmail.com> - 2013-02-09 03:04 -0800

csiph-web