# amd64 wegen Verschlüsslung ?

## Hyp

Hallo,

Ich habe mir einen neuen Prozessor (und Motherboard) zugelegt und zwar den Intel Core 2 Duo E6600 (und der ist 64bit fähig).  Ohne eine riesige Diskussion über die Vor- und Nachteile von amd64 gegenüber i686 anfangen zu wollen, stelle ich mir die Frage ob es einen (merkbaren?) Geschwindigkeitsvorteil bei der Ver- bzw. Entschlüsslung gibt. Ich möchte nämlich gerne wieder meine home-Partition verschlüsseln und dieser (evtl.?) Geschwindigkeitsvorteil wäre der einzige Grund für mich, doch ein amd64-System einmal zu versuchen und auch riskieren, dass einige Packages "nicht ohne Weiteres" laufen.

Gibt es hierzu Meinungen, Erfahrungen oder sogar Benchmarks ?

Gruß,

Hyp

----------

## Anarcho

Ja, den gibt es. Im Kernel existiert eine 64Bit Assembler Implementierung von AES die ca. 20% schneller als die i586 Version ist. Das habe ich selber getestet.

----------

## schachti

 *Hyp wrote:*   

> 
> 
> Ich habe mir einen neuen Prozessor (und Motherboard) zugelegt und zwar den Intel Core 2 Duo E6600 (und der ist 64bit fähig).  Ohne eine riesige Diskussion über die Vor- und Nachteile von amd64 gegenüber i686 anfangen zu wollen, stelle ich mir die Frage ob es einen (merkbaren?) Geschwindigkeitsvorteil bei der Ver- bzw. Entschlüsslung gibt.
> 
> 

 

Mal abgesehen davon, ob es einen Geschwindigkeitsvorteil gibt, ist der Prozessor so leistungsfähig, daß Du keinen Unterschied merken wirst (bei meinem alten Athlon XP 1800+ war zum Beispiel nicht der Prozessor, sondern die Festplatte der Flaschenhals - die Platte hat max. 35 MB/s geschafft, und das hat den Prozessor nicht ausgelastet). Jeder Kern des E6600 dürfte mindestens 2-3 Mal so schnell wie mein alter Athlon XP 1800+ sein, so daß selbst ein RAID0 aus 2 modernen Festplatten Deinen Prozessor bei der Verschlüsselung nicht ausreizen dürfte.

----------

## Anarcho

 *schachti wrote:*   

>  *Hyp wrote:*   
> 
> Ich habe mir einen neuen Prozessor (und Motherboard) zugelegt und zwar den Intel Core 2 Duo E6600 (und der ist 64bit fähig).  Ohne eine riesige Diskussion über die Vor- und Nachteile von amd64 gegenüber i686 anfangen zu wollen, stelle ich mir die Frage ob es einen (merkbaren?) Geschwindigkeitsvorteil bei der Ver- bzw. Entschlüsslung gibt.
> 
>  
> ...

 

Womit hast du denn dann die Festplatte veschlüsselt? Mit ROT13? Also mein Athlon 2000+ schafft mit AES256 ca. 14 MB/s was meine Festplattenn nicht gerade auslastet. Und selbst meine CPU nicht völlig ausgelastet wäre, dann wäre ich doch trotzdem um eine 20%ige Entlastung dankbar wenn ich dadurch statt 50% nur noch 40% CPU Auslastung habe und somit 10% mehr Leistung für andere Sachen habe bzw. Strom spare.

----------

## schachti

 *Anarcho wrote:*   

> 
> 
> Womit hast du denn dann die Festplatte veschlüsselt? Mit ROT13?
> 
> 

 

Mit AES; im Kernel war

# CONFIG_CRYPTO_AES is not set

CONFIG_CRYPTO_AES_586=y

gewählt. Getestet habe ich wie folgt: Ca. 100 GB von einer verschlüsselten Partition auf eine andere verschlüsselte Partition kopiert. Der Durchsatz lag dabei irgendwo um die 17 MB/s - wohlgemerkt mit zwei AES-Durchläufen, nämlich Ent- und Verschlüsselung.

----------

## Hyp

 *Anarcho wrote:*   

> Ja, den gibt es. Im Kernel existiert eine 64Bit Assembler Implementierung von AES die ca. 20% schneller als die i586 Version ist. Das habe ich selber getestet.

 

