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

Groups > comp.os.linux.misc > #7263 > unrolled thread

OpenSSL speed benchmark discrepancy

Back to article view | Back to comp.os.linux.misc

Contents

  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

#7263 — OpenSSL speed benchmark discrepancy

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.

[toc] | [next] | [standalone]

#7269

[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.)

[toc] | [prev] | [next] | [standalone]

#7271

> 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?
> 
Well these numbers are raw openssl speed results.
"The 'numbers' are in 1000s of bytes per second processed"
> 
> So, you're seeing it run more slowly on bare metal physical
> 
> machine than in a VM on that same physical machine?
> 
Correct.
> 
> One possibility for such a situation could be if the VM presents
> 
> a different CPU type to the kernel than the bare metal.  
Every running VM presents replica of the host's cpu model.
> 
> 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.
> 
I'm running HW assisted virtualization, most if not all platforms allow executing guest code directly, without or very little VMM control, unless I'm missing something at this point.
> 
> 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.
That's right. Simple test's like hdparm or more advanced bonnie show's 
that many VMs offer better I/O performance due to it's buffering on VMM level.
> 
> (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.
> 
Well, as for ESXi, it uses BT in some cases and a structure allow to
cache translated code in special structure called TLB. But I don't 
see how this could give performance advantage over raw execution 
of the code.
> 
> HTH
> 
> 
> 
> (Wojciech, I guess maybe it's a small world.  Is there somebody
> 
> with my name in the US group you work with?)
> 
No, I don't think so Robert :)

Best regards,
w.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.misc

csiph-web