Journal Marre des cartes ARM ?

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
19
19
nov.
2018

Hardkernel’s est connu pour ses cartes Odroid Xu4, puis HC1 et HC2 pour mettre du disque dur ; le tout sur achitecture ARM.

Hardkernel sort maintenant une nouvelle carte sur achitecture intel x86 avec des spécifications intéressantes et un très bon support Linux :

  • Le dernier kernel 4.18 Fonctionne nativement parfaitement (Aujourd’hui Ubuntu 18.10)
  • Les pilotes modernes OpenGL 4.5, OpenCL 2.0, Wayland and Vulkan GPU drivers fonctionnent via la librairie standard Mesa
  • Décodeur & encodeur vidéo MPEG2/MPEG4/H.264/H.265/VP8/VP9 HW fonctionne avec VAAPI standard
  • Processeur 4 cœurs 2.3Ghz J4105 (14nm) avec 4MiB de cache
  • Mémoire 2 canaux DDR4-PC19200 (2400MT/s)
  • Mémoire totale jusqu'à 32GiB avec 2 slots SO-DIMM
  • Accélération SSE4.2 (SMM, FPU, NX, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AES)
  • Puce graphique Intel UHD (Gen9.5) 600 (GT1) 700Mhz
  • Sorties vidéos HDMI 2.0 et DP 1.2
  • 4 x PCIe 2.0 pour un stockage NVMe
  • 2 x ports Ethernet Gbit
  • 2 x ports SATA 3.0
  • Multiples sortie USB 3.0/2.0

La consommation au repos reste raisonnable 4W pour monter jusqu'à ~22W max. Refroidissement passif + disque NVMe pour du silence.