Ok, 20 % sind schon etwas.

Gruß,

Hyp

----------

## manuels

Aber Moment: Wir reden hier doch über den Kernel. Wenn der "64-Bit ist" kannst du trotzdem ein x86er Gentoo aufsetzen und hast diesen Verschlüsselungsperformancegewinn trotzdem.

----------

## Anarcho

 *manuels wrote:*   

> Aber Moment: Wir reden hier doch über den Kernel. Wenn der "64-Bit ist" kannst du trotzdem ein x86er Gentoo aufsetzen und hast diesen Verschlüsselungsperformancegewinn trotzdem.

 

Ja, das ist richtig.

@schachti:

Ich habe nochmal nachgemessen, ich komme auf 14 MB/s von Platte zu Platte, also insgesamt 28 MB/s. Auch nachvollzogen mit hdparm.

Allerdings schaffen moderne Platten deutlich mehr als 35 MB/s und dazu noch oben genannte Gründe und ich würde in solchen Fällen immer die schöne 64 Bit Variante nehmen.

----------

## Hyp

 *manuels wrote:*   

> Aber Moment: Wir reden hier doch über den Kernel. Wenn der "64-Bit ist" kannst du trotzdem ein x86er Gentoo aufsetzen und hast diesen Verschlüsselungsperformancegewinn trotzdem.

 

Hm, das verstehe ich jetzt nicht. Wann ist ein Kernel "64bit" ? Klärt mich als Laien auf..  :Smile: 

----------

## Mr_Maniac

Nur um einige Bedenken gegen amd64 zu zerstreuen:

Ich habe seit einer Woche auch einen "neuen PC" (viel neues Innenleben) mit einem Core2Duo E6320 und habe mir ein amd64-gentoo installiert.

Wie bei meinem alten PC habe ich stage 1 genommen (alter PC hat mehrere Tage zum Kompilieren aller Pakete gebraucht und er Core2Duo nur etwa 10 Stunden   :Shocked:  ).

Meine neue Gentoo-Installation ist inzwischen auf dem gleichen Stand wie meine alte Gentoo-Installation und es gibt nur wenige Sachen, die nicht, oder zumindest nicht nativ laufen:

netscape-flash (aber mit dem nspluginwrapper läuft es ohne Probleme), sun-java oder eher gesagt das nsplugin davon (gibt wohl leider noch kein 64Bit Plug-in) und z.Zt. noch epsxe (die Plug-Ins werden mit 64bit kompiliert aber epsxe ist 32bit. Immerhin kann ich den epsxe starten. Nur viel weiter komme ich eben nicht  :Wink:  ) sowie doomsday (lässt sich problemlos kompilieren, aber beim Ausführen gibt es einen Segfault).

Ansonsten läuft - wie gesagt - alles einwandfrei  :Smile: 

----------

## Hyp

Ich werde es auf einen Versuch ankommen lassen ..  :Smile:  Welche Sourcen verwendest du ?

btw. habe dasselbe Board wie du  :Wink:  Kannst du mir deine make.conf und Kernel-config einmal schicken bzw. posten ? Danke.

----------

## manuels

 *Hyp wrote:*   

> Hm, das verstehe ich jetzt nicht. Wann ist ein Kernel "64bit" ? Klärt mich als Laien auf.. 

 

Da musst du zwischen Userspace und Kernelspace unterscheiden.

Wenn du in der Kernelkonfiguration als "Zielsystem" den AMD Athlon64 auswählst, hast du einen 64-Bit Kernel.

Zusätzlich kannst du dann noch die Unterstützung der Ausführung von 32-Bit-Programmen hinzufügen.

Dann kannst du ein CHOST=x86-Gentoo (also 32-Bit-Userspace) mit einem 64-Bit-Kernelspace laufen lassen - kein Problem.

Der Kernel unterstützt dann den kompletten 64-Bit-Befehlssatz, deine Programme, die im Userspace laufen, aber nicht.

----------

## Hyp

Ok, gut zu wissen (das tat ich nicht!).  Wenn du mir jetzt noch sagen könntest, wo ich das "Zielsystem" einstellen kann, dann wäre ich glücklich  :Smile:  (Unter "Processor type and features  ---> Processor family" habe ich nichts gefunden; allerdings mit suspend2-sources)

