Maintenant que OpenBSD supporte le MP, j'ai quelques questions quant à
son efficacité : j'ai une machine qui passe son temps à faire de
l'IPsec. OpenBSD n'est pas très efficace dans ce boulot (niveau
performance). Il gère sans problème plusieurs dizaines de tunnels,
mais dès que je fais passer 20 MBits dans l'un d'eux, ça prend tout le
proc d'un Celeron IV 2.4 GHz.
Est-ce que si je colle un Bi Opteron (ou Bi EM64T), est-ce qu'il sera
capable de chiffrer deux fois le débit que serait capable de chiffrer
la version monoproc (pour de l'IPsec) ? Est-ce que Open sait gérer
l'HT dans le cas des EM64T ?
Sinon, dans un sujet proche, la machine actuelle a une carte de crypto
Hifn qui est supportée par Open. Si le nombre de tunnels IPsec atteint
les 60, le chiffrement s'arrête (rien dans dmesg, ni dans les logs) au
bout d'une journée. Aucun problème si la carte est désactivée. Est-ce
un problème connu ?
--
panic("CPU too expensive - making holiday in the ANDES!");
2.2.16 /usr/src/linux/arch/mips/kernel/traps.c
Bonjour, Je ne connais pas les réponses à tes questions mais
mais dès que je fais passer 20 MBits dans l'un d'eux, ça prend tout le proc d'un Celeron IV 2.4 GHz.
est surprenant, vu que http://www.openbsd.org/crypto.html parle de 64Mbit/s en 3DES/SHA1 ESP sur un p3 500Mhz pour les plus vieilles hifn...
Sur une machine équivalente à tienne (mais sans hifn), openssl speed me dit: hmac(md5) 14794.66k 49548.27k 141013.70k 255310.94k 336169.12k blowfish cbc 63785.61k 68899.74k 67888.09k 71882.01k 79549.04k aes-128 cbc 42120.44k 41422.45k 41729.62k 41939.64k 41975.72k
Tu devrait donc avoir de la marge. Tu utilise des algo symétriques très gourmands avec de grosses clefs ? Si je ne m'abuse les hifn accelerent 3des uniqument non ? (chez moi 3des est 3 fois plus lent que blowfish sur la cpu0, selon openssl speed). Je me demande si ces cartes sont très interessantes sur une cpu rapide ...
cpu0: Intel(R) Pentium(R) 4 CPU 2.80GHz ("GenuineIntel" 686-class) 2.81 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT, PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID (btw c'est un p4 avec HT, mais pas supporté parceque le bios est UP).
Est-ce que si je colle un Bi Opteron (ou Bi EM64T), est-ce qu'il sera capable de chiffrer deux fois le débit que serait capable de chiffrer la version monoproc (pour de l'IPsec) ? Est-ce que Open sait gérer l'HT dans le cas des EM64T ?
Surement moins cher et peut-être plus performant, jetter un oeil au AES 128 sur un via c3 ? ça à l'air de cartonner ! http://marc.theaimsgroup.com/?l=openbsd-misc&m7577297024182&w=2 http://archives.neohapsis.com/archives/openbsd/2004-05/0430.html
Bonjour,
Je ne connais pas les réponses à tes questions mais
mais dès que je fais passer 20 MBits dans l'un d'eux, ça prend tout le
proc d'un Celeron IV 2.4 GHz.
est surprenant, vu que http://www.openbsd.org/crypto.html parle de
64Mbit/s en 3DES/SHA1 ESP sur un p3 500Mhz pour les plus vieilles hifn...
Sur une machine équivalente à tienne (mais sans hifn), openssl speed me dit:
hmac(md5) 14794.66k 49548.27k 141013.70k 255310.94k 336169.12k
blowfish cbc 63785.61k 68899.74k 67888.09k 71882.01k 79549.04k
aes-128 cbc 42120.44k 41422.45k 41729.62k 41939.64k 41975.72k
Tu devrait donc avoir de la marge. Tu utilise des algo symétriques très
gourmands avec de grosses clefs ?
Si je ne m'abuse les hifn accelerent 3des uniqument non ? (chez moi 3des
est 3 fois plus lent que blowfish sur la cpu0, selon openssl speed). Je me
demande si ces cartes sont très interessantes sur une cpu rapide ...
cpu0: Intel(R) Pentium(R) 4 CPU 2.80GHz ("GenuineIntel" 686-class) 2.81 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,
PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID
(btw c'est un p4 avec HT, mais pas supporté parceque le bios est UP).
Est-ce que si je colle un Bi Opteron (ou Bi EM64T), est-ce qu'il sera
capable de chiffrer deux fois le débit que serait capable de chiffrer
la version monoproc (pour de l'IPsec) ? Est-ce que Open sait gérer
l'HT dans le cas des EM64T ?
Surement moins cher et peut-être plus performant, jetter un oeil au
AES 128 sur un via c3 ? ça à l'air de cartonner !
http://marc.theaimsgroup.com/?l=openbsd-misc&m7577297024182&w=2
http://archives.neohapsis.com/archives/openbsd/2004-05/0430.html
Bonjour, Je ne connais pas les réponses à tes questions mais
mais dès que je fais passer 20 MBits dans l'un d'eux, ça prend tout le proc d'un Celeron IV 2.4 GHz.
est surprenant, vu que http://www.openbsd.org/crypto.html parle de 64Mbit/s en 3DES/SHA1 ESP sur un p3 500Mhz pour les plus vieilles hifn...
Sur une machine équivalente à tienne (mais sans hifn), openssl speed me dit: hmac(md5) 14794.66k 49548.27k 141013.70k 255310.94k 336169.12k blowfish cbc 63785.61k 68899.74k 67888.09k 71882.01k 79549.04k aes-128 cbc 42120.44k 41422.45k 41729.62k 41939.64k 41975.72k
Tu devrait donc avoir de la marge. Tu utilise des algo symétriques très gourmands avec de grosses clefs ? Si je ne m'abuse les hifn accelerent 3des uniqument non ? (chez moi 3des est 3 fois plus lent que blowfish sur la cpu0, selon openssl speed). Je me demande si ces cartes sont très interessantes sur une cpu rapide ...
cpu0: Intel(R) Pentium(R) 4 CPU 2.80GHz ("GenuineIntel" 686-class) 2.81 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT, PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID (btw c'est un p4 avec HT, mais pas supporté parceque le bios est UP).
Est-ce que si je colle un Bi Opteron (ou Bi EM64T), est-ce qu'il sera capable de chiffrer deux fois le débit que serait capable de chiffrer la version monoproc (pour de l'IPsec) ? Est-ce que Open sait gérer l'HT dans le cas des EM64T ?
Surement moins cher et peut-être plus performant, jetter un oeil au AES 128 sur un via c3 ? ça à l'air de cartonner ! http://marc.theaimsgroup.com/?l=openbsd-misc&m7577297024182&w=2 http://archives.neohapsis.com/archives/openbsd/2004-05/0430.html
Vincent Bernat
OoO En ce début de soirée du dimanche 06 novembre 2005, vers 21:37, Benjamin Pineau disait:
mais dès que je fais passer 20 MBits dans l'un d'eux, ça prend tout le proc d'un Celeron IV 2.4 GHz.
est surprenant, vu que http://www.openbsd.org/crypto.html parle de 64Mbit/s en 3DES/SHA1 ESP sur un p3 500Mhz pour les plus vieilles hifn...
Sur une machine équivalente à tienne (mais sans hifn), openssl speed me dit: hmac(md5) 14794.66k 49548.27k 141013.70k 255310.94k 336169.12k blowfish cbc 63785.61k 68899.74k 67888.09k 71882.01k 79549.04k aes-128 cbc 42120.44k 41422.45k 41729.62k 41939.64k 41975.72k
Tu devrait donc avoir de la marge. Tu utilise des algo symétriques très gourmands avec de grosses clefs ?
openssl speed me donne des résultats supérieurs aux tiens (comment est-ce possible ?), mais n'empêche que dès que y'a 20 MBits à chiffrer, le proc se retrouve quasiment à 100% (sans carte de crypto).
Surement moins cher et peut-être plus performant, jetter un oeil au AES 128 sur un via c3 ? ça à l'air de cartonner ! http://marc.theaimsgroup.com/?l=openbsd-misc&m7577297024182&w=2 http://archives.neohapsis.com/archives/openbsd/2004-05/0430.html
En effet, je vais creuser de ce côté. Mais j'ai peur qu'en pratique, cela ne matche pas forcément les benchmarks. -- NERVE GAS IS NOT A TOY NERVE GAS IS NOT A TOY NERVE GAS IS NOT A TOY -+- Bart Simpson on chalkboard in episode 2F32
OoO En ce début de soirée du dimanche 06 novembre 2005, vers 21:37,
Benjamin Pineau <ben-removethisifyourehuman@zouh.org> disait:
mais dès que je fais passer 20 MBits dans l'un d'eux, ça prend tout le
proc d'un Celeron IV 2.4 GHz.
est surprenant, vu que http://www.openbsd.org/crypto.html parle de
64Mbit/s en 3DES/SHA1 ESP sur un p3 500Mhz pour les plus vieilles hifn...
Sur une machine équivalente à tienne (mais sans hifn), openssl speed me dit:
hmac(md5) 14794.66k 49548.27k 141013.70k 255310.94k 336169.12k
blowfish cbc 63785.61k 68899.74k 67888.09k 71882.01k 79549.04k
aes-128 cbc 42120.44k 41422.45k 41729.62k 41939.64k 41975.72k
Tu devrait donc avoir de la marge. Tu utilise des algo symétriques très
gourmands avec de grosses clefs ?
openssl speed me donne des résultats supérieurs aux tiens (comment
est-ce possible ?), mais n'empêche que dès que y'a 20 MBits à
chiffrer, le proc se retrouve quasiment à 100% (sans carte de crypto).
Surement moins cher et peut-être plus performant, jetter un oeil au
AES 128 sur un via c3 ? ça à l'air de cartonner !
http://marc.theaimsgroup.com/?l=openbsd-misc&m7577297024182&w=2
http://archives.neohapsis.com/archives/openbsd/2004-05/0430.html
En effet, je vais creuser de ce côté. Mais j'ai peur qu'en pratique,
cela ne matche pas forcément les benchmarks.
--
NERVE GAS IS NOT A TOY
NERVE GAS IS NOT A TOY
NERVE GAS IS NOT A TOY
-+- Bart Simpson on chalkboard in episode 2F32
OoO En ce début de soirée du dimanche 06 novembre 2005, vers 21:37, Benjamin Pineau disait:
mais dès que je fais passer 20 MBits dans l'un d'eux, ça prend tout le proc d'un Celeron IV 2.4 GHz.
est surprenant, vu que http://www.openbsd.org/crypto.html parle de 64Mbit/s en 3DES/SHA1 ESP sur un p3 500Mhz pour les plus vieilles hifn...
Sur une machine équivalente à tienne (mais sans hifn), openssl speed me dit: hmac(md5) 14794.66k 49548.27k 141013.70k 255310.94k 336169.12k blowfish cbc 63785.61k 68899.74k 67888.09k 71882.01k 79549.04k aes-128 cbc 42120.44k 41422.45k 41729.62k 41939.64k 41975.72k
Tu devrait donc avoir de la marge. Tu utilise des algo symétriques très gourmands avec de grosses clefs ?
openssl speed me donne des résultats supérieurs aux tiens (comment est-ce possible ?), mais n'empêche que dès que y'a 20 MBits à chiffrer, le proc se retrouve quasiment à 100% (sans carte de crypto).
Surement moins cher et peut-être plus performant, jetter un oeil au AES 128 sur un via c3 ? ça à l'air de cartonner ! http://marc.theaimsgroup.com/?l=openbsd-misc&m7577297024182&w=2 http://archives.neohapsis.com/archives/openbsd/2004-05/0430.html
En effet, je vais creuser de ce côté. Mais j'ai peur qu'en pratique, cela ne matche pas forcément les benchmarks. -- NERVE GAS IS NOT A TOY NERVE GAS IS NOT A TOY NERVE GAS IS NOT A TOY -+- Bart Simpson on chalkboard in episode 2F32
Vincent Bernat
OoO En ce début de soirée du dimanche 06 novembre 2005, vers 21:37, Benjamin Pineau disait:
Surement moins cher et peut-être plus performant, jetter un oeil au AES 128 sur un via c3 ? ça à l'air de cartonner !
Le problème, c'est que j'ai aussi besoin de faire du 3DES (à cause de Windows). Et ce n'est pas supporté. P'tet que le C7 permettrait d'avoir un équilibre entre l'accélération de l'AES et du SHA et une puissance suffisante pour faire du 3DES en "soft". -- printk("What? oldfid != cii->c_fid. Call 911.n"); 2.4.3 linux/fs/coda/cnode.c
OoO En ce début de soirée du dimanche 06 novembre 2005, vers 21:37,
Benjamin Pineau <ben-removethisifyourehuman@zouh.org> disait:
Surement moins cher et peut-être plus performant, jetter un oeil au
AES 128 sur un via c3 ? ça à l'air de cartonner !
Le problème, c'est que j'ai aussi besoin de faire du 3DES (à cause de
Windows). Et ce n'est pas supporté. P'tet que le C7 permettrait
d'avoir un équilibre entre l'accélération de l'AES et du SHA et une
puissance suffisante pour faire du 3DES en "soft".
--
printk("What? oldfid != cii->c_fid. Call 911.n");
2.4.3 linux/fs/coda/cnode.c
OoO En ce début de soirée du dimanche 06 novembre 2005, vers 21:37, Benjamin Pineau disait:
Surement moins cher et peut-être plus performant, jetter un oeil au AES 128 sur un via c3 ? ça à l'air de cartonner !
Le problème, c'est que j'ai aussi besoin de faire du 3DES (à cause de Windows). Et ce n'est pas supporté. P'tet que le C7 permettrait d'avoir un équilibre entre l'accélération de l'AES et du SHA et une puissance suffisante pour faire du 3DES en "soft". -- printk("What? oldfid != cii->c_fid. Call 911.n"); 2.4.3 linux/fs/coda/cnode.c
VANHULLEBUS Yvan
Vincent Bernat writes: [....]
openssl speed me donne des résultats supérieurs aux tiens (comment est-ce possible ?), mais n'empêche que dès que y'a 20 MBits à chiffrer, le proc se retrouve quasiment à 100% (sans carte de crypto).
Parceque openssl speed fait "juste" des benchs de chiffrement par blocs en mode userland, alors que tes mesures de performances "reeles" sont a propos de paquets ESP (donc avec des manipulations en plus), le tout en mode kernel.
Si OpenBSD se comporte comme Free sur ce point la, des que tu commences a depasser les 50-60% d'interruptions (ce qui peut arriver rapidement quand tu fais de l'IPSec avec de gros debits), les valeurs de top veulent plus rien dire (j'ai deja eu des tops avec 3 demons a 250% chacun.... sur un monoproc, je precise !!!).
A +
VANHU.
Vincent Bernat <vince@khabale.org> writes:
[....]
openssl speed me donne des résultats supérieurs aux tiens (comment
est-ce possible ?), mais n'empêche que dès que y'a 20 MBits à
chiffrer, le proc se retrouve quasiment à 100% (sans carte de crypto).
Parceque openssl speed fait "juste" des benchs de chiffrement par
blocs en mode userland, alors que tes mesures de performances "reeles"
sont a propos de paquets ESP (donc avec des manipulations en plus), le
tout en mode kernel.
Si OpenBSD se comporte comme Free sur ce point la, des que tu
commences a depasser les 50-60% d'interruptions (ce qui peut arriver
rapidement quand tu fais de l'IPSec avec de gros debits), les valeurs
de top veulent plus rien dire (j'ai deja eu des tops avec 3 demons a
250% chacun.... sur un monoproc, je precise !!!).
openssl speed me donne des résultats supérieurs aux tiens (comment est-ce possible ?), mais n'empêche que dès que y'a 20 MBits à chiffrer, le proc se retrouve quasiment à 100% (sans carte de crypto).
Parceque openssl speed fait "juste" des benchs de chiffrement par blocs en mode userland, alors que tes mesures de performances "reeles" sont a propos de paquets ESP (donc avec des manipulations en plus), le tout en mode kernel.
Si OpenBSD se comporte comme Free sur ce point la, des que tu commences a depasser les 50-60% d'interruptions (ce qui peut arriver rapidement quand tu fais de l'IPSec avec de gros debits), les valeurs de top veulent plus rien dire (j'ai deja eu des tops avec 3 demons a 250% chacun.... sur un monoproc, je precise !!!).
A +
VANHU.
Benjamin Pineau
Le Sun, 06 Nov 2005 23:16:47 +0100, Vincent Bernat écrivait:
Tu devrait donc avoir de la marge. Tu utilise des algo symétriques très gourmands avec de grosses clefs ?
openssl speed me donne des résultats supérieurs aux tiens (comment est-ce possible ?), mais n'empêche que dès que y'a 20 MBits à chiffrer, le proc se retrouve quasiment à 100% (sans carte de crypto).
Bon en même temps l'implémentation mesurée (openssl) n'est pas celle utilisée dans ton cas (3DES dans le noyau), je voulais surtout signaler des algos qui performent bien (du moins dans l'implem d'openssl, mais sans doute aussi dans le kernel) (oh, et: quelle version d'open utilise-tu ?).
Je n'ai pas de passerelles IPsec très goulues en traffic (ni en nombre de tunnels) donc tes commentaires sont interessants pour moi. As-tu essayé de profiler un peu ? c'est pas facile vu que le chiffrement n'est pas en userland, mais on dirait qu'il y a vraiment quelque chose qui cloche, 20Mbit/s ça me semble vraiment faible... ou tester avec d'autres algos, interfaces reseau, pf ou pas, avec ou sans serveurs de clefs etc. (même si tu doit l'utiliser une config précise en prod, ce serait vachement utile, pour tout le monde, de savoir si 3des est la cause de ce genre de pb ou pas).
Surement moins cher et peut-être plus performant, jetter un oeil au AES 128 sur un via c3 ? ça à l'air de cartonner ! http://marc.theaimsgroup.com/?l=openbsd-misc&m7577297024182&w=2 http://archives.neohapsis.com/archives/openbsd/2004-05/0430.html
En effet, je vais creuser de ce côté. Mais j'ai peur qu'en pratique, cela ne matche pas forcément les benchmarks.
C'est clair. Il vaudrait mieux pinguer misc@ (ou autres) pour avoir des retours d'utilisation. Mais sur du 3DES j'ai vraiment un doute (et aussi pour ta question concernant les améliorations à esperer du SMP ...).
Le Sun, 06 Nov 2005 23:16:47 +0100,
Vincent Bernat <vince@khabale.org> écrivait:
Tu devrait donc avoir de la marge. Tu utilise des algo symétriques très
gourmands avec de grosses clefs ?
openssl speed me donne des résultats supérieurs aux tiens (comment
est-ce possible ?), mais n'empêche que dès que y'a 20 MBits à
chiffrer, le proc se retrouve quasiment à 100% (sans carte de crypto).
Bon en même temps l'implémentation mesurée (openssl) n'est pas celle utilisée
dans ton cas (3DES dans le noyau), je voulais surtout signaler des algos qui
performent bien (du moins dans l'implem d'openssl, mais sans doute aussi dans
le kernel) (oh, et: quelle version d'open utilise-tu ?).
Je n'ai pas de passerelles IPsec très goulues en traffic (ni en nombre de
tunnels) donc tes commentaires sont interessants pour moi.
As-tu essayé de profiler un peu ? c'est pas facile vu que le chiffrement
n'est pas en userland, mais on dirait qu'il y a vraiment quelque chose qui
cloche, 20Mbit/s ça me semble vraiment faible... ou tester avec d'autres
algos, interfaces reseau, pf ou pas, avec ou sans serveurs de clefs etc.
(même si tu doit l'utiliser une config précise en prod, ce serait vachement
utile, pour tout le monde, de savoir si 3des est la cause de ce genre de pb
ou pas).
Surement moins cher et peut-être plus performant, jetter un oeil au
AES 128 sur un via c3 ? ça à l'air de cartonner !
http://marc.theaimsgroup.com/?l=openbsd-misc&m7577297024182&w=2
http://archives.neohapsis.com/archives/openbsd/2004-05/0430.html
En effet, je vais creuser de ce côté. Mais j'ai peur qu'en pratique,
cela ne matche pas forcément les benchmarks.
C'est clair. Il vaudrait mieux pinguer misc@ (ou autres) pour avoir des
retours d'utilisation. Mais sur du 3DES j'ai vraiment un doute (et aussi
pour ta question concernant les améliorations à esperer du SMP ...).
Le Sun, 06 Nov 2005 23:16:47 +0100, Vincent Bernat écrivait:
Tu devrait donc avoir de la marge. Tu utilise des algo symétriques très gourmands avec de grosses clefs ?
openssl speed me donne des résultats supérieurs aux tiens (comment est-ce possible ?), mais n'empêche que dès que y'a 20 MBits à chiffrer, le proc se retrouve quasiment à 100% (sans carte de crypto).
Bon en même temps l'implémentation mesurée (openssl) n'est pas celle utilisée dans ton cas (3DES dans le noyau), je voulais surtout signaler des algos qui performent bien (du moins dans l'implem d'openssl, mais sans doute aussi dans le kernel) (oh, et: quelle version d'open utilise-tu ?).
Je n'ai pas de passerelles IPsec très goulues en traffic (ni en nombre de tunnels) donc tes commentaires sont interessants pour moi. As-tu essayé de profiler un peu ? c'est pas facile vu que le chiffrement n'est pas en userland, mais on dirait qu'il y a vraiment quelque chose qui cloche, 20Mbit/s ça me semble vraiment faible... ou tester avec d'autres algos, interfaces reseau, pf ou pas, avec ou sans serveurs de clefs etc. (même si tu doit l'utiliser une config précise en prod, ce serait vachement utile, pour tout le monde, de savoir si 3des est la cause de ce genre de pb ou pas).
Surement moins cher et peut-être plus performant, jetter un oeil au AES 128 sur un via c3 ? ça à l'air de cartonner ! http://marc.theaimsgroup.com/?l=openbsd-misc&m7577297024182&w=2 http://archives.neohapsis.com/archives/openbsd/2004-05/0430.html
En effet, je vais creuser de ce côté. Mais j'ai peur qu'en pratique, cela ne matche pas forcément les benchmarks.
C'est clair. Il vaudrait mieux pinguer misc@ (ou autres) pour avoir des retours d'utilisation. Mais sur du 3DES j'ai vraiment un doute (et aussi pour ta question concernant les améliorations à esperer du SMP ...).
Vincent Bernat
OoO En cette fin de matinée radieuse du lundi 07 novembre 2005, vers 11:51, VANHULLEBUS Yvan disait:
openssl speed me donne des résultats supérieurs aux tiens (comment est-ce possible ?), mais n'empêche que dès que y'a 20 MBits à chiffrer, le proc se retrouve quasiment à 100% (sans carte de crypto).
Parceque openssl speed fait "juste" des benchs de chiffrement par blocs en mode userland, alors que tes mesures de performances "reeles" sont a propos de paquets ESP (donc avec des manipulations en plus), le tout en mode kernel.
Si OpenBSD se comporte comme Free sur ce point la, des que tu commences a depasser les 50-60% d'interruptions (ce qui peut arriver rapidement quand tu fais de l'IPSec avec de gros debits), les valeurs de top veulent plus rien dire (j'ai deja eu des tops avec 3 demons a 250% chacun.... sur un monoproc, je precise !!!).
Donc question : comment je sais si le proc est bien dimensioné ? -- Make sure comments and code agree. - The Elements of Programming Style (Kernighan & Plauger)
OoO En cette fin de matinée radieuse du lundi 07 novembre 2005, vers
11:51, VANHULLEBUS Yvan <vanhu@nospam_free.fr> disait:
openssl speed me donne des résultats supérieurs aux tiens (comment
est-ce possible ?), mais n'empêche que dès que y'a 20 MBits à
chiffrer, le proc se retrouve quasiment à 100% (sans carte de crypto).
Parceque openssl speed fait "juste" des benchs de chiffrement par
blocs en mode userland, alors que tes mesures de performances "reeles"
sont a propos de paquets ESP (donc avec des manipulations en plus), le
tout en mode kernel.
Si OpenBSD se comporte comme Free sur ce point la, des que tu
commences a depasser les 50-60% d'interruptions (ce qui peut arriver
rapidement quand tu fais de l'IPSec avec de gros debits), les valeurs
de top veulent plus rien dire (j'ai deja eu des tops avec 3 demons a
250% chacun.... sur un monoproc, je precise !!!).
Donc question : comment je sais si le proc est bien dimensioné ?
--
Make sure comments and code agree.
- The Elements of Programming Style (Kernighan & Plauger)
OoO En cette fin de matinée radieuse du lundi 07 novembre 2005, vers 11:51, VANHULLEBUS Yvan disait:
openssl speed me donne des résultats supérieurs aux tiens (comment est-ce possible ?), mais n'empêche que dès que y'a 20 MBits à chiffrer, le proc se retrouve quasiment à 100% (sans carte de crypto).
Parceque openssl speed fait "juste" des benchs de chiffrement par blocs en mode userland, alors que tes mesures de performances "reeles" sont a propos de paquets ESP (donc avec des manipulations en plus), le tout en mode kernel.
Si OpenBSD se comporte comme Free sur ce point la, des que tu commences a depasser les 50-60% d'interruptions (ce qui peut arriver rapidement quand tu fais de l'IPSec avec de gros debits), les valeurs de top veulent plus rien dire (j'ai deja eu des tops avec 3 demons a 250% chacun.... sur un monoproc, je precise !!!).
Donc question : comment je sais si le proc est bien dimensioné ? -- Make sure comments and code agree. - The Elements of Programming Style (Kernighan & Plauger)
Vincent Bernat
OoO Peu avant le début de l'après-midi du lundi 07 novembre 2005, vers 13:59, Benjamin Pineau disait:
Bon en même temps l'implémentation mesurée (openssl) n'est pas celle utilisée dans ton cas (3DES dans le noyau), je voulais surtout signaler des algos qui performent bien (du moins dans l'implem d'openssl, mais sans doute aussi dans le kernel) (oh, et: quelle version d'open utilise-tu ?).
La 3.8. Mais avec la 3.6, c'était un peu pareil. Sinon, les tunnels sont aussi en AES, ça dépend des OS de l'autre côté.
As-tu essayé de profiler un peu ? c'est pas facile vu que le chiffrement n'est pas en userland, mais on dirait qu'il y a vraiment quelque chose qui cloche, 20Mbit/s ça me semble vraiment faible... ou tester avec d'autres algos, interfaces reseau, pf ou pas, avec ou sans serveurs de clefs etc. (même si tu doit l'utiliser une config précise en prod, ce serait vachement utile, pour tout le monde, de savoir si 3des est la cause de ce genre de pb ou pas).
Le serveur est en prod, je peux difficilement virer des trucs. Je tenterai de benchmarker en AES pour voir ce que cela donne (car c'est configuré pour). Les autres bouts des tunnels sont des clients en wifi, donc un seul client ne peut pas saturer la machine. Il faudra que j'attaque avec un fil pour faire un benchmark correct. -- I WILL NOT USE ABBREV. I WILL NOT USE ABBREV. I WILL NOT USE ABBREV. -+- Bart Simpson on chalkboard in episode 2F33
OoO Peu avant le début de l'après-midi du lundi 07 novembre 2005, vers
13:59, Benjamin Pineau <ben-removethisifyourehuman@zouh.org> disait:
Bon en même temps l'implémentation mesurée (openssl) n'est pas celle utilisée
dans ton cas (3DES dans le noyau), je voulais surtout signaler des algos qui
performent bien (du moins dans l'implem d'openssl, mais sans doute aussi dans
le kernel) (oh, et: quelle version d'open utilise-tu ?).
La 3.8. Mais avec la 3.6, c'était un peu pareil. Sinon, les tunnels
sont aussi en AES, ça dépend des OS de l'autre côté.
As-tu essayé de profiler un peu ? c'est pas facile vu que le chiffrement
n'est pas en userland, mais on dirait qu'il y a vraiment quelque chose qui
cloche, 20Mbit/s ça me semble vraiment faible... ou tester avec d'autres
algos, interfaces reseau, pf ou pas, avec ou sans serveurs de clefs etc.
(même si tu doit l'utiliser une config précise en prod, ce serait vachement
utile, pour tout le monde, de savoir si 3des est la cause de ce genre de pb
ou pas).
Le serveur est en prod, je peux difficilement virer des trucs. Je
tenterai de benchmarker en AES pour voir ce que cela donne (car c'est
configuré pour). Les autres bouts des tunnels sont des clients en
wifi, donc un seul client ne peut pas saturer la machine. Il faudra
que j'attaque avec un fil pour faire un benchmark correct.
--
I WILL NOT USE ABBREV.
I WILL NOT USE ABBREV.
I WILL NOT USE ABBREV.
-+- Bart Simpson on chalkboard in episode 2F33
OoO Peu avant le début de l'après-midi du lundi 07 novembre 2005, vers 13:59, Benjamin Pineau disait:
Bon en même temps l'implémentation mesurée (openssl) n'est pas celle utilisée dans ton cas (3DES dans le noyau), je voulais surtout signaler des algos qui performent bien (du moins dans l'implem d'openssl, mais sans doute aussi dans le kernel) (oh, et: quelle version d'open utilise-tu ?).
La 3.8. Mais avec la 3.6, c'était un peu pareil. Sinon, les tunnels sont aussi en AES, ça dépend des OS de l'autre côté.
As-tu essayé de profiler un peu ? c'est pas facile vu que le chiffrement n'est pas en userland, mais on dirait qu'il y a vraiment quelque chose qui cloche, 20Mbit/s ça me semble vraiment faible... ou tester avec d'autres algos, interfaces reseau, pf ou pas, avec ou sans serveurs de clefs etc. (même si tu doit l'utiliser une config précise en prod, ce serait vachement utile, pour tout le monde, de savoir si 3des est la cause de ce genre de pb ou pas).
Le serveur est en prod, je peux difficilement virer des trucs. Je tenterai de benchmarker en AES pour voir ce que cela donne (car c'est configuré pour). Les autres bouts des tunnels sont des clients en wifi, donc un seul client ne peut pas saturer la machine. Il faudra que j'attaque avec un fil pour faire un benchmark correct. -- I WILL NOT USE ABBREV. I WILL NOT USE ABBREV. I WILL NOT USE ABBREV. -+- Bart Simpson on chalkboard in episode 2F33
Vincent Bernat
OoO Peu avant le début de l'après-midi du lundi 07 novembre 2005, vers 13:59, Benjamin Pineau disait:
As-tu essayé de profiler un peu ? c'est pas facile vu que le chiffrement n'est pas en userland, mais on dirait qu'il y a vraiment quelque chose qui cloche, 20Mbit/s ça me semble vraiment faible...
Remarque, en 3DES, avec OpenSSL, cette machine ne fait plus que 15 Mo/s. J'ai été pessimiste sur les 20 Mbits. On doit pouvoir monter à 40 MBits. Juste du 3DES, ça fait 120 MBits. Si on compte qu'il faut faire en plus des sommes de contrôle, des signatures et compagnie, le rapport est p'tet pas aussi irréaliste.
Si je pouvais me débarasser du 3DES... Mais Microsoft ne sait faire que ça pour de l'IPsec. -- Don't use conditional branches as a substitute for a logical expression. - The Elements of Programming Style (Kernighan & Plauger)
OoO Peu avant le début de l'après-midi du lundi 07 novembre 2005, vers
13:59, Benjamin Pineau <ben-removethisifyourehuman@zouh.org> disait:
As-tu essayé de profiler un peu ? c'est pas facile vu que le chiffrement
n'est pas en userland, mais on dirait qu'il y a vraiment quelque chose qui
cloche, 20Mbit/s ça me semble vraiment faible...
Remarque, en 3DES, avec OpenSSL, cette machine ne fait plus que 15
Mo/s. J'ai été pessimiste sur les 20 Mbits. On doit pouvoir monter à
40 MBits. Juste du 3DES, ça fait 120 MBits. Si on compte qu'il faut
faire en plus des sommes de contrôle, des signatures et compagnie, le
rapport est p'tet pas aussi irréaliste.
Si je pouvais me débarasser du 3DES... Mais Microsoft ne sait faire
que ça pour de l'IPsec.
--
Don't use conditional branches as a substitute for a logical expression.
- The Elements of Programming Style (Kernighan & Plauger)
OoO Peu avant le début de l'après-midi du lundi 07 novembre 2005, vers 13:59, Benjamin Pineau disait:
As-tu essayé de profiler un peu ? c'est pas facile vu que le chiffrement n'est pas en userland, mais on dirait qu'il y a vraiment quelque chose qui cloche, 20Mbit/s ça me semble vraiment faible...
Remarque, en 3DES, avec OpenSSL, cette machine ne fait plus que 15 Mo/s. J'ai été pessimiste sur les 20 Mbits. On doit pouvoir monter à 40 MBits. Juste du 3DES, ça fait 120 MBits. Si on compte qu'il faut faire en plus des sommes de contrôle, des signatures et compagnie, le rapport est p'tet pas aussi irréaliste.
Si je pouvais me débarasser du 3DES... Mais Microsoft ne sait faire que ça pour de l'IPsec. -- Don't use conditional branches as a substitute for a logical expression. - The Elements of Programming Style (Kernighan & Plauger)
Benjamin Pineau
Le Mon, 07 Nov 2005 21:54:22 +0100, Vincent Bernat écrivait:
La 3.8. Mais avec la 3.6, c'était un peu pareil. Sinon, les tunnels sont aussi en AES, ça dépend des OS de l'autre côté.
Il n'existerai pas des rustine ou logiciels adjuvant pour permettre à ce fameux "os de l'autre coté limité au 3des" d'utiliser aes ou blowfish ? (c'est vraiment une question, pas une suggestion).
Le serveur est en prod, je peux difficilement virer des trucs. Je
Heu oui, enfin je ne pensait quand même pas à martyriser une machine en prod ! Pas d'environement de test qui traine ? ça aiderai peut-être parvenir à évaluer le facteur limitant (et peut-être y voir plus clair sur les bénéfices potentiels d'une nouvelle cpu). Eg. tenter avec du simple des pour voir si le chiffrement est vraiment en cause (sait-on jamais ...).
Bon je vais essayer chez moi, cette question m'interesse (mais avec des cartes rtl8139' el cheapo je pense que je vais saturer le lien avant le noyau (?)).
Le Mon, 07 Nov 2005 21:54:22 +0100,
Vincent Bernat <bernat@luffy.cx> écrivait:
La 3.8. Mais avec la 3.6, c'était un peu pareil. Sinon, les tunnels
sont aussi en AES, ça dépend des OS de l'autre côté.
Il n'existerai pas des rustine ou logiciels adjuvant pour permettre à ce
fameux "os de l'autre coté limité au 3des" d'utiliser aes ou blowfish ?
(c'est vraiment une question, pas une suggestion).
Le serveur est en prod, je peux difficilement virer des trucs. Je
Heu oui, enfin je ne pensait quand même pas à martyriser une machine en prod !
Pas d'environement de test qui traine ? ça aiderai peut-être parvenir à
évaluer le facteur limitant (et peut-être y voir plus clair sur les bénéfices
potentiels d'une nouvelle cpu). Eg. tenter avec du simple des pour voir si le
chiffrement est vraiment en cause (sait-on jamais ...).
Bon je vais essayer chez moi, cette question m'interesse (mais avec des cartes
rtl8139' el cheapo je pense que je vais saturer le lien avant le noyau (?)).
Le Mon, 07 Nov 2005 21:54:22 +0100, Vincent Bernat écrivait:
La 3.8. Mais avec la 3.6, c'était un peu pareil. Sinon, les tunnels sont aussi en AES, ça dépend des OS de l'autre côté.
Il n'existerai pas des rustine ou logiciels adjuvant pour permettre à ce fameux "os de l'autre coté limité au 3des" d'utiliser aes ou blowfish ? (c'est vraiment une question, pas une suggestion).
Le serveur est en prod, je peux difficilement virer des trucs. Je
Heu oui, enfin je ne pensait quand même pas à martyriser une machine en prod ! Pas d'environement de test qui traine ? ça aiderai peut-être parvenir à évaluer le facteur limitant (et peut-être y voir plus clair sur les bénéfices potentiels d'une nouvelle cpu). Eg. tenter avec du simple des pour voir si le chiffrement est vraiment en cause (sait-on jamais ...).
Bon je vais essayer chez moi, cette question m'interesse (mais avec des cartes rtl8139' el cheapo je pense que je vais saturer le lien avant le noyau (?)).
Vincent Bernat
OoO En cette nuit nuageuse du mercredi 09 novembre 2005, vers 01:26, Benjamin Pineau disait:
La 3.8. Mais avec la 3.6, c'était un peu pareil. Sinon, les tunnels sont aussi en AES, ça dépend des OS de l'autre côté.
Il n'existerai pas des rustine ou logiciels adjuvant pour permettre à ce fameux "os de l'autre coté limité au 3des" d'utiliser aes ou blowfish ? (c'est vraiment une question, pas une suggestion).
Ce serait l'idéal, mais je n'ai rien trouvé. Ils ne comptent toujours pas coller AES dans les prochaines versions d'ailleurs...
Bon je vais essayer chez moi, cette question m'interesse (mais avec des cartes rtl8139' el cheapo je pense que je vais saturer le lien avant le noyau (?)).
Si comme moi, tu te trouves limité à 40 MB/s, même des Realtek supportent sans problème ce débit.
Au fait, j'ai initié un thread dans misc@ et je suis encore plus perdu qu'avant. Entre l'un qui me conseille une carte crypto et l'autre qui dit que c'est inutile... -- #if 0 2.2.16 /usr/src/linux/fs/buffer.c
OoO En cette nuit nuageuse du mercredi 09 novembre 2005, vers 01:26,
Benjamin Pineau <ben-removethisifyourehuman@zouh.org> disait:
La 3.8. Mais avec la 3.6, c'était un peu pareil. Sinon, les tunnels
sont aussi en AES, ça dépend des OS de l'autre côté.
Il n'existerai pas des rustine ou logiciels adjuvant pour permettre à ce
fameux "os de l'autre coté limité au 3des" d'utiliser aes ou blowfish ?
(c'est vraiment une question, pas une suggestion).
Ce serait l'idéal, mais je n'ai rien trouvé. Ils ne comptent toujours
pas coller AES dans les prochaines versions d'ailleurs...
Bon je vais essayer chez moi, cette question m'interesse (mais avec des cartes
rtl8139' el cheapo je pense que je vais saturer le lien avant le noyau (?)).
Si comme moi, tu te trouves limité à 40 MB/s, même des Realtek
supportent sans problème ce débit.
Au fait, j'ai initié un thread dans misc@ et je suis encore plus perdu
qu'avant. Entre l'un qui me conseille une carte crypto et l'autre qui
dit que c'est inutile...
--
#if 0
2.2.16 /usr/src/linux/fs/buffer.c
OoO En cette nuit nuageuse du mercredi 09 novembre 2005, vers 01:26, Benjamin Pineau disait:
La 3.8. Mais avec la 3.6, c'était un peu pareil. Sinon, les tunnels sont aussi en AES, ça dépend des OS de l'autre côté.
Il n'existerai pas des rustine ou logiciels adjuvant pour permettre à ce fameux "os de l'autre coté limité au 3des" d'utiliser aes ou blowfish ? (c'est vraiment une question, pas une suggestion).
Ce serait l'idéal, mais je n'ai rien trouvé. Ils ne comptent toujours pas coller AES dans les prochaines versions d'ailleurs...
Bon je vais essayer chez moi, cette question m'interesse (mais avec des cartes rtl8139' el cheapo je pense que je vais saturer le lien avant le noyau (?)).
Si comme moi, tu te trouves limité à 40 MB/s, même des Realtek supportent sans problème ce débit.
Au fait, j'ai initié un thread dans misc@ et je suis encore plus perdu qu'avant. Entre l'un qui me conseille une carte crypto et l'autre qui dit que c'est inutile... -- #if 0 2.2.16 /usr/src/linux/fs/buffer.c
