<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.21299" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN class=169534413-29062011>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=169534413-29062011>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=169534413-29062011></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=169534413-29062011>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).</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=169534413-29062011></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=169534413-29062011>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=169534413-29062011></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=169534413-29062011>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?</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=169534413-29062011></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=169534413-29062011><STRONG>and to be 
more clear this is the last core of the 64 bit 
server:</STRONG></SPAN></FONT></DIV><FONT><SPAN class=169534413-29062011>
<DIV><BR><FONT face=Arial size=2>processor       : 
7<BR>vendor_id       : GenuineIntel<BR>cpu 
family      : 
6<BR>model           : 
15<BR>model name      : Intel(R) Xeon(R) 
CPU           E5310  @ 
1.60GHz<BR>stepping        : 11<BR>cpu 
MHz         : 1600.058<BR>cache 
size      : 4096 KB<BR>physical 
id     : 
1<BR>siblings        : 4<BR>core 
id         : 3<BR>cpu 
cores       : 
4<BR>apicid          : 
7<BR>fpu             
: yes<BR>fpu_exception   : yes<BR>cpuid level     

10<BR>wp              
: yes<BR>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<BR>bogomips        : 
3177.52<BR>clflush size    : 64<BR>cache_alignment : 
64<BR>address sizes   : 38 bits physical, 48 bits virtual<BR>power 
management:<BR></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><SPAN class=169534413-29062011><FONT face=Arial size=2><STRONG>and this is 
the last core of the 32 bit server:</STRONG></FONT></SPAN></DIV>
<DIV><SPAN class=169534413-29062011><FONT face=Arial 
size=2><BR>processor       : 
3<BR>vendor_id       : GenuineIntel<BR>cpu 
family      : 
6<BR>model           : 
15<BR>model name      : Intel(R) Xeon(R) 
CPU            5140  
@ 2.33GHz<BR>stepping        : 11<BR>cpu 
MHz         : 2333.389<BR>cache 
size      : 4096 KB<BR>physical 
id     : 
3<BR>siblings        : 2<BR>core 
id         : 7<BR>cpu 
cores       : 
2<BR>fdiv_bug        : 
no<BR>hlt_bug         : 
no<BR>f00f_bug        : 
no<BR>coma_bug        : 
no<BR>fpu             
: yes<BR>fpu_exception   : yes<BR>cpuid level     

10<BR>wp              
: yes<BR>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<BR>bogomips        : 
4666.97<BR></FONT></SPAN></DIV></SPAN></FONT>
<DIV><FONT face=Arial size=2><SPAN 
class=169534413-29062011></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=169534413-29062011>Regards.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=169534413-29062011>Issam 
Harrathi</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><PRE>Issam Harrathi wrote:

><I> on server1(64 bit) i have 2 Intel E5310 quad-core 1.6Ghz and on server2(32
</I>><I> bit) i have 2 Intel Xeon dual-core 2.33Ghz.
</I>><I> means 8*1.6 Ghz on server1 and 4*2.33 on server2.
</I>><I> 8*1.6 is better and faster than 4*2.33, no?
</I>
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</PRE></DIV><PRE>********************************************************************************
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.
********************************************************************************
</PRE></BODY></HTML>