----------

## mv

 *Hyp wrote:*   

> Wenn du mir jetzt noch sagen könntest, wo ich das "Zielsystem" einstellen kann, dann wäre ich glücklich 

 

So einfach ist das leider nicht. Die Option, einen 64-Bit-Kernel zu kompilieren, hast Du nur, wenn Du ihn auf einem 64-Bit-System kompilierst. Also zumindest eine Toolchain brauchst Du in 64-Bit...

(Theoretisch gibt es sicher noch eine Alternative mit Cross-Compilierung, aber die ist wohl so kompliziert, dass es einfacher sein dürfte, ein 64-Bit-System aufzusetzen.)

----------

## Mr_Maniac

 *Hyp wrote:*   

> Ich werde es auf einen Versuch ankommen lassen ..  Welche Sourcen verwendest du ?

 

Die gentoo-sources. Wie in meiner Signatur schon steht: Was gerade stable im Portage ist  :Wink: 

 *Quote:*   

> btw. habe dasselbe Board wie du  Kannst du mir deine make.conf und Kernel-config einmal schicken bzw. posten ? Danke.

 

Gerne doch. Die USE-Flags musst du natürlich nach deinen Vorlieben setzen und in die kernel-config solltest du auch noch mal rein schauen (z.B. Soundkarte auswählen. Nutze die On-Board-Karte nicht):

http://home.arcor.de/mr_maniac/ANDERES/amd64configs.tar.bz2

Wer will kann ja auch mal in die Kernel-Config reinschauen und eventuell Tipps geben, was man besser machen könnte  :Wink: 

Bin ja noch 64-Bit Neuling  :Wink: 

----------

## Hyp

 *mv wrote:*   

> So einfach ist das leider nicht. Die Option, einen 64-Bit-Kernel zu kompilieren, hast Du nur, wenn Du ihn auf einem 64-Bit-System kompilierst. Also zumindest eine Toolchain brauchst Du in 64-Bit...

 

Hm, was heißt das nun konkret ?  :Wink:  Was muss ich tun ?

@Mr_Maniac: Danke vielmals !

----------

## manuels

installier am besten ein ganz normales 64-Bit-Gentoo und gut ist.  :Very Happy: 

----------

## ConiKost

 *Hyp wrote:*   

>  *mv wrote:*   So einfach ist das leider nicht. Die Option, einen 64-Bit-Kernel zu kompilieren, hast Du nur, wenn Du ihn auf einem 64-Bit-System kompilierst. Also zumindest eine Toolchain brauchst Du in 64-Bit... 
> 
> Hm, was heißt das nun konkret ?  Was muss ich tun ?
> 
> @Mr_Maniac: Danke vielmals !

 

Wenn du ein i686 chost hast, komplett gentoo neuinstallieren mit x86_64 chost;)

----------

## Hyp

Ich dachte, ich könnte einen 64bit Kernel nutzen ohne das ganze System auf 64bit umzustellen. Das war es doch was manuels oben geschrieben hat,  oder ? Bin verwirrt ...

----------

## Anarcho

 *Hyp wrote:*   

> Ich dachte, ich könnte einen 64bit Kernel nutzen ohne das ganze System auf 64bit umzustellen. Das war es doch was manuels oben geschrieben hat,  oder ? Bin verwirrt ...

 

Das kannst du machen, aber dann musst du den Kernel auf einem anderen System kompilieren. Vielleicht geht es aber auch mit make Paramtern wie BUILD= CHOST= TARGET=.

Aber ich bin mit meinem 64 Bit System bis auf wenige Ausnahmen sehr zufrieden.

Der Mischbetrieb dürfte bei Grafiktreibern wie nVIdia oder fglrx allerdings Handarbeit erfordern.

----------

## Hyp

 *Anarcho wrote:*   

> Das kannst du machen, aber dann musst du den Kernel auf einem anderen System kompilieren. Vielleicht geht es aber auch mit make Paramtern wie BUILD= CHOST= TARGET=.

 

Ok, jetzt verstehe ich.. 

Aber das scheint mir zu kompliziert .. deshalb werde ich wohl ein "reines" System installieren.

