BE-IIS-HPP-T1S: UDP-Durchsatz in Abhängigkeit vom SPI-Takt

10BASE-T1S (IEEE 802.3cg) ermöglicht Ethernet-Kommunikation mit 10 Mbit/s über ein einzelnes verdrilltes Adernpaar und unterstützt Multidrop-Netzwerktopologien.

Das BE-IIS-HPP-T1S stellt eine 10BASE-T1S-Schnittstelle für Raspberry-Pi-Systeme auf Basis des Microchip LAN8651 Ethernet MAC-PHY bereit. Der MAC-PHY kommuniziert über SPI mit dem Raspberry Pi.

Dieser Test untersucht, wie sich die angeforderte SPI-Taktfrequenz auf den erreichbaren 10BASE-T1S-UDP-Durchsatz auswirkt.

Es soll nicht nur geprüft werden, ob die Ethernet-Verbindung aufgebaut wird. Ziel ist es, den Punkt zu bestimmen, an dem die SPI-Verbindung zwischen Raspberry Pi und LAN8651 zum Leistungsengpass wird.

Zentrale Merkmale

• 10BASE-T1S-Schnittstelle gemäß IEEE 802.3cg
• Microchip LAN8651 10BASE-T1S MAC-PHY
• Galvanisch getrennte MDI-Schnittstelle
• Raspberry-Pi-HAT+-konform (2024)
• Stapelbares HAT-Design für das BE-IIS-HAT++-Ökosystem
• Konfigurierbare Chip-Select- und IRQ-Zuordnung
• Optionale Unterstützung eines PoSPE-Begleitboards
• Zwei Steckverbinderoptionen
• Linux-Treiber- und Device-Tree-Integration
• Offene Testskripte und reproduzierbarer Aufbau

Testziel

Die Standardkonfiguration des Device Trees für das BE-IIS-HPP-T1S fordert eine SPI-Frequenz von 20 MHz an:

spi-max-frequency = <20000000>;

Für diesen Test wurde die angeforderte Frequenz in Schritten von 1 MHz reduziert:

20 MHz
19 MHz
18 MHz
...
6 MHz
5 MHz

Bei jeder Frequenz übertrug ein Raspberry Pi kontinuierlich UDP-Datenverkehr mit einer iperf3-Sollrate von 10 Mbit/s.

Der zweite Raspberry Pi empfing den Datenverkehr und erfasste:

• Empfangenen Durchsatz
• UDP-Paketverlust
• Jitter
• Anzahl übertragener Pakete
• Anzahl verlorener Pakete
• Angeforderte SPI-Frequenz

Das Ergebnis jedes Testpunkts wurde in eine CSV-Datei geschrieben.

Hardware-Testaufbau

Der Aufbau verwendet:

• 2 × Raspberry-Pi-Systeme
• 2 × BE-IIS-HPP-T1S HATs
• 1 × 10BASE-T1S-Single-Pair-Verbindung
• 1 × separates Managementnetzwerk für die SSH-Steuerung

Jeder Raspberry Pi ist mit einem BE-IIS-HPP-T1S HAT ausgestattet.

Raspberry-Pi-Sender
+ BE-IIS-HPP-T1S
+ T1S-Adresse 10.10.10.1
        |
        | 10BASE-T1S über ein verdrilltes Adernpaar
        |
Raspberry-Pi-Empfänger
+ BE-IIS-HPP-T1S
+ T1S-Adresse 10.10.10.2

Das Managementnetzwerk wird ausschließlich verwendet, um den entfernten iperf3-Client über SSH zu starten.

Der eigentliche Testdatenverkehr wird ausdrücklich über das 10BASE-T1S-Netzwerk von 10.10.10.1 zu 10.10.10.2 gesendet.

Diese Trennung ist wichtig. Die SSH-Verbindung bleibt dadurch verfügbar, selbst wenn die getestete SPI-Frequenz für eine nutzbare T1S-Kommunikation zu niedrig wird.

Software-Testaufbau