Je vais peut être virer le vieux portable de derrière la télé pour regarder Netflix.
Lien

  • # Intéressant, mais combien ça coute ?

    Posté par  . Évalué à 7. Dernière modification le 19 novembre 2018 à 16:13.

    L'avantage des cartes a base de processeur ARM est le cout : pour moins d'une centaine d'euros, on a une carte utilisable en l'état (pas besoin d'ajouter de RAM, au pire on ajoute une carte SD qui coute pas des masses). Pour certaines on a même un connecteur SATA. Pour pas mal d'utilisations, c'est largement suffisant.

    La carte présentée dans ce journal est intéressante, semble plus performante que les cartes ARM que l'on voi couramment, mais semble nécessiter d'ajuter de la RAM et du stockage type SSD. Je ne connais pas le côt de la carte seule, mais d'après ce que j'ai constaté, en général, ce genre de carte peut approcher voire dépasser la centaine d'euros. Pas sûr que ce soit rentable à côté d'une mini ITX par exemple.

  • # Routeur/serveur/Nas

    Posté par  . Évalué à 7.

    Vraiment très intéressant pour se faire un routeur/serveur/nas.
    Avoir 2 port réseau pour un routeur est parfait
    Avoir 2 port S-ATA + NVMe est parfait pour du raid.

    A voir le prix maintenant mais ça pourrait avantageusement remplacer mon Soekris qui a du mal a tenir la charge du VPN.

    • [^] # Re: Routeur/serveur/Nas

      Posté par  . Évalué à 0. Dernière modification le 20 novembre 2018 à 13:54.

      Vraiment très intéressant pour se faire un routeur/serveur/nas.

      Pour un routeur: à voir de la compatibilité des logiciels (on est pas aussi bien loti chez hardkernel que chez RPI *1).

      *1 : Pas d'openwrt pour hardkernel par exemple, on est toujours sur ubuntu 16.04 (en 2018…, j'espère qu'ils vont quand même sortir de nouvelles moutures). Sans compter les soucis interne (genre geoip qui nécessite de recompiler le kernel si on veut l'utiliser avec iptables)

      Par contre en voyant toutes ces cartes, je ne vois pas comment les routeurs (les vrai) peuvent continuer d'être vendu avec de vulgaire dualcore.

      • [^] # Re: Routeur/serveur/Nas

        Posté par  . Évalué à 3.

        C'est un x86_64 ici, pas de problème de compatibilité.

      • [^] # Re: Routeur/serveur/Nas

        Posté par  . Évalué à 3.

        on est toujours sur ubuntu 16.04
        Mon HC2 et C2 utilisent tout deux des images officielles en 18.04.

      • [^] # Re: Routeur/serveur/Nas

        Posté par  . Évalué à 7.

        Par contre en voyant toutes ces cartes, je ne vois pas comment les routeurs (les vrai) peuvent continuer d'être vendu avec de vulgaire dualcore.

        Ben parce que leurs specs permettent de faire ce pourquoi ils sont vendus. Sur des séries à des millions d'exemplaires, chaque dollar de gagné sur les appros est un dollar dans la popoche.
        C'est la base du commerce.

        • [^] # Re: Routeur/serveur/Nas

          Posté par  . Évalué à -3.

          Pour les routeurs grand publique je comprend, mais pour les routeurs VPN c'est fort limitant en BP.

  • # Pas mal

    Posté par  (site web personnel) . Évalué à 7. Dernière modification le 19 novembre 2018 à 16:57.

    Pas mal mais à voir l'intérêt par rapport à une mini-ITX.

    J'ai récemment acheté une mini-ITX avec deux ports réseaux, 4 ports sata, 2 ports SODIMM, avec le même cpu en plus pêchu pour 90€…

    Edit : je dois avouer par contre que l'intérêt est pas mal de ne pas se trimbaler une alim ATX…

    • [^] # Re: Pas mal

      Posté par  . Évalué à 6.

      Ca m'intéresse !
      Quel modèle est-ce ?

      • [^] # Re: Pas mal

        Posté par  (site web personnel) . Évalué à 1.

        c'est la GA-J3455-D3H. Sur Amazon ;)
        My mistake c'est un 3455 et pas un J4xxx.

        Cela dit franchement elle tourne du tonnerre sous debian.

    • [^] # Re: Pas mal

      Posté par  (site web personnel) . Évalué à 6. Dernière modification le 19 novembre 2018 à 19:44.

      intérêt est pas mal de ne pas se trimbaler une alim ATX

      Il existe des adaptateurs qui permettent d'utiliser une alim continue normale et d'envoyer ça vers le connecteur ATX (cf "Pico ATX PSU" dans un moteur de recherche).

      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

      • [^] # Re: Pas mal

        Posté par  . Évalué à 4.

        il y a aussi des cartes au format thin mini ITX qui incluent directement les convertisseurs de tension d'une picoATX et donc n'exigent qu'une alim d'ordi portable.

      • [^] # Re: Pas mal

        Posté par  (site web personnel) . Évalué à 1.

        hummm ça ça m'intéresse !

        Merci je vais regarder ça de ce pas..

    • [^] # Re: Pas mal

      Posté par  . Évalué à 1.

      Ouais, enfin, en même temps, un (ou plusieurs) transfo USB ou une alim d'ordi portable, si il faut alimenter 4 disques en SATA, ça risque de ne pas arranger les disques et de ne pas suivre (multiplier les alims USB, ça réduit carrément le rendement, par rapport à une bonne alim ATX.

  • # Kernel upstream ? UEFI ?

    Posté par  . Évalué à 6.

    La seule chose qui pourrait retenir mon attention serait l'implémentation d'un BIOS ou UEFI standard, et la prise en charge du kernel Linux upstream.

    Parce que le défaut majeur des bidules en ARM c'est quand même la spécificité. Lorsque le fabricant décide d'abandonner ton système, tu es fichu et tu ne peux plus jamais mettre à jour.

    • [^] # Re: Kernel upstream ? UEFI ?

      Posté par  . Évalué à 2.

      Parce que le défaut majeur des bidules en ARM c'est quand même la spécificité. Lorsque le fabricant décide d'abandonner ton système, tu es fichu et tu ne peux plus jamais mettre à jour.

      J'ai un peu de mal à comprendre. Quel(s) fabricant(s)? Tu pourrais développer?

      • [^] # Re: Kernel upstream ? UEFI ?

        Posté par  . Évalué à 8.

        Justement, Hard kernel par exemple, j'ai un XU2 de 2012, je te mets au défi d'installer une distribution récente. C'est probablement pas impossible mais y'a juste plus de communauté existante.

        Pareil, j'ai du matos Calxeda, la boîte a fait faillite, le dernier kernel fonctionnel est un paquet pour ubuntu de juin 2013 dans un PPA.

        • [^] # Re: Kernel upstream ? UEFI ?

          Posté par  (site web personnel) . Évalué à 2.

          Pour Xu2, la dernière image date d'août 2018.

          • Ubuntu 16.04.5
          • Kernel 3.4.106
          • Kodi 17.6 Krypton + MFC hw video acceleration
          • Plex Media Server 1.13.0

          Le problème vient de la communauté/des utilisateurs. Si il n'y plus personne pour s'en occuper, cela s’arrête de mort naturelle, comme sur PC. Les cartes ARM ont juste un développement plus rapide et donc un cycle de vie plus court.

          Hardkernel ne peut maintenir tout les kernels/distributions à vie. Mais ils semblent ouvert :

          Lien

          Pour l'Xu3/4 et ses descendants, ils fournissent tout, même de quoi se faire un uboot signé.

          • [^] # Re: Kernel upstream ? UEFI ?

            Posté par  . Évalué à 2.

            Ca me gêne beaucoup d'utiliser une image système pas signée venant d'un utilisateur non identifié sur un forum… C'est mieux que rien…

        • [^] # Re: Kernel upstream ? UEFI ?

          Posté par  . Évalué à 2.

          Exact. Concernant Arch Linux Arm, on trouve du récent pour xu, xu3 et xu4 mais rien pour xu2.

          • [^] # Re: Kernel upstream ? UEFI ?

            Posté par  . Évalué à 3.

            Et c'est pas parce que ces images archlinux sont générées automatiquement qu'elles sont testées et fonctionnelles.

            • [^] # Re: Kernel upstream ? UEFI ?

              Posté par  . Évalué à 2. Dernière modification le 20 novembre 2018 à 17:54.

              Personnellement, avant de critiquer, je teste et si il y a un souci, je poste un rapport de bug… :)

              • [^] # Re: Kernel upstream ? UEFI ?

                Posté par  . Évalué à 3.

                Je veux pas être négatif, mais j'ai testé plein de choses il y a quelques mois (y compris archlinux arm que j'ai utilisé très longtemps sur d'autres board), ça fonctionnait pas convenablement, j'ai pas réussi à contourner les bugs, j'ai pas reporté parce que :

                • il n'y a plus de communauté pour travailler dessus
                • au travail, je peux pas passer 2 jours sur une vieille carte ARM à 60€, 3 heures max. Si ça fonctionne pas, je prends la machine suivante dans le stock…

                • [^] # Re: Kernel upstream ? UEFI ?

                  Posté par  . Évalué à 1.

                  quels types de bug ?

                  J'utilise différentes cartes ARM (de l'Allwinner et du Rockchip, dont un netbook), avec Archlinux ARM, ça boot sans problème, la majorité marche sans problème, les pilotes gpu, pour accélération 3d libre il faut les compiler soi même pour le moment par contre (GPU ARM dans les 2 cas). Je préfère sans acceleration 3d que le blob proposé. Ce qui impose aussi le noyau imposé, plutôt qu'un mainline standard.

      • [^] # Re: Kernel upstream ? UEFI ?

        Posté par  . Évalué à 6.

        Tous les smartphones et tablettes, par exemple.

        • [^] # Re: Kernel upstream ? UEFI ?

          Posté par  . Évalué à 1.

          On parlait de SBC ici, pas de smartphones (contrainte des chip 3G et vidéo pas très ouverts sur ceux-ci).

    • [^] # Re: Kernel upstream ? UEFI ?

      Posté par  . Évalué à 3.

      Les broadcom type raspberry, les allwinner, l'imx6 freescale, les amlogic, les rcar renesas ont des supports mainline plutôt correct (avec ou sans blob proprio côté GPU suivant les modèles). Après c'est pas forcément "distribution ready", connaître yocto est un plus. En tout cas la "balkanisation" des architectes Arm c'est vraiment améliorer ces 5 dernière années (device tree vs board config, mainlining plus présent, progrès sur les stack graphique, standart v4l2 etc…)

      • [^] # Re: Kernel upstream ? UEFI ?

        Posté par  . Évalué à 0.

        Pour les allwinners, il y a encore beaucoup de points à couvrir dans la todolist.
        Mon expérience avec le CubieTruck (allwinner A20/mali 400), c'est qu'on peut faire une croix sur la lecture de vidéos, le support de l'audio sur la sortie SPDIF est enfin devenu fonctionnel avec linux 4.19 et le pilote infrarouge n'a pas plus d'un an si mes souvenirs sont exacts. Donc pour une utilisation multimédia, c'est très très bof.
        Et encore, on a de la chance d'avoir encore des experts qui travaillent sur le support d'une plateforme vieille de 6 ans.

        • [^] # Re: Kernel upstream ? UEFI ?

          Posté par  . Évalué à 3.

          Après NXP, Allwinner est quand même le fabricant en meilleure posture pour le multimédia en mainline (enfin, si on ne prend pas un modèle avec GPU PowerVR). C'est sûr que moi aussi mon expérience avec une Cubieboard2 m'a laissé un peu d'amertume (en plus armbian a lâché le support de pas mal de SBC en A20 cette année) mais les choses s'améliorent avec Cedrus et le travail sur la génération H3 H5 avance bien plus rapidement maintenant que linux-sunxi s'est bien étoffé. Aussi, Lima et Panfrost sont bien (re)partis et vont faire beaucoup progresser l'utilisabilité de tous les SoC avec GPU Mali.

    • [^] # Re: Kernel upstream ? UEFI ?

      Posté par  (site web personnel) . Évalué à 0.

      Niveau BIOS∕UEFI Il y a de l'espoir.

  • # x86_64

    Posté par  (site web personnel) . Évalué à 5.

    J'ai vérifié, le processeur est un x86_64 d'après ce que j'ai compris. Parce que bon, x86 c'est assez puissant pour faire plein de choses, mais ça commence quand même à devenir déprécié (de moins en moins de distributions le supporte entièrement)

    Un LUG en Lorraine : https://enunclic-cappel.fr

  • # Io

    Posté par  (site web personnel) . Évalué à 5.

    C'est sympa ces cartes, mais il manque toujours un paquet d'IO simple pour manipuler des actionneurs : quelques PWM pour faire des sorties de commande moteur et quelques ADC (convertisseurs analogiques numériques) pour les entrées. Rajouter cela à ce genre de carte peut être compliqué, souvent si des modules externes existent les latences étaient toutes pourris.

    "La première sécurité est la liberté"

    • [^] # Re: Io

      Posté par  . Évalué à 4.

      Je pense pas que ce soit la vocation de ce type de carte. Perso, je la vois plus en routeur et/ou NAS.
      Ca reste difficile de concevoir des cartes pour satisfaire tout les besoins …
      Ce que tu décris, c'est plus une application "industrielle", il existe des boards pour faire ça. Par exemple, en googl-ant "ARM board with ADC", je suis tombé sur ce site:

      https://www.embeddedarm.com/products/category/single-board-computers

      et en particulier cette board:

      https://www.embeddedarm.com/products/TS-7800-V2

      • [^] # Re: Io

        Posté par  (site web personnel) . Évalué à 4.

        Le problème d'avoir un Linux à jour est toujours là. Le moindre petit STM32 dispose de plus d'IO que ces cartes ! Mais on ne mets pas de Linux sur un STM32 :/

        "La première sécurité est la liberté"

        • [^] # Re: Io

          Posté par  (site web personnel) . Évalué à 3. Dernière modification le 20 novembre 2018 à 14:58.

          Certains essaient… :-)

          Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

      • [^] # Re: Io

        Posté par  . Évalué à 0. Dernière modification le 20 novembre 2018 à 14:58.

        Pas le même prix non plus, c'est quand même assez cher (tout est relatif). Autant prendre une RaspBerry PI, et programmer en "BareMetal".

        • [^] # Re: Io

          Posté par  (site web personnel) . Évalué à 4.

          Programmer un raspberrypi en baremetal doit être très compliqué. Rien que l'arbre d'horloge doit être super gros à gérer.

          De plus, un RPi n'a pas non plus d'IO ou presque.

          "La première sécurité est la liberté"

          • [^] # Re: Io

            Posté par  . Évalué à 2. Dernière modification le 20 novembre 2018 à 21:44.

            Pour avoir plein d'IOs, faut se tourner vers les cartes Olimex (olinuxino par exemple) ou beagleboard ( beaglebone black est la derniere carte que j'ai essayée mais ils ont sorti d'autres carte s depuis ( j'aimdrais bien en essayer quelues unes).

            De mémoire les beaglebone black ont plein d'ios dont plusieurs entrées analogiques (au moins 3 si je ne me trompe).

  • # Ceph

    Posté par  . Évalué à 3.

    Faudrait calculer (et je le ferais), mais ça serait des chouettes noeuds (OSD) Ceph pour un usage domestique/homelab ça. En tous cas plus que les habituels SBC (même si y'a des tarés qui font du Ceph sur Rpi, c'est clairement pas intéressant niveau perfs).

    • [^] # Re: Ceph

      Posté par  (site web personnel) . Évalué à 2.

      Je ne connaissais pas Ceph
      https://fr.wikipedia.org/wiki/Ceph

      Depuis quelques années, je me dis que ce serait bien de mettre en place deux boitiers (ou plus) chez moi pour stocker mon patrimoine numérique de façon sécurisée (redondance) et aussi un boitier (ou plus) chez un ami, un membre de ma famille (une autre redondance au cas où…).

      Un ami m'avait parlé de SyncThing (logiciel libre qui fait diu P2P) avec des clients pour PC et mobiles.

      Mais j'aime bien mon NextCloud qui m'aide à me dégoogeliser.

      Par contre synchroniser deux instances de NextCloud n'est pas prévu de base il me semble. On pourrait peut-être utiliser BitTorrent Sync ou SyncThing…

      Côté board, j'étais parti vers du Banana Pi ou du ODROID (Hardkernel)…

      Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)

      • [^] # Re: Ceph

        Posté par  . Évalué à 4.

        Depuis quelques années, je me dis que ce serait bien de mettre en place deux boitiers (ou plus) chez moi pour stocker mon patrimoine numérique de façon sécurisée (redondance)

        La redondance "chez toi", c'est un peu inutile: quitte à dupliquer les machines, autant dupliquer les localisations physiques (un incendie, une surtension chez EDF, un cambriolage, et pouf, tes deux machines redondantes disparaissent !)

        Si tu as une connection digne de ce nom, je t'encourage à plutôt t'orienter vers un petit serveur dédié ou un VPS chez un hosteur à pas cher (kimsufi, dédibox…): ce sera plus fiable, utilisable depuis partout et surtout tout compris (hardware, conso elec, …)

        Par contre synchroniser deux instances de NextCloud n'est pas prévu de base il me semble. Nextcloud offre la possibilité de "scaler" sur plusieurs machines:

        https://docs.nextcloud.com/server/9/admin_manual/operations/scaling_multiple_machines.html

        Tu dois donc pouvoir déployer une infra Nextcloud avec des frontaux différents attaquants les mêmes storage engine & co …

        On pourrait peut-être utiliser BitTorrent Sync ou SyncThing…

        Un poil complexe… si tu lis l'article linké ci-dessus, tout n'est pas fichier: tu as un layer storage (facile à synchro à priori) mais tout ce qui est plus du côté de la base de données risque d'être plus complexe à synchroniser …

        Côté board, j'étais parti vers du Banana Pi ou du ODROID (Hardkernel)…

        Ca me parait un poil limitant comme hard… Encore une fois, tu gagnerais à faire tourner ça plutôt sur un serveur dédié …

        • [^] # Re: Ceph

          Posté par  . Évalué à 4.

          La redondance "chez toi", c'est un peu inutile: quitte à dupliquer les machines, autant dupliquer les localisations physiques (un incendie, une surtension chez EDF, un cambriolage, et pouf, tes deux machines redondantes disparaissent !)

          Tout dépend de la taille de "chez toi". Dans une maison, ça peut s'avérer rentable de mettre des noeuds à tous les étages par exemple. Particulièrement si tu vis à la campagne (raison assez valable pour avoir de l'espace), et que ta connexion en intissé te rend l'utilisation d'un VPS pénible.

          Pour le cambriolage, t'es pas obligé de laisser tes nœuds bien visibles : ton réseau est caché dans tes murs, rien n'empêche tes nœuds de se cacher dans les plafonds/planchers. Je vois mal les mecs faire un nmap pour être sûr d'avoir embarqué tous les équipements actifs.

          Pour la surcharge EDF, il n'est pas interdit de protéger ton matériel.

          • [^] # Re: Ceph

            Posté par  (Mastodon) . Évalué à 4.

            oui bon à un moment faut admettre que gérer un cluster ceph à la maison, à moins de le faire à but éducatif/lab, c'est un peu overkill.

            Du coup les perfs c'est pas vraiment le critère numéro 1.

      • [^] # Re: Ceph

        Posté par  . Évalué à 2. Dernière modification le 21 novembre 2018 à 09:28.

        Par contre synchroniser deux instances de NextCloud n'est pas prévu de base il me semble.

        Logique vu que Nextcloud utilise un système fédéré (et donc les fichiers accessible sur l'instance www.popol.com sont aussi accessible sur www.hello.world pour peu que les deux serveurs puissent communiquer et qu'un user de l'un partage avec un user de l'autre).

        Comme tu l'as mentionné, tu peux tester avec Syncthing (tu peux suivre ce tuto pour régler les conflits de permissions entre l'utilisateur www-data et l'utilisateur dédié a ton syncthing).
        Avec ce système si tu modifie un fichier sur une machine, il sera synchronisé avec la seconde machine après une ou deux minutes. Comme les fichiers ne sont pas synchronisés instantanément, il est déconseillé d'utiliser en temps réelle les deux machines, mais plus tôt une seule machine et la seconde sert de backup (au sens load balancing du terme).

        Si tu veux de la Haute Disponibilité alors check du côté de glusterfs (par contre il surconsomme énormément les ressources sur ARM et n'a pas bonne réputation avec les petits fichiers). La haute-disponibilité c'est uniquement si tu as besoin que le service soit encore disponible même si une machine crash.

  • # More d'Intel, d'ARM, vive RISC-V

    Posté par  (site web personnel) . Évalué à -10.

    More d'Intel, d'ARM, vive RISC-V.

    Allons-nous tirer les leçons de Spectre et Meltdown? Je ne crois pas.

  • # D'autres boards X86_64 "puissantes" ?

    Posté par  . Évalué à 1.

    Je ne sais pas si la réponse a été apporté dans les commentaires, je n'ai pas pris le temps de tout lire.

    Je chercherai une board X86_64 assez puissante pour faire tourner des "petits" jeux (typiquement, Hearhstone ou Artifact). Avec la possibilité d'ajouter un module écran tactile et une alim' de type batteries (donc il faut aussi une board qui ne tête pas trop). L'objectif serait de me faire une petite tablette maison tout en continuant à utiliser ma logithèque habituelle.

    La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

    • [^] # Re: D'autres boards X86_64 "puissantes" ?

      Posté par  . Évalué à 2. Dernière modification le 02 janvier 2019 à 11:20.

      Je chercherai une board X86_64 assez puissante
      […]
      donc il faut aussi une board qui ne tête pas trop
      […]

      C'est un peu anti-nomique ton histoire …

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.