----------

## Mr_Maniac

 *Anarcho wrote:*   

> Das kannst du machen, aber dann musst du den Kernel auf einem anderen System kompilieren. Vielleicht geht es aber auch mit make Paramtern wie BUILD= CHOST= TARGET=.

 

Hmm... Sollte es nicht reichen, eine amd64 Live-CD zu booten?

Oder dann ein mini-chroot einzurichten, in das man nur ein stage entpackt mit dem man dann den kernel kompiliert?

 *Quote:*   

> Aber ich bin mit meinem 64 Bit System bis auf wenige Ausnahmen sehr zufrieden.

 

Bei mir macht eigentlich nur epsxe und die doomsday Engine probleme. Beides nicht wichtig  :Wink: 

Mit etwas rumprobieren könnte ich evtl. zumindest epsxe zum Laufen bringen (wie kann ich portage sagen, dass es die Plug-Ins NICHT als elf64 linken soll?)

 *Quote:*   

> Der Mischbetrieb dürfte bei Grafiktreibern wie nVIdia oder fglrx allerdings Handarbeit erfordern.

 

Hmm... 64bit Kernel-Modul aber der Rest 32 bit... Geht das überhaupt?

Ich würde auch empfehlen, dem reinen 64 bit System eine Chance zu geben. Versuch es einfach. Ich hatte wirklich bis auf die zwei Spiele die ich genannt habe KEINE Probleme...

Ich habe die Configs meines alten athlon-thunderbird-gentoos genommen und angepasst und habe jetzt nahezu 1:1 das System von "damals" halt nur in 64 bit  :Wink: 

Sogar mein xmms im overlay läuft ohne Probleme auf 64 bit  :Wink: 

----------

## Anarcho

 *Mr_Maniac wrote:*   

>  *Anarcho wrote:*   Das kannst du machen, aber dann musst du den Kernel auf einem anderen System kompilieren. Vielleicht geht es aber auch mit make Paramtern wie BUILD= CHOST= TARGET=. 
> 
> Hmm... Sollte es nicht reichen, eine amd64 Live-CD zu booten?
> 
> Oder dann ein mini-chroot einzurichten, in das man nur ein stage entpackt mit dem man dann den kernel kompiliert?

 

So etwas in der Art meinte ich.

 *Mr_Maniac wrote:*   

>  *Quote:*   Aber ich bin mit meinem 64 Bit System bis auf wenige Ausnahmen sehr zufrieden. 
> 
> Bei mir macht eigentlich nur epsxe und die doomsday Engine probleme. Beides nicht wichtig 
> 
> Mit etwas rumprobieren könnte ich evtl. zumindest epsxe zum Laufen bringen (wie kann ich portage sagen, dass es die Plug-Ins NICHT als elf64 linken soll?)

 

Versuch mal CFLAGS="-m32" emerge blah

 *Mr_Maniac wrote:*   

>  *Quote:*   Der Mischbetrieb dürfte bei Grafiktreibern wie nVIdia oder fglrx allerdings Handarbeit erfordern. 
> 
> Hmm... 64bit Kernel-Modul aber der Rest 32 bit... Geht das überhaupt?

 

Ich denke ja, da die 32 Bit Xorg-Treiber ja über eine Kernel Schnittstelle mit dem Treiber kommunizieren. Aber sicher bin ich mir da nicht. Zumindest bei PPC scheint der Mischbetrieb ja zu gehen (keine Ahnung mit welchen Treibern).

 *Mr_Maniac wrote:*   

> Ich würde auch empfehlen, dem reinen 64 bit System eine Chance zu geben. Versuch es einfach. Ich hatte wirklich bis auf die zwei Spiele die ich genannt habe KEINE Probleme...
> 
> Ich habe die Configs meines alten athlon-thunderbird-gentoos genommen und angepasst und habe jetzt nahezu 1:1 das System von "damals" halt nur in 64 bit 
> 
> Sogar mein xmms im overlay läuft ohne Probleme auf 64 bit 

 

Ich würde es auch als AMD64 System laufen lassen. Für die paar anderen Programme gibt es dann ja die emul-linux-x86-* Pakete.

----------

## Hyp

Danke für eure Meinungen.

