Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Perte de débit suite au remplacement de la livebox

    Scheduled Pinned Locked Moved Français
    7 Posts 4 Posters 1.6k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • K
      kalistyan
      last edited by

      Salut  :)

      J'ai remarqué une perte de débit, depuis le remplacement de la livebox, par un routeur pfSense.

      Débit livebox :

      Débit pfSense :

      Version

      2.3.2-RELEASE (amd64)
      built on Tue Jul 19 12:44:43 CDT 2016
      FreeBSD 10.3-RELEASE-p5

      CPU Type

      Intel(R) Atom(TM) CPU 330 @ 1.60GHz
      4 CPUs: 1 package(s) x 2 core(s) x 2 HTT threads

      [2.3.2-RELEASE][root@pfsense.unnati.lan]/root: grep -i cpu /var/run/dmesg.boot
      CPU: Intel(R) Atom(TM) CPU  330  @ 1.60GHz (1600.01-MHz K8-class CPU)
      FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
      cpu0 (BSP): APIC ID:  0
      cpu1 (AP/HT): APIC ID:  1
      cpu2 (AP): APIC ID:  2
      cpu3 (AP/HT): APIC ID:  3
      cpu0: <acpi cpu="">on acpi0
      cpu1: <acpi cpu="">on acpi0
      cpu2: <acpi cpu="">on acpi0
      cpu3: <acpi cpu="">on acpi0
      SMP: AP CPU #3 Launched!
      SMP: AP CPU #1 Launched!
      SMP: AP CPU #2 Launched!</acpi></acpi></acpi></acpi>

      Réglage pfSense :

      Aucune saturation processeur sur la charge générale, possible d'avoir un graphique sur la charge par core ?

      1 Reply Last reply Reply Quote 0
      • C
        chris4916
        last edited by

        Est volontairement que tu demandes au CPU de prendre en charge le checksum plutôt que le laisser à la charge des cartes réseau ?

        Jah Olela Wembo: Les mots se muent en maux quand ils indisposent, agressent ou blessent.

        1 Reply Last reply Reply Quote 0
        • J
          jdh
          last edited by

          Avec aussi peu d'informations …

          pfSense est un firewall avec un certain nombre de services, voire de packages (dont on ne sait rien).
          De plus, pfSense, contrairement à des appliances commerciales, dispose d'un noyau 'général' et non optimisé.
          Ca n'a pas beaucoup à voir avec une box qui, va se contenter de fonctionner en routeur, a des services minimaux, est optimisé pour certains traitements, bref ne fait pas la même chose.

          Vos choix de 'network' sont-il comparables ? (déjà écrit)

          Par ailleurs, que savez vous de votre outil de mesure ? Combien la mesure prend de temps = est ce représentatif ? Quel volume de données sert à cette mesure ? Le test est-il fait avec les mêmes éléments ?
          Notamment quand 2 éléments changent, il n'est pas facile de faire des comparaisons. C'est le cas ici, nettement. En particulier, sur Internet, il est connu que la route est dépendante du 'best effort'.

          Il me semble logique qu'un pfSense soit moins efficace qu'un routeur (dédié) (parce qu'un box est un routeur dédié).
          En particulier, l'utilisation de packages est à proscrire : même un léger 'darkstat' ou un 'ntopng' doit être pénalisant ..., je ne parle même pas de Squid ...)

          Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

          1 Reply Last reply Reply Quote 0
          • K
            kalistyan
            last edited by

            @chris4916:

            Est volontairement que tu demandes au CPU de prendre en charge le checksum plutôt que le laisser à la charge des cartes réseau ?

            Oui, après avoir découvert des erreurs de ce type :

            [Coloring Rule Name: Checksum Errors]
                [Coloring Rule String [truncated]: eth.fcs.status=="Bad" || ip.checksum.status=="Bad" || tcp.checksum.status=="Bad" || udp.checksum.status=="Bad" || sctp.checksum.status=="Bad" || mstp.checksum.status=="Bad" || cdp.checksum.status=="Bad" ||]

            Il m'a été conseillé de désactiver la prise en charge matériel.

            @jdh:

            Avec aussi peu d'informations …

            J'ai effectivement été avar en info.  ;D

            @jdh:

            En particulier, l'utilisation de packages est à proscrire : même un léger 'darkstat' ou un 'ntopng' doit être pénalisant …, je ne parle même pas de Squid ...)

            Un seul package d'installer, mais désactiver lors des tests.  ;)

            @jdh:

            Par ailleurs, que savez vous de votre outil de mesure ? Combien la mesure prend de temps = est ce représentatif ? Quel volume de données sert à cette mesure ? Le test est-il fait avec les mêmes éléments ?
            Notamment quand 2 éléments changent, il n'est pas facile de faire des comparaisons. C'est le cas ici, nettement. En particulier, sur Internet, il est connu que la route est dépendante du 'best effort'.

            Je ne sais rien de cet outil. Il faut compter moins d'une minute pour réaliser le test. Aucune idée du volume de données utilisées…
            En amont, j'ai un convertisseur fibre vers ethernet, par conséquent, seul la partie routeur change (livebox puis pfsense).

            @jdh:

            Vos choix de 'network' sont-il comparables ? (déjà écrit)

            Choix du serveur en automatique, d'ou la différence entre les deux tests, et étant donné que le second "encaisse" plus…  ;D

            Entre temps, j'ai réalisé d'autres tests, mais cette fois-ci, avec un serveur iperf de chez Online (10 Gb/s).

            Livebox :

            Z:\iperf-3.1.3-win64>iperf3 -c ping.online.net -p 5202 -t 20 -R
            Connecting to host ping.online.net, port 5202
            Reverse mode, remote host ping.online.net is sending
            [  4] local 192.168.38.2 port 64853 connected to 62.210.18.40 port 5202
            [ ID] Interval          Transfer    Bandwidth
            [  4]  0.00-1.00  sec  22.3 MBytes  187 Mbits/sec
            [  4]  1.00-2.00  sec  22.6 MBytes  189 Mbits/sec
            [  4]  2.00-3.00  sec  22.5 MBytes  189 Mbits/sec
            [  4]  3.00-4.00  sec  22.3 MBytes  187 Mbits/sec
            [  4]  4.00-5.00  sec  22.5 MBytes  189 Mbits/sec
            [  4]  5.00-6.00  sec  22.5 MBytes  189 Mbits/sec
            [  4]  6.00-7.00  sec  22.4 MBytes  188 Mbits/sec
            [  4]  7.00-8.00  sec  22.5 MBytes  189 Mbits/sec
            [  4]  8.00-9.00  sec  22.5 MBytes  189 Mbits/sec
            [  4]  9.00-10.00  sec  22.4 MBytes  187 Mbits/sec
            [  4]  10.00-11.00  sec  22.4 MBytes  188 Mbits/sec
            [  4]  11.00-12.00  sec  22.7 MBytes  190 Mbits/sec
            [  4]  12.00-13.00  sec  22.3 MBytes  187 Mbits/sec
            [  4]  13.00-14.00  sec  22.5 MBytes  189 Mbits/sec
            [  4]  14.00-15.00  sec  22.5 MBytes  189 Mbits/sec
            [  4]  15.00-16.00  sec  22.3 MBytes  187 Mbits/sec
            [  4]  16.00-17.00  sec  22.3 MBytes  187 Mbits/sec
            [  4]  17.00-18.00  sec  22.5 MBytes  189 Mbits/sec
            [  4]  18.00-19.00  sec  22.3 MBytes  187 Mbits/sec
            [  4]  19.00-20.00  sec  22.5 MBytes  189 Mbits/sec

            [ ID] Interval          Transfer    Bandwidth      Retr
            [  4]  0.00-20.00  sec  449 MBytes  188 Mbits/sec    0            sender
            [  4]  0.00-20.00  sec  449 MBytes  188 Mbits/sec                  receiver

            iperf Done.

            pfSense :

            Z:\iperf-3.1.3-win64>iperf3 -c ping.online.net -p 5202 -t 20 -R
            Connecting to host ping.online.net, port 5202
            Reverse mode, remote host ping.online.net is sending
            [  4] local 192.168.100.4 port 49501 connected to 62.210.18.40 port 5202
            [ ID] Interval          Transfer    Bandwidth
            [  4]  0.00-1.00  sec  21.7 MBytes  182 Mbits/sec
            [  4]  1.00-2.00  sec  22.3 MBytes  187 Mbits/sec
            [  4]  2.00-3.00  sec  22.3 MBytes  187 Mbits/sec
            [  4]  3.00-4.00  sec  22.1 MBytes  186 Mbits/sec
            [  4]  4.00-5.00  sec  22.3 MBytes  187 Mbits/sec
            [  4]  5.00-6.00  sec  22.3 MBytes  187 Mbits/sec
            [  4]  6.00-7.00  sec  22.3 MBytes  187 Mbits/sec
            [  4]  7.00-8.00  sec  22.3 MBytes  187 Mbits/sec
            [  4]  8.00-9.00  sec  22.3 MBytes  187 Mbits/sec
            [  4]  9.00-10.00  sec  22.3 MBytes  187 Mbits/sec
            [  4]  10.00-11.00  sec  22.3 MBytes  187 Mbits/sec
            [  4]  11.00-12.00  sec  22.3 MBytes  187 Mbits/sec
            [  4]  12.00-13.00  sec  22.3 MBytes  187 Mbits/sec
            [  4]  13.00-14.00  sec  22.2 MBytes  186 Mbits/sec
            [  4]  14.00-15.00  sec  22.3 MBytes  187 Mbits/sec
            [  4]  15.00-16.00  sec  22.3 MBytes  187 Mbits/sec
            [  4]  16.00-17.00  sec  22.3 MBytes  187 Mbits/sec
            [  4]  17.00-18.00  sec  22.3 MBytes  187 Mbits/sec
            [  4]  18.00-19.00  sec  21.6 MBytes  181 Mbits/sec
            [  4]  19.00-20.00  sec  21.9 MBytes  184 Mbits/sec

            [ ID] Interval          Transfer    Bandwidth      Retr
            [  4]  0.00-20.00  sec  445 MBytes  187 Mbits/sec    0            sender
            [  4]  0.00-20.00  sec  445 MBytes  186 Mbits/sec                  receiver

            iperf Done.

            Z:\iperf-3.1.3-win64>

            Résultats quasi identique !

            Finalement, il n'y a p'être pas tant de perte…

            Qu'en pensez vous ?

            1 Reply Last reply Reply Quote 0
            • J
              jdh
              last edited by

              iperf(3) est un outil plus complet, plus paramétrable, et … dont on peut trouver une doc !

              -t 20 : 20 secondes d'échange (au lieu de 10 par défaut) : échange plus long = information de meilleure qualité, à expérimenter sur quelques minutes ...
              -R : reverse Serveur -> Client = mesure du débit 'descendant' : à effectuer dans les 2 sens (-d ?)

              Il est notable qu'un test basé sur UDP peut donner des valeurs supérieures à TCP (du fait de la différence entre les 2 protos).
              Il est notable que le test devrait être fait avec le 'serveur le plus proche' (notion aléatoire du fait de 'best effort' qui peut changer les routes).

              Mais l'info parait meilleure : l'écart aussi grand était aberrant (838 Mb -> 335 Mb), une petite différence est plausible.

              Il ne sert à rien d'avoir un outil (de mesure) si on ne sait pas comment il fonctionne ...

              Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

              1 Reply Last reply Reply Quote 0
              • B
                baalserv
                last edited by

                Vous ne dite rien concernant les cartes ETH utilisé sur le pF, leurs choix à pourtant une importance capitale … ^^

                Si la connerie humaine fournissait de l'énergie, la Terre serait sauvée …

                1 Reply Last reply Reply Quote 0
                • C
                  chris4916
                  last edited by

                  @kalistyan:

                  Qu'en pensez vous ?

                  J'en pense que:

                  1 - ton pfSense de test sans off-load est moins performant que ta LiveBox et peut-être bien limité par le CPU ?
                  2 - Si tu montes un pfSense avec le même CPU (Atom 330) avec des cartes réseau qui supportent de l'off-load, ça devrait arranger les choses. Est-ce suffisant ? je ne sais pas  :P

                  Jah Olela Wembo: Les mots se muent en maux quand ils indisposent, agressent ou blessent.

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.