Tâche manquante pour la migration : régénérer les weights sur la configuration matérielle minimale supportée

elois · 22 February 2026 17:01

Je vois que vous semblez prêts à migrer dans seulement deux semaines. Je regarde donc ce que vous pourriez avoir oublié, et j’ai trouvé un point important :

Sur les branches master et 337-prepare-g1-launch, les poids ont été générés via un run des benchmarks sur la machine de @bgallois, avec un CPU Intel Core i3-12100F.

Cela signifie que tous les nœuds forgerons avec un CPU dont les performances mono-cœur sont sensiblement inférieures à celles du Intel Core i3-12100F échoueront à produire ou importer de nouveaux blocs à temps si ces blocs sont bien remplis. Cela implique une désynchronisation forcée de ces nœuds, et peut même arrêter la blockchain si plus d’un tiers des forgerons ont un CPU insuffisant.

@bgallois avait généré les poids sur sa machine de développement pour pouvoir compiler et merger l’ajout des benchmarks. Cependant, ce qui aurait dû être fait ensuite était de relancer les benchmarks sur une machine correspondant aux spécifications matérielles minimales demandées aux forgerons.

Il me semble qu’à l’époque nous avions défini comme spécification matérielle minimale un Raspberry Pi 4 avec un SSD en USB 3.0. Est-ce toujours le cas ?

Si oui, c’est un problème important, car les performances mono-cœur du CPU d’un Raspberry Pi 4 (Broadcom BCM2711) sont entre 3× et 8× plus faibles, selon le type de benchmark (source Geekbench : Intel Core i3-12100F Benchmarks - Geekbench et
Broadcom BCM2711 - Geekbench).

Cela signifie que si quelqu’un spam le réseau pour remplir les blocs proches de leur capacité maximale, les éventuels forgerons sur RPi 4 seront désynchronisés de force.

Avez-vous testé le spam sur la Ğtest pour vérifier le taux de remplissage des blocs et si tous les forgerons arrivent à suivre ?

Quelle spécification matérielle minimale avez-vous finalement retenue pour les forgerons ?
Quelqu’un peut-il relancer les benchmarks sur une machine correspondant à ces spécifications matérielles minimales ?

Voici les commandes à lancer pour régénérer les poids :

cargo build --release --no-default-features --features runtime-benchmarks,g1

target/release/duniter benchmark storage \
  --dev \
  --mul=2 \
  --weight-path=./runtime/g1/src/weights/ \
  --state-version=1 \
  --database=paritydb \
  --disable-pov-recorder \
  --batch-size=100

target/release/duniter benchmark overhead \
  --chain=dev \
  --wasm-execution=compiled \
  --weight-path=./runtime/g1/src/weights/ \
  --warmup=10 \
  --repeat=100

target/release/duniter benchmark pallet \
  --genesis-builder=spec-genesis \
  --steps=50 \
  --repeat=20 \
  --pallet="" \
  --extrinsic="" \
  --wasm-execution=compiled \
  --heap-pages=4096 \
  --header=./file_header.txt \
  --output=./runtime/g1/src/weights/

poka · 23 February 2026 09:15

Wow, merci @elois d’avoir relevé ça, heureusement que tu es dans le coin !
Est-ce que quelqu’un disposant d’un rpi4 avec disque USB peut s’occuper de lancer ces benchmark sur une nouvelle branche depuis master ?

Il faudrait ne pas tarder de manière à tester ça sur la GTest le plus vite possible.
Je m’occupe de préparer des tests de charge dans la semaine …

cgeek · 23 February 2026 12:54

Yes je m’en occupe.

elois · 23 February 2026 19:30

USB 3.0 précisément, car la vitesse d’accès en lecture est le goulot d’étranglement numéro un pour l’exécution d’un block.

Si les benchmarks sont exécutés avec une connexion USB différente, il faut indiquer la norme USB précise et, idéalement, la spécification technique du câble et du SSD.

Par prudence, il peut être pertinent d’augmenter le multiplicateur appliqué au temps d’accès en lecture retenu à 3 au lieu de 2, par exemple (c’est le paramètre --mul).

Attention, les commandes que j’ai indiquées concernent le runtime g1.

Pour tester sur la Ğtest, il faut également exécuter les benchmarks sur le runtime gtest (ou copier-coller les fichiers générés ; si les deux runtimes sont suffisamment proches, cela reste acceptable).

