better performance with 32 bit ! why?

[iharrathi.ext at orange-ftgroup.com]

As asked, i will made a test with os 32 bit on the same server as the the 64 bit, and will post this result here.
Thanks for all for your answers.
Regards.
Issam Harrathi.

________________________________
De : HARRATHI Issam Ext OLNC/DPS
Envoyé : mercredi 29 juin 2011 16:17
À : 'sven at whgl.uni-frankfurt.de'; 'Ryan Novosielski'; 'eivind at aminor.no'; 'dufberg at telia.net'; 'lst_hoe02 at kwsoft.de'
Cc : 'bind-users at lists.isc.org'
Objet : Re: better performance with 32 bit ! why?

When i start Bind on server2 i do it with -n 4 ( to use 4 thread) and on server1 i start bind with -n 8. And i see then on munin that the load is shared on all cores.
For the load-server it's another server let's call it server 3. I know that tcpreplay is monothread so i lunch 2*25000 qps for example. And i use also resperf for testing, what i have with resperf and tcpreplay is nearly the same.

What's important is that i 'm using always the same server3 to load the server1 and server2 (not at the same time, and using the same pcap-- rewrite twice to meet the mac@ of server1 and server2-- ) and i start with -n 4 on the 4 cores server and with -n 8 on the 8 cores. But i found best performance on the 32 bit server2 (4*2.33).

Other information i begin the test only after sending for a few minutes 20000 qps, so then i have only 5% of request that causes recursion, and about 15% nxdoamin answer, finally 80% of answer from cache. This is available for the 2 server since it's the same original pcap written twice.

Do i have to use bind compiled and running on 32 bit server to have better performance rather than bind compiled and running on 64 bit server?

and to be more clear this is the last core of the 64 bit server:

processor       : 7
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU           E5310  @ 1.60GHz
stepping        : 11
cpu MHz         : 1600.058
cache size      : 4096 KB
physical id     : 1
siblings        : 4
core id         : 3
cpu cores       : 4
apicid          : 7
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm constant_tsc pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm
bogomips        : 3177.52
clflush size    : 64
cache_alignment : 64
address sizes   : 38 bits physical, 48 bits virtual
power management:

and this is the last core of the 32 bit server:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU            5140  @ 2.33GHz
stepping        : 11
cpu MHz         : 2333.389
cache size      : 4096 KB
physical id     : 3
siblings        : 2
core id         : 7
cpu cores       : 2
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor ds_cpl est tm2 xtpr
bogomips        : 4666.97

Regards.
Issam Harrathi




Issam Harrathi wrote:

> on server1(64 bit) i have 2 Intel E5310 quad-core 1.6Ghz and on server2(32
> bit) i have 2 Intel Xeon dual-core 2.33Ghz.
> means 8*1.6 Ghz on server1 and 4*2.33 on server2.
> 8*1.6 is better and faster than 4*2.33, no?

You can only do maths like that if you assume that everything is
multithreaded _and_ capable of spreading to multiple cores without any
overhead.

I've mentioned earlier that for example BIND only scales up to about 4
threads. Based on this, your maths example would be (kind of simplified):

64 bit vs 32 bit:
4*1.6GHz vs 4*2.33GHz

Also, you mentioned using tcpreplay, which is also apparantly
single-threaded , making the comparison like this:

1*1.6GHz vs 1*2.33GHz.

Regards
Eivind Olsen

********************************************************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
********************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110629/232e4892/attachment.html>