Auf beiden Raspberry-Pi-Systemen läuft Raspberry Pi OS 64-Bit mit dem BE-IIS Installer und dem LAN865x-Linux-Treiber.

Die T1S-Schnittstelle des Empfängers steht unter folgendem Namen zur Verfügung:

ifconfig beiis-t1s0

Der Test verwendet folgende Netzwerkkonfiguration:

T1S-Adresse Sender    : 10.10.10.1
T1S-Adresse Empfänger : 10.10.10.2
Schnittstelle         : beiis-t1s0
UDP-Sollrate          : 10 Mbit/s
Messdauer             : 20 Sekunden
Ausgelassene Aufwärmzeit: 3 Sekunden

Automatisierter SPI-Frequenz-Sweep

Ein Testskript automatisiert den größten Teil des Messablaufs.

Für jeden Testpunkt führt das Skript folgende Schritte aus:

1. SPI-Frequenz aus dem aktiven Device Tree lesen
2. Zugehörige Frequenz im Overlay-Quelltext prüfen
3. Entfernten Sender über SSH prüfen
4. Lokalen iperf3-Server starten
5. UDP-Sender auf dem entfernten System starten
6. Empfängerseitiges iperf3-JSON-Ergebnis aufzeichnen
7. Ergebnis an die CSV-Datei anhängen
8. spi-max-frequency um 1 MHz reduzieren
9. Device-Tree-Overlay neu bauen und installieren
10. Vor der nächsten Messung einen Neustart anfordern

Der Neustart stellt sicher, dass der nächste Test die neu installierte Device-Tree-Konfiguration verwendet.

Das Skript wird bewusst als normaler Benutzer gestartet:

./t1s_spi_sweep.sh

Erhöhte Rechte werden nur für die Installation des Overlays angefordert.

Es darf nicht folgendermaßen gestartet werden:

sudo ./t1s_spi_sweep.sh

Würde das vollständige Skript mit sudo ausgeführt, würden Home-Verzeichnis und SSH-Umgebung auf den Benutzer root wechseln.

Beispiel für einen Testzyklus

Bei einer angeforderten Frequenz von 20 MHz liest das Skript:

[INFO] SPI frequency
  Active device tree : 20000000 Hz (20.000 MHz)
  Overlay source     : 20000000 Hz (20.000 MHz)

Anschließend führt es die UDP-Messung durch, schreibt das Ergebnis in die CSV-Datei, ändert den Overlay-Quelltext auf 19 MHz, baut das Overlay neu und fordert einen Neustart an.

Nach dem Neustart wird das Skript für die nächste Frequenz erneut ausgeführt.

Dieser Ablauf wird fortgesetzt, bis die konfigurierte Mindestfrequenz erreicht ist oder die Kommunikation nicht mehr sinnvoll nutzbar ist.

Durchsatzergebnisse

Das folgende Diagramm zeigt den empfängerseitigen UDP-Durchsatz.

Die angeforderte UDP-Datenrate betrug 10 Mbit/s.

Bei angeforderten SPI-Frequenzen von 20 MHz bis hinunter zu 13 MHz maß der Empfänger ungefähr 9,05 bis 9,54 Mbit/s.

Bei 13 MHz lautete das Ergebnis weiterhin:

9,539 Mbit/s empfangen
4,61 % Paketverlust

Bei 12 MHz begann der Durchsatz zu sinken:

8,722 Mbit/s empfangen
12,02 % Paketverlust

Bei 11 MHz und 10 MHz erreichten nur noch etwa 7,1 Mbit/s den Empfänger.

Unterhalb von 10 MHz fiel der Durchsatz stark ab:

9 MHz : 4.013 Mbit/s
8 MHz : 2.759 Mbit/s
7 MHz : 0.204 Mbit/s
6 MHz : 0.016 Mbit/s
5 MHz : 0.001 Mbit/s

Ergebnisse zum Paketverlust

Bei den höheren SPI-Frequenzen wird der verbleibende Paketverlust teilweise durch die gewählte UDP-Sollrate von 10 Mbit/s verursacht.