Attention aux tests de charge naïfs qui peuvent donner l’illusion que le réseau résiste bien au spam, alors que ce n’est pas le cas.

Ce qui importe en priorité, c’est de maximiser les accès en lecture au sein d’un même bloc vers des clés de storage différentes. Il existe un cache : relire plusieurs fois les mêmes clés n’augmente donc pas la charge.

Le scénario de test de charge idéal consiste à créer le plus grand nombre possible de petites transactions, chacune effectuant un simple transfert depuis un compte distinct vers un autre compte distinct.

Je recommande de développer un bot capable de dériver de nombreux comptes à partir d’un trousseau de clés maître. Il suffit ensuite de créditer manuellement une quantité importante de Ğ1 sur le compte maître, puis de laisser le bot diviser le solde par deux à chaque itération :

la moitié vers deux comptes,
puis un quart vers quatre nouveaux comptes,
et ainsi de suite.

Pour maximiser la charge, il est essentiel que tous les comptes émetteurs et destinataires soient uniques et différents à chaque transaction, afin d’augmenter le nombre de clés de storage lues ainsi que le nombre de signatures à vérifier.

Ainsi, la première itération envoie des fonds vers les comptes /1 et /2, qui envoient ensuite vers les comptes /3 à /6, et ainsi de suite.

EDIT: Ne surtout pas utiliser de batch call : cela réduit la charge, car il existe un overhead par transaction (vérification de la signature, vérification du nonce, vérification des quotas/frais, etc.).

aya · 23 February 2026 22:27

J’ai fait l’exercice de mon côté sur un raspi4 8Go RAM 1To NVMe en USB3 avec --mul=3 :

$ grep WEIGHT runtime/g1/src/weights/paritydb_weights.rs
read: 131_118 * constants::WEIGHT_REF_TIME_PER_NANOS,
write: 957_435 * constants::WEIGHT_REF_TIME_PER_NANOS
$ grep WEIGHT runtime/g1/src/weights/extrinsic_weights.rs
Weight::from_parts(WEIGHT_REF_TIME_PER_NANOS.saturating_mul(838_991), 0);

J’ai fait une MR avec tous les fichiers de poids.

le détail des différentes étapes pour info

aya@aynic:~/Sources/duniter-v2s $ target/release/duniter benchmark storage \
  --dev \
  --mul=3 \
  --weight-path=./runtime/g1/src/weights/ \
  --state-version=1 \
  --database=paritydb \
  --disable-pov-recorder \
  --batch-size=100
2026-02-23 22:27:44 Low open file descriptor limit configured for the process. Current value: 4096, recommended value: 10000.
2026-02-23 22:27:57 🔨 Initializing Genesis block/state (state: 0x7560…2259, header-hash: 0x87a5…4a79)
2026-02-23 22:27:57 Creating transaction pool txpool_type=SingleState ready=Limit { count: 8192, total_bytes: 20971520 } future=Limit { count: 512, total_bytes: 1048576 }
2026-02-23 22:27:57 👴 Loading GRANDPA authority set from genesis on what appears to be first startup.
2026-02-23 22:27:57 👶 Creating empty BABE epoch changes on what appears to be first startup.
2026-02-23 22:27:57 Essential task `babe-worker` failed. Shutting down service.
2026-02-23 22:27:57 Warmup round 1/1
2026-02-23 22:27:57 Preparing keys from block 0x87a5…4a79
2026-02-23 22:27:57 Reading 157 keys
2026-02-23 22:27:57 Time summary [ns]:
Total: 6861961
Min: 2185, Max: 6013963
Average: 43706, Median: 5352, Stddev: 478007.55
Percentiles 99th, 95th, 75th: 20740, 8408, 6389
Value size summary:
Total: 5205581
Min: 1, Max: 5201710
Average: 33156, Median: 12, Stddev: 413815.46
Percentiles 99th, 95th, 75th: 241, 128, 33
2026-02-23 22:27:57 Warmup round 1/1
2026-02-23 22:27:57 Preparing keys from block 0x87a5…4a79
2026-02-23 22:27:57 Writing 157 keys in batches of 100
2026-02-23 22:27:57 Time summary [ns]:
Total: 319145
Min: 319145, Max: 319145
Average: 319145, Median: 319145, Stddev: 0
Percentiles 99th, 95th, 75th: 319145, 319145, 319145
Value size summary:
Total: 52040
Min: 52040, Max: 52040
Average: 52040, Median: 52040, Stddev: 0
Percentiles 99th, 95th, 75th: 52040, 52040, 52040
2026-02-23 22:27:57 Writing weights to "/home/aya/Sources/duniter-v2s/runtime/g1/src/weights/paritydb_weights.rs"
aya@aynic:~/Sources/duniter-v2s $ target/release/duniter benchmark overhead \
  --chain=dev \
  --wasm-execution=compiled \
  --weight-path=./runtime/g1/src/weights/ \
  --warmup=10 \
  --repeat=100