Okay. Wie bereits erwähnt, werde ich es auf einen Versuch ankommen lassen. Wenn etwas nicht funktionieren sollte, dann kann ich mich ja wieder hier melden  :Wink: 

----------

## papahuhn

 *Anarcho wrote:*   

> 
> 
> Aber ich bin mit meinem 64 Bit System bis auf wenige Ausnahmen sehr zufrieden.
> 
> 

 

Sind das reine 64bit oder mit multilib?

----------

## Anarcho

 *papahuhn wrote:*   

>  *Anarcho wrote:*   
> 
> Aber ich bin mit meinem 64 Bit System bis auf wenige Ausnahmen sehr zufrieden.
> 
>  
> ...

 

Ich fahre ein multilib System.

----------

## Mr_Maniac

 *Anarcho wrote:*   

> Versuch mal CFLAGS="-m32" emerge blah

 

Da ich ja schon vor dem Umstieg fleißig in den Wikis und Foren geschaut habe, habe ich das bereits probiert  :Wink: 

Ich habe sogar verschiedene Varianten durchprobiert. Bis hin zu CHOST="i386" CFLAGS="-march=i386 -m32" LDFLAGS="-m32" emerge blah...

Jedoch sagt epsxe mir immer folgendes, wenn ich die Plug-Ins einstellen will:

```
plugins/libspuPeopsALSA.so.1.0.9: wrong ELF class: ELFCLASS64
```

Ich werde epsxe und die plug-ins wohl mal manuell runterladen und installieren müssen... Mal sehen, ob das besser klappt.

Ach ja: Ich fahre übrigens auch multilib  :Wink: 

----------

## Hyp

So, ich bin jetzt endlich mal dazugekommen meine Installation durchzuführen.

MrManiac: Könntest du mal ein 

```
genlop -t sys-devel/gcc
```

 ausführen? Ich erhalte als Ausgabe 

```
 * sys-devel/gcc

     Fri Jun  1 17:41:44 2007 >>> sys-devel/gcc-4.1.2

       merge time: 49 minutes and 25 seconds.
```

 was mir ein wenig schwach vorkommt. Besonders, wenn ich es mit 

```
sys-devel/gcc-4.1.1-r1

merge time: 24 minutes and 16 seconds
```

 von http://www.unixboard.de/vb3/showthread.php?t=24016 vergleiche.

Was mir auch noch in der Ausgabe von /proc/cpuinfo aufgefallen ist

```
model name      : Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz

stepping        : 6

cpu MHz         : 2306.314

```

Ist das normal, dass da ca. 100MHz fehlen oder ist das nur der Unterschied beim Umrechnen von Giga->Mega ?

----------

## AmonAmarth

 *Hyp wrote:*   

> [/url] vergleiche.
> 
> Was mir auch noch in der Ausgabe von /proc/cpuinfo aufgefallen ist
> 
> ```
> ...

 

diesen "umrechnungsfehler" hast du nur bei der umrechnung von byte und kb/mb/gb usw. weil die nächst höhere einheit ein vielfaches von 2^10 sein muss

----------

## Hyp

 *Quote:*   

> diesen "umrechnungsfehler" hast du nur bei der umrechnung von byte und kb/mb/gb usw. weil die nächst höhere einheit ein vielfaches von 2^10 sein muss

 

Ähm, ja, da hätte ich wohl selbst auch draufkommen können...

Was kann dann in meinem Fall schiefgegangen sein ?

----------

## Hyp

Hm, hat keiner eine Anmerkung zu meinem Beitrag von Fr Jun 01, 2007 6:55 pm ?

----------

## ChrisJumper

 *Hyp wrote:*   

> So, ich bin jetzt endlich mal dazugekommen meine Installation durchzuführen.
> 
> MrManiac: Könntest du mal ein 
> 
> ```
> ...

 

Hi Hyp!

Also ich denk nicht das du das so vergleichen solltest. Eure System sind zu unterschiedlich als das du nun erwarten könntest dieselbe Zeit zu erreichen. Er postet in dem Thread auch nicht ob er diesen Genlop-Test mit einem 32 oder 64 Bit System gemacht hat. Dazu kommt noch die Frage ob er ccache benutzt oder Teile von seinem Ram als Tmp-Verzeichnis verwendete. Damit lässt sich das Compilieren z.B. beschleunigen.

