Salut, je viens de voir la série des échanges et les histoires de perf .

J’ai une question simple :-) , c’est quel modèle de NAS QNAP ?

Je demande parce qu’au final ton premier goulet d’étranglement sera … le TLS …

J’ai fait deux tests et en fonction du browser , stack TLS , tu peux être dans une situation diamétralement opposée :
Un cas ici où ton NAS négocie en AES256_GCM:
TLS_AES_256_GCM_SHA384
Un autre en AES128_GCM:
AES_128_GCM_SHA256

L’impact CPU ( voir capacité d’offloads ) varie énormément.


Cela permet également de soulager la stack TCP / UDP mais également les offloads hardware ( si tu en as côté carte réseau … ) en charge de:
- slicer les paquets ( sendfile, LSO , etc …)
- calculer les différents checksums :
    - IPv4 , pas de Checksum en IPv6 https://en.m.wikipedia.org/wiki/IPv4 , https://en.m.wikipedia.org/wiki/IPv6
    - UDP et TCP ( IPv6 repose uniquement sur les contrôles au niveau des protocoles de niveau 4 et plus )
De même tu sembles n’utiliser que la PKI RSA des certificats Let’s Encrypt.
Ils ont également une PKI ECC qui est moins lourde au niveau de l’ensemble des phases ( nego initiale , rekeying etc …).

Bonjour,

C'est le QNAP TS-264 : https://www.qnap.com/fr-fr/product/ts-264


Je n'ai pas tout compris : ), mais lorsque j'ai regardé l'utilisation de la bande passante utilisé pendant les tests, j'ai aussi regardé la charge CPU qui était très faible.
As-tu une solution pour optimiser tout ça ?

Pour moi tu as des goulets d’étranglement partout sur ce p’tit NAS :

Les SSD sont en  PCIe Gen 3 x1 ( pas suffisant pour du 8gbit/s..)
Le port pour la carte réseau est en Gen 3x2 ( normalement suffisant mais dépend de ta carte …)
Les ports SATA qui saturent …
C’est un « Atom » avec les limites associés  ( PCH , lignes PCIe à souci … , throttling thermique , etc …)

Non c'est un Processeur Intel® Celeron® N5095 4-core/4-thread, capable de passer à 2,9 GHz
Et mes disques sont des SSD SATA III (6 Gb/s), mais ne peuvent pas atteindre les 8Gb/s comme tu l'as écrit.

CPU   Intel(R) Celeron(R) N5105, jusqu'à 2900 MHz (4 cœurs, 4 threads)
C'est celui que j'ai, non ?Don't worry, il n'y a pas de pb, Moi il me convient parfaitement : )

Salut, je viens de voir la série des échanges et les histoires de perf .

J’ai une question simple :-) , c’est quel modèle de NAS QNAP ?

Je demande parce qu’au final ton premier goulet d’étranglement sera … le TLS …

J’ai fait deux tests et en fonction du browser , stack TLS , tu peux être dans une situation diamétralement opposée :
Un cas ici où ton NAS négocie en AES256_GCM:
TLS_AES_256_GCM_SHA384
Un autre en AES128_GCM:
AES_128_GCM_SHA256

L’impact CPU ( voir capacité d’offloads ) varie énormément.

Pour l’histoire de la MTU à 9000/ Jumbo Frame … remet la ….
Cela fait plus de 20 ans que le PMTU discovery path existe 😅.
Ce mécanisme permet à la stack tcp de l’OS de savoir quel et le Path MTU de chacun des tiers .
Tes devices vont savoir que la Livebox / Orange n’accepte pas plus de 1500 côté internet et n’enverront jamais plus grand . Mais ils pourront continuer d’échanger à 9000 en interne …
Cela permet également de soulager la stack TCP / UDP mais également les offloads hardware ( si tu en as côté carte réseau … ) en charge de:
- slicer les paquets ( sendfile, LSO , etc …)
- calculer les différents checksums :
    - IPv4 , pas de Checksum en IPv6 https://en.m.wikipedia.org/wiki/IPv4 , https://en.m.wikipedia.org/wiki/IPv6
    - UDP et TCP ( IPv6 repose uniquement sur les contrôles au niveau des protocoles de niveau 4 et plus )



De même tu sembles n’utiliser que la PKI RSA des certificats Let’s Encrypt.
Ils ont également une PKI ECC qui est moins lourde au niveau de l’ensemble des phases ( nego initiale , rekeying etc …).