2026-02-23 22:29:07 Low open file descriptor limit configured for the process. Current value: 4096, recommended value: 10000.
2026-02-23 22:29:20 🔨 Initializing Genesis block/state (state: 0x7560…2259, header-hash: 0x87a5…4a79)
2026-02-23 22:29:20 Creating transaction pool txpool_type=SingleState ready=Limit { count: 8192, total_bytes: 20971520 } future=Limit { count: 512, total_bytes: 1048576 }
2026-02-23 22:29:20 👴 Loading GRANDPA authority set from genesis on what appears to be first startup.
2026-02-23 22:29:21 👶 Creating empty BABE epoch changes on what appears to be first startup.
2026-02-23 22:29:21 Essential task `babe-worker` failed. Shutting down service.
2026-02-23 22:29:21 Running 10 warmups...
2026-02-23 22:29:21 Executing block 100 times
2026-02-23 22:29:21 Per-block execution overhead [ns]:
Total: 114159483
Min: 1085352, Max: 1776370
Average: 1141594, Median: 1110481, Stddev: 110220.45
Percentiles 99th, 95th, 75th: 1631018, 1288797, 1135000
2026-02-23 22:29:21 Writing weights to "/home/aya/Sources/duniter-v2s/runtime/g1/src/weights/block_weights.rs"
2026-02-23 22:29:21 Running 10 warmups...
2026-02-23 22:29:21 Executing block 100 times
2026-02-23 22:29:21 Building block, this takes some time...
2026-02-23 22:29:32 Extrinsics per block: 2458
2026-02-23 22:29:32 Running 10 warmups...
2026-02-23 22:29:53 Executing block 100 times
2026-02-23 22:33:22 Per-extrinsic execution overhead [ns]:
Total: 83899164
Min: 831123, Max: 865553
Average: 838991, Median: 837738, Stddev: 5422.74
Percentiles 99th, 95th, 75th: 863711, 850807, 839853
2026-02-23 22:33:22 Writing weights to "/home/aya/Sources/duniter-v2s/runtime/g1/src/weights/extrinsic_weights.rs"
aya@aynic:~/Sources/duniter-v2s $ target/release/duniter benchmark pallet --genesis-builder=spec-genesis --steps=50 --repeat=20 --pallet="*" --extrinsic="*" --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/g1/src/weights/

les infos cpu

# cat /proc/cpuinfo
processor       : 0
BogoMIPS        : 108.00
Features        : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd08
CPU revision    : 3

processor       : 1
BogoMIPS        : 108.00
Features        : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd08
CPU revision    : 3

processor       : 2
BogoMIPS        : 108.00
Features        : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd08
CPU revision    : 3

processor       : 3
BogoMIPS        : 108.00
Features        : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd08
CPU revision    : 3

les infos du disque dur

# hdparm -I /dev/sda
/dev/sda:

ATA device, with non-removable media
        Model Number:       Samsung SSD 860 EVO M.2 1TB
        Serial Number:      XXXXXXXXXXXXXXX
        Firmware Revision:  RVT24B6Q
        Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
        Used: unknown (minor revision code 0x005e)
        Supported: 11 8 7 6 5
        Likely used: 11
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:    16514064
        LBA    user addressable sectors:   268435455
        LBA48  user addressable sectors:  1953525168
        Logical  Sector size:                   512 bytes
        Physical Sector size:                   512 bytes
        Logical Sector-0 offset:                  0 bytes
        device size with M = 1024*1024:      953869 MBytes
        device size with M = 1000*1000:     1000204 MBytes (1000 GB)
        cache/buffer size  = unknown
        Form Factor: unknown (0x0007]
        Nominal Media Rotation Rate: Solid State Device