Dann gibt es noch unterschiedliche Faktoren wie z.B. der Arbeitsspeicher:

```
# CPU: Intel E6600 (Conroe)

# Speicher: 2048MB DDR800 CL4 von G.Skill
```

Mfg Chris

----------

## think4urs11

Naja ich habe den Wert mal mit meinem T5500/1.66GHz-Laptop verglichen und ich komme (32Bit/1GB/kein ccache/tmp on ram o.ä. voodoo) auf 38:02 min, da sind 49 Minuten für ein nominell deutlich schnelleres System mit einem 2.4GHz-Proz. schon sehr schwächlich.

udma ist aktiv?

throttle wg. Überhitzung kann ausgeschlossen werden?

----------

## Hyp

Hi,

Ja, ich denke auch nicht, dass ich diese Werte erreichen kann. Aber so deutlich darunter, das hätte ich nicht erwartet. Ich habe auf einer zweiten Festplatte noch eine 32bit Version installiert und erhalte dort 39 min, also ca. 10 Minuten weniger (was ich auch seltsam finde). 

Ja, udma5 ist aktiviert und überhitzt sollte die CPU bei 39°C auch nicht sein.

Die Lesegeschwindigkeit der Festplatte ist für eine IDE auch ok 

```
hdparm -T -t /dev/hda

/dev/hda:

 Timing cached reads:   3506 MB in  2.00 seconds = 1753.78 MB/sec

 Timing buffered disk reads:  228 MB in  3.03 seconds =  75.35 MB/sec
```

----------

## Mr_Maniac

So... Hier sind dann mal auch meine Werte für gcc. Seltsamer Weise war der erste Kompilierungs-Vorgang schneller als der darauf folgende. Und das trotz ccache?!?

```
 * sys-devel/gcc

     Thu May 17 16:01:09 2007 >>> sys-devel/gcc-4.1.2

       merge time: 32 minutes and 40 seconds.

     Thu May 17 18:06:21 2007 >>> sys-devel/gcc-4.1.2

       merge time: 42 minutes and 34 seconds.
```

----------

## Hyp

Danke für die Werte.

Ich habe wieder einen kleinen Fortschritt erreicht.

Ich habe im Bios den (einfachen) FSB fix auf 266 MHz eingestellt (anstelle des Automatik-Modus') und jetzt erhalte ich 

```
cpu MHz         : 2395.015
```

Eigentlich sollten die 266 MHz auch im Automatik-Modus eingestellt sein, aber das ist wohl ein Bios-Fehler, dass er das nicht macht.

Jetzt lasse ich den Kompiliervorgang nochmals laufen und dann mal schauen, was sich ergibt.

----------

## ChrisJumper

Ok hier kommen meine Werte, wenn dir das vllt. weiterhilft:

Besonders interessant finde ich die beiden verschiedenen Werte.  Beim ersten hatte ich ccache noch nicht aktiviert...

```
 # genlop -t sys-devel/gcc

 * sys-devel/gcc

     Mon Jun  4 01:51:06 2007 >>> sys-devel/gcc-4.1.2

       merge time: 38 minutes and 6 seconds.

     Mon Jun  4 06:22:31 2007 >>> sys-devel/gcc-4.1.2

       merge time: 32 minutes and 12 seconds.

```

```
processor       : 1

vendor_id       : GenuineIntel

cpu family      : 6

model           : 15

model name      : Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz

stepping        : 6

cpu MHz         : 2400.002

cache size      : 4096 KB
```

----------

## Hyp

Danke für eure Beiträge. 

Ich habe mich jetzt doch gegen 64bit entschieden. 

Grund:  

```
     Tue Jun  5 16:22:42 2007 >>> sys-devel/gcc-4.1.2

       merge time: 30 minutes and 27 seconds.

```

----------

## Child_of_Sun_24

@Hyp

Du musst bei dem 64 Bit gcc mitberechnen das er zusätzlich zum 64 Bit compiler einen kompletten 32 Bit compiler fürs cross compiling erstellt, beim 32 Bit system erstellt er nur einen 32 Bit Compiler, beides gegenüberstellen kannst du also eigentlich nicht und das er auf dem 64 Bit System länger braucht liegt halt genau daran.

CoS24

----------