UDP reduziert seine Übertragungsrate nicht automatisch und überträgt verlorene Pakete nicht erneut. Zusätzlich müssen Ethernet- und Protokoll-Overhead transportiert werden. Eine UDP-Nutzdatenrate von 10 Mbit/s liegt daher nahe an oder oberhalb der praktisch verfügbaren Nutzdatenkapazität einer physikalischen 10-Mbit/s-Verbindung.

Aus diesem Grund sollte der an den besten Testpunkten gemessene Verlust von ungefähr 4,6 % für sich allein nicht als SPI-Begrenzung interpretiert werden.

Wichtiger ist der zusätzliche Verlust, der mit sinkender angeforderter SPI-Frequenz auftritt.

Bei 12 MHz stieg der Paketverlust auf ungefähr 12 %.

Bei 10 MHz und 11 MHz stieg er auf ungefähr 29 %.

Bei 9 MHz gingen ungefähr 60 % der UDP-Pakete verloren.

Bei 7 MHz und darunter gingen nahezu alle Pakete verloren.

Vollständige Messergebnisse

Die vollständige CSV-Datei ist hier verfügbar:

Vollständige CSV-Daten des T1S-SPI-Sweeps herunterladen

Interpretation

Der Test zeigt drei praktische Betriebsbereiche.

13 MHz bis 20 MHz: voller T1S-Durchsatz

In diesem Bereich ist die SPI-Verbindung schnell genug, um nahezu den vollständigen praktisch erreichbaren UDP-Nutzdatendurchsatz der 10BASE-T1S-Verbindung zu unterstützen.

Die gemessenen Ergebnisse verlaufen nicht vollständig monoton. Beispielsweise sind die Messwerte bei 15 MHz, 14 MHz und 13 MHz geringfügig besser als die Werte zwischen 19 MHz und 16 MHz.

Das bedeutet nicht, dass ein niedrigerer angeforderter SPI-Takt grundsätzlich schneller ist.

spi-max-frequency definiert die maximal angeforderte Gerätefrequenz. Der SPI-Controller und der Treiber des Raspberry Pi können nur unterstützte Taktkonfigurationen auswählen und angeforderte Werte gegebenenfalls runden. Der tatsächliche SCLK-Verlauf wurde während dieses Tests nicht gemessen.

Die x-Achse ist daher als maximal angeforderte SPI-Frequenz aus dem Device Tree zu verstehen und nicht als präzise Messung des physikalischen SPI-Takts.

Auch normale Schwankungen zwischen einzelnen Durchläufen können eine einzelne UDP-Messung beeinflussen.

10 MHz bis 12 MHz: SPI wird zum Engpass

Bei 12 MHz beginnt der empfangene Durchsatz unter das praktische T1S-Maximum zu fallen.

Bei 10 MHz und 11 MHz empfängt das System nur noch etwa 7,1 Mbit/s und verliert ungefähr 29 % der Pakete.

In diesem Bereich ist die physikalische T1S-Verbindung weiterhin aktiv. Die SPI-Schnittstelle zwischen Host und MAC-PHY kann die Pakete jedoch nicht mehr schnell genug für den konfigurierten UDP-Datenverkehr mit 10 Mbit/s übertragen.

Unter 10 MHz: starke Durchsatzbegrenzung

Bei 9 MHz fällt der Durchsatz auf etwa 4 Mbit/s.

Bei 8 MHz fällt er unter 3 Mbit/s.

Bei 7 MHz und darunter kann die Verbindung technisch noch eine geringe Anzahl von Paketen übertragen. Für den normalen 10BASE-T1S-Ethernet-Betrieb bei der getesteten Last ist sie jedoch nicht mehr sinnvoll nutzbar.

Der 5-MHz-Test wurde mit ungefähr folgendem Ergebnis abgeschlossen:

0,000571 Mbit/s empfangen
99,995 % Paketverlust

Für die gewählte Last entspricht dies praktisch einem vollständigen Einbruch des Durchsatzes.