Capabilities:
        LBA, IORDY(can be disabled)
        Queue depth: 32
        Standby timer values: spec'd by Standard, no device specific minimum
        R/W multiple sector transfer: Max = 1   Current = 1
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    SMART feature set
                Security Mode feature set
           *    Power Management feature set
           *    Write cache
           *    Look-ahead
           *    Host Protected Area feature set
           *    WRITE_BUFFER command
           *    READ_BUFFER command
           *    NOP cmd
           *    DOWNLOAD_MICROCODE
                SET_MAX security extension
           *    48-bit Address feature set
           *    Device Configuration Overlay feature set
           *    Mandatory FLUSH_CACHE
           *    FLUSH_CACHE_EXT
           *    SMART error logging
           *    SMART self-test
           *    General Purpose Logging feature set
           *    WRITE_{DMA|MULTIPLE}_FUA_EXT
           *    64-bit World wide name
                Write-Read-Verify feature set
           *    WRITE_UNCORRECTABLE_EXT command
           *    {READ,WRITE}_DMA_EXT_GPL commands
           *    Segmented DOWNLOAD_MICROCODE
           *    Gen1 signaling speed (1.5Gb/s)
           *    Gen2 signaling speed (3.0Gb/s)
           *    Gen3 signaling speed (6.0Gb/s)
           *    Native Command Queueing (NCQ)
           *    Phy event counters
           *    READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
                DMA Setup Auto-Activate optimization
                Device-initiated interface power management
           *    Asynchronous notification (eg. media change)
           *    Software settings preservation
                Device Sleep (DEVSLP)
           *    SMART Command Transport (SCT) feature set
           *    SCT Write Same (AC2)
           *    SCT Error Recovery Control (AC3)
           *    SCT Features Control (AC4)
           *    SCT Data Tables (AC5)
           *    Device encrypts all user data
           *    DOWNLOAD MICROCODE DMA command
           *    SET MAX SETPASSWORD/UNLOCK DMA commands
           *    WRITE BUFFER DMA command
           *    READ BUFFER DMA command
           *    Data Set Management TRIM supported (limit 8 blocks)
           *    Deterministic read ZEROs after TRIM
# smartctl -a /dev/sda
smartctl 7.4 2023-08-01 r5530 [aarch64-linux-6.12.69+deb13-arm64] (local build)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Samsung based SSDs
Device Model:     Samsung SSD 860 EVO M.2 1TB
Serial Number:    XXXXXXXXXXXXXX
LU WWN Device Id: 0 000000 000000000
Firmware Version: RVT24B6Q
User Capacity:    1 000 204 886 016 bytes [1,00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      M.2
TRIM Command:     Available, deterministic, zeroed
Device is:        In smartctl database 7.3/5528
ATA Version is:   ACS-4 T13/BSR INCITS 529 revision 5
SATA Version is:  SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Mon Feb 23 21:06:39 2026 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

les infos usb

# lspci -v
00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2711 PCIe Bridge (rev 10) (prog-if 00 [Normal decode])
        Device tree node: /sys/firmware/devicetree/base/scb/pcie@7d500000/pci@0,0
        Flags: bus master, fast devsel, latency 0, IRQ 19
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        Memory behind bridge: 00000000-000fffff [size=1M] [32-bit]
        Prefetchable memory behind bridge: [disabled] [64-bit]
        Capabilities: [48] Power Management version 3
        Capabilities: [ac] Express Root Port (Slot-), IntMsgNum 0
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [180] Vendor Specific Information: ID=0000 Rev=0 Len=028 <?>
        Capabilities: [240] L1 PM Substates
        Kernel driver in use: pcieport

01:00.0 USB controller: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 Controller (rev 01) (prog-if 30 [XHCI])
        Subsystem: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 Controller
        Device tree node: /sys/firmware/devicetree/base/scb/pcie@7d500000/pci@0,0/usb@0,0
        Flags: bus master, fast devsel, latency 0, IRQ 38
        Memory at 600000000 (64-bit, non-prefetchable) [size=4K]
        Capabilities: [80] Power Management version 3
        Capabilities: [90] MSI: Enable+ Count=4/4 Maskable- 64bit+
        Capabilities: [c4] Express Endpoint, IntMsgNum 0
        Capabilities: [100] Advanced Error Reporting
        Kernel driver in use: xhci_hcd
        Kernel modules: xhci_pci

les infos hardware

# lshw
    description: Computer
    produit: Raspberry Pi 4 Model B Rev 1.4
    numéro de série: 0000000000000000
    bits: 64 bits
    fonctionnalités: smp cp15_barrier setend swp tagged_addr_disabled
  *-core
       description: Motherboard
       identifiant matériel: 0
     *-cpu:0
          description: CPU
          produit: cpu
          identifiant matériel: 1
          information bus: cpu@0
          taille: 1500MHz
          capacité: 1500MHz
          fonctionnalités: fp asimd evtstrm crc32 cpuid cpufreq
        *-cache
             description: L1 Cache
             identifiant matériel: 0
             taille: 32KiB
     *-cpu:1
          description: CPU
          produit: cpu
          identifiant matériel: 2
          information bus: cpu@1
          taille: 1500MHz
          capacité: 1500MHz
          fonctionnalités: fp asimd evtstrm crc32 cpuid cpufreq
        *-cache
             description: L1 Cache
             identifiant matériel: 0
             taille: 32KiB
     *-cpu:2
          description: CPU
          produit: cpu
          identifiant matériel: 3
          information bus: cpu@2
          taille: 1500MHz
          capacité: 1500MHz
          fonctionnalités: fp asimd evtstrm crc32 cpuid cpufreq
        *-cache
             description: L1 Cache
             identifiant matériel: 0
             taille: 32KiB
     *-cpu:3
          description: CPU
          produit: cpu
          identifiant matériel: 4
          information bus: cpu@3
          taille: 1500MHz
          capacité: 1500MHz
          fonctionnalités: fp asimd evtstrm crc32 cpuid cpufreq
        *-cache
             description: L1 Cache
             identifiant matériel: 0
             taille: 32KiB
     *-cpu:4 DÉSACTIVÉ
          description: CPU
          produit: l2-cache0
          identifiant matériel: 5
          information bus: cpu@4
     *-memory
          description: Mémoire système
          identifiant matériel: 6
          taille: 8GiB
     *-pci
          description: PCI bridge
          produit: BCM2711 PCIe Bridge
          fabriquant: Broadcom Inc. and subsidiaries
          identifiant matériel: 0
          information bus: pci@0000:00:00.0
          version: 10
          bits: 32 bits
          horloge: 33MHz
          fonctionnalités: pci pm pciexpress normal_decode bus_master cap_list
          configuration: driver=pcieport
          ressources: irq:19 mémoire:600000000-6000fffff
        *-usb
             description: USB controller
             produit: VL805/806 xHCI USB 3.0 Controller
             fabriquant: VIA Technologies, Inc.
             identifiant matériel: 0
             information bus: pci@0000:01:00.0
             version: 01
             bits: 64 bits
             horloge: 33MHz
             fonctionnalités: pm msi pciexpress xhci bus_master cap_list
             configuration: driver=xhci_hcd latency=0
             ressources: irq:38 mémoire:600000000-600000fff
     *-scsi
          identifiant matériel: 7
          information bus: usb@2:2
          nom logique: scsi0
        *-disk
             description: SCSI Disk
             produit: Forty
             fabriquant: Argon
             identifiant matériel: 0.0.0
             information bus: scsi@0:0.0.0
             nom logique: /dev/sda
             version: 0
             numéro de série: 000000000000
             taille: 931GiB (1TB)
             fonctionnalités: partitioned partitioned:dos
             configuration: ansiversion=6 logicalsectorsize=512 sectorsize=512 signature=xxxxxxxx
           *-volume:0
                description: Windows FAT volume
                fabriquant: mkfs.fat
                identifiant matériel: 1
                information bus: scsi@0:0.0.0,1
                nom logique: /dev/sda1
                nom logique: /boot/firmware
                version: FAT32
                numéro de série: xxxx-xxxx
                taille: 255MiB
                capacité: 256MiB
                fonctionnalités: primary fat initialized
                configuration: FATs=2 filesystem=fat label=boot mount.fstype=vfat mount.options=rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro state=mounted
           *-volume:1
                description: EXT4 volume
                fabriquant: Linux
                identifiant matériel: 2
                information bus: scsi@0:0.0.0,2
                nom logique: /dev/sda2
                nom logique: /
                version: 1.0
                numéro de série: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx
                taille: 931GiB
                capacité: 931GiB
                fonctionnalités: primary journaled extended_attributes large_files dir_nlink recover extents ext4 ext2 initialized
                configuration: created=2021-05-07 18:13:17 filesystem=ext4 label=rootfs lastmountpoint=/root modified=2026-02-23 19:22:25 mount.fstype=ext4 mount.options=rw,noatime mounted=1970-01-01 01:00:07 state=mounted
  *-mmc0
       description: MMC Host
       identifiant matériel: 1
       nom logique: mmc0
     *-device
          description: SDIO Device
          identifiant matériel: 1
          information bus: mmc@0:0001
          numéro de série: 0
          fonctionnalités: sdio
        *-interface:0
             produit: 43430
             fabriquant: Broadcom
             identifiant matériel: 1
             information bus: mmc@0:0001:1
             nom logique: mmc0:0001:1
        *-interface:1
             produit: 43430
             fabriquant: Broadcom
             identifiant matériel: 2
             information bus: mmc@0:0001:2
             nom logique: mmc0:0001:2
        *-bt
             description: BlueTooth interface
             produit: 43430
             fabriquant: Broadcom
             identifiant matériel: 3
             information bus: mmc@0:0001:3
             nom logique: mmc0:0001:3
             fonctionnalités: wireless bluetooth
             configuration: wireless=BlueTooth
  *-mmc1
       description: MMC Host
       identifiant matériel: 2
       nom logique: mmc1
  *-sound:0
       description: Headphones
       identifiant matériel: 3
       nom logique: card0
       nom logique: /dev/snd/controlC0
       nom logique: /dev/snd/pcmC0D0p
  *-sound:1
       description: vc4hdmi0
       identifiant matériel: 4
       nom logique: card1
       nom logique: /dev/snd/controlC1
       nom logique: /dev/snd/pcmC1D0p
  *-sound:2
       description: vc4hdmi1
       identifiant matériel: 5
       nom logique: card2
       nom logique: /dev/snd/controlC2
       nom logique: /dev/snd/pcmC2D0p
  *-input:0
       produit: vc4-hdmi-0
       identifiant matériel: 6
       nom logique: input0
       nom logique: /dev/input/event0
       fonctionnalités: cec
  *-input:1
       produit: vc4-hdmi-1
       identifiant matériel: 7
       nom logique: input1
       nom logique: /dev/input/event1
       fonctionnalités: cec
  *-network
       description: Ethernet interface
       identifiant matériel: 8
       nom logique: eth0
       numéro de série: xx:xx:xx:xx:xx:xx
       taille: 1Gbit/s
       capacité: 1Gbit/s
       fonctionnalités: ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=bcmgenet driverversion=x.xx.xx-arm64 duplex=full ip=xxx.xxx.xxx.xxx link=yes multicast=yes port=twisted pair speed=1Gbit/s

cgeek · 24 February 2026 06:58

Ah bah tant mieux, car j’en étais à une erreur d’allocation mémoire pour le runtime. Ceci dit ce serait intéressant que j’essaye d’aller au bout quand même.

poka · 24 February 2026 11:35

elois:

Ce qui importe en priorité, c’est de maximiser les accès en lecture au sein d’un même bloc vers des clés de storage différentes. Il existe un cache : relire plusieurs fois les mêmes clés n’augmente donc pas la charge.

Le scénario de test de charge idéal consiste à créer le plus grand nombre possible de petites transactions, chacune effectuant un simple transfert depuis un compte distinct vers un autre compte distinct.

Je recommande de développer un bot capable de dériver de nombreux comptes à partir d’un trousseau de clés maître. Il suffit ensuite de créditer manuellement une quantité importante de Ğ1 sur le compte maître, puis de laisser le bot diviser le solde par deux à chaque itération :

la moitié vers deux comptes,

puis un quart vers quatre nouveaux comptes,

et ainsi de suite.

C’est exactement ce que j’avais en tête, là dessus, je pense pouvoir me débrouiller ><

Mais n’existerait-il pas des outils de pen test / test de charge pour Substrate développé par Polkadot ou autre ? Est-ce que tu pourrais te renseigner autour de toi à ce sujet ?

Dernière question concernant les tests de charge, est-ce que tu penses qu’il suffit de tester des transfers de monnaie, ou bien aussi des choses plus spécifiques à Duniter comme des certifications ?

poka · 24 February 2026 11:37

Je pense que la lecture de ce topic devrait grandement t’intéresser du coup: Cannot allocate memory (os error 12) sur raspberry

Un peu de lecture, mais je pense que l’ensemble du déroulé de la discussion est intéressante à connaitre.

cgeek · 24 February 2026 11:40

Tout à fait, je l’ai lue religieusement. Je devrais bientôt aboutir, c’est juste que la compilation sur un Raspberry PI est … un peu moins rapide que sur mes machines habituelles

poka · 24 February 2026 11:45

Du coup je le précise au cas où, mais compiler Duniter avec l’option --wasmtime-instantiation-strategy recreate-instance-copy-on-write n’a pas réglé le problème sur le long terme, il faut bien finalement suivre la procédure donné par aya en dernier message du thread.

cgeek · 24 February 2026 11:54

Oui, j’ai dû changer de distribution. Là je suis sur une Ubuntu :

cat /boot/config-$(uname -r) | grep VA_BITS
# CONFIG_ARM64_VA_BITS_39 is not set
CONFIG_ARM64_VA_BITS_48=y
# CONFIG_ARM64_VA_BITS_52 is not set
CONFIG_ARM64_VA_BITS=48

cgeek · 24 February 2026 17:26

J’ai approuvé après avoir commenté la MR. On peut merger ta branche selon moi, j’ai des résultats similaires (c’est très légèrement plus lent sur mon raspi), en tous les cas sans commune mesure avec la machine de bgallois.

elois · 24 February 2026 18:48

Merci beaucoup @aya pour la régénération des poids. Peux-tu ajouter à ta PR un fichier Markdown qui détaille les spécifications hardware utilisées et la date, avec un nom du style benchmarks_runs.md à la racine du dépôt ?

Je n’ai pas d’informations là-dessus. Au travail, nous avons développé notre propre code pour nos tests de charge, mais il n’est pas utilisé pour Duniter, car il envoie des transactions Ethereum.

Tester les transferts de monnaie suffit. Ce qui compte, c’est de remplir les blocs avec beaucoup d’accès au storage et de travail CPU, comme la vérification de signatures ; la nature des calls exécutés importe peu.

EDIT: @aya on a aussi besoin de mettre à jour les weights pour le runtime gtest afin de pouvoir tester sur la gtest. Peux-tu copier-coller les fichiers générés dans le dossier runtime/gtest/src/weights ?

aya · 24 February 2026 23:06

C’est fait, j’ai mis à jour les poids de la gtest et ajouté un fichier BENCHMARK.md.

elois · 25 February 2026 17:44

Merci @aya, je viens d’approuver et de merger ta MR. Lors de ma review, j’ai constaté au moins un problème avec les benchmarks ainsi qu’une discrepancy au niveau des ProxyType entre gtest et g1, mais je vais ouvrir des issues GitLab dédiées afin que l’on corrige cela dans de futures MRs.

elois · 25 February 2026 21:10

@poka stp attends avant de relancer une gtest avec les nouveaux poids, car j’ai détecté plusieurs erreurs importantes dans les scénarios des benchmarks qu’on doit d’abord corriger.

J’ai créé une issue qui explique en détail les problèmes : https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/346

poka · 25 February 2026 21:20

Pas de soucis, de toute façon je pense qu’on ne va pas relancer de gtest mais simplement faire un runtime upgrade pour s’entrainer.
Je vais suivre vos issues et MR et j’attends le go.

elois · 26 February 2026 16:33

J’ai ouvert une MR pour corriger plusieurs erreurs dans les benchmarks:

@cgeek @aya Est-ce que l’un d’entre vous peut régénérer les poids sur ma branche 346-benchmark-scenario-coverage-gaps pour les 4 pallets concernées ?

Si les différences de poids sont importantes, notamment pour la pallet quota, alors nous devons inclure ces changements avant la migration. En revanche, si les différences sont négligeables, cela peut attendre.

Vous pouvez utiliser le script bash suivant pour régénérer uniquement les poids nécessaires :

for chain in g1 gtest; do
  cargo build --release --no-default-features --features runtime-benchmarks,$chain
  for pallet in pallet_authority_members pallet_identity pallet_quota pallet_smith_members; do
    target/release/duniter benchmark pallet \
      --genesis-builder=spec-genesis \
      --steps=50 \
      --repeat=20 \
      --pallet="$pallet" \
      --extrinsic="*" \
      --wasm-execution=compiled \
      --heap-pages=4096 \
      --header=./file_header.txt \
      --output="./runtime/$chain/src/weights/"
  done
done

cgeek · 26 February 2026 17:33

@aya stp car sur ma machine ça n’a pas aussi bien marché que la tienne.

aya · 26 February 2026 20:33

C’est push.