Praktisches Ergebnis

Für diesen Hardware- und Softwareaufbau war eine angeforderte SPI-Frequenz von 13 MHz der niedrigste getestete Wert, der noch den vollständigen praktisch erreichbaren 10BASE-T1S-UDP-Durchsatz bereitstellte.

Die Standardeinstellung bleibt:

spi-max-frequency = <20000000>;

Diese Einstellung bietet deutliche Reserve und sollte die normale Konfiguration für Produktion und Evaluierung bleiben.

Das Ergebnis ist für die Systemauslegung dennoch hilfreich. Es zeigt, dass die Standardkonfiguration mit 20 MHz nicht unmittelbar an der beobachteten Durchsatzgrenze arbeitet und die LAN8651-SPI-Verbindung in diesem Aufbau eine messbare Reserve besitzt.

Einschränkungen des Tests

Dieser Test ist eine praxisnahe technische Messung und keine formale Konformitätsprüfung.

Zu den wichtigen Einschränkungen gehören:

• Ein einzelner Hardwareaufbau
• Eine Messung je angeforderter SPI-Frequenz
• Eine UDP-Paketgröße und iperf3-Konfiguration
• Eine Raspberry-Pi-Software- und Kernel-Konfiguration
• Keine Oszilloskopmessung des tatsächlichen SPI-Takts
• Kein Langzeit-Stabilitätstest bei jeder Frequenz
• Keine wiederholte statistische Testreihe
• Keine Variation von Temperatur oder Spannung

Eine detailliertere Charakterisierung könnte jeden Messpunkt mehrfach wiederholen und zusätzlich die physikalische SCLK-Frequenz, CPU-Last, Interrupt-Last und das Timing der SPI-Übertragungen messen.

Fazit

Das BE-IIS-HPP-T1S übertrug nahezu den vollständigen 10BASE-T1S-UDP-Durchsatz, während der angeforderte SPI-Takt von 20 MHz auf 13 MHz reduziert wurde.

Bei 13 MHz maß der Empfänger ungefähr 9,54 Mbit/s. Dies entsprach praktisch dem besten Ergebnis bei der Standardeinstellung von 20 MHz.

Bei 12 MHz begann der Durchsatz zu sinken. Bei 10 MHz und 11 MHz begrenzte die SPI-Schnittstelle den empfangenen Durchsatz auf ungefähr 7,1 Mbit/s. Unterhalb von 10 MHz verschlechterten sich Durchsatz und Paketzustellung schnell.

Der Test zeigt damit einen klaren praktischen Übergang:

13 MHz und mehr : voller praktischer T1S-Durchsatz
10–12 MHz        : zunehmende SPI-Begrenzung
unter 10 MHz     : starke Durchsatzbegrenzung

Die standardmäßige Device-Tree-Konfiguration mit 20 MHz bietet eine sinnvolle Betriebsreserve und bleibt die empfohlene Einstellung.

Der automatisierte Testablauf macht das Ergebnis außerdem reproduzierbar. Änderung, Neubau und Installation des Overlays, die Neustartsequenz, die iperf3-Messung und das CSV-Logging werden von einem transparenten Shell-Skript übernommen, das gemeinsam mit den Produkttestressourcen gespeichert ist.

Links und Referenzen

Produktseite mit Datenblatt, Schaltplan, PCB-Layout, 3D-Daten und Shop-Links: https://www.be-iis.eu/products/BE-IIS-HPP-T1S_B/

BE-IIS Installer und Produktsoftware-Ressourcen: https://github.com/be-iis/be-iis-installer/

Quelltext des SPI-Geschwindigkeits-Sweeps: https://github.com/be-iis/be-iis-installer/tree/main/products/BE-IIS-HPP-T1S-REVB/test/spi-speed-sweep/

DigiKey-Produktseite: https://www.digikey.de/en/products/detail/brechel-electronic-industrial-interface-systems-be-iis/BE-IIS-HPP-T1S/29436902