Brainstorming Future of FESA Realtime

1 Ist-Zustand

• Versorgung der FGs benötigt länger als gewünscht.
• Interrupthandling in SAFTlib ist ineffizient.
• D-Bus ist langsamer als für unseren Anwendungsfall notwendig.
• Bemerkungen Dietrich
  • Vergleich Aepfel mit Birnen
    • Zahl der Events
      • Bemerkung: Wir wollten ein Event fuer einen Strahltransfer verschicken. Gegen das heutige Versenden von vielen Events fuer einen einzigen Transfer haben wir uns damals entschieden gewehrt. Es war ausdrucklich auch der Wunsch von FE, viele Gruppen mit vielen gleichzeitigen Events zu haben!
      • Frueher: ein TIF war in einer Gruppe (z.B. SIS PZ): Eine RT Aktion als Reaktion auf ein Event
      • Heute: TR werden - anders als abgesprochen - in mehreren Timinggruppen verwendet: N RT Aktionen als Reaktion von N Events. Das dauert dann auch N mal so lange.
    • Anzahl der "Kunden"
      • Frueher: Ein TIF, ein Kunde.
      • Heute: Eine der zentralen Anforderungen bei der Neuentwicklung war, dass mehrere Kunden den TR simultan benutzen koennen. Dadurch ergibt sich die Notwendigkeit einer Zwischenschicht mit IPC. Diese zusaetzliche Zwischenschritt kostet einfache mehr Zeit!
    • Technologie
      • Frueher: Parallele VME Buszugriffe. Gut fuer niedrige Latenz kleiner Pakete. Schlecht fuer Bandbreite
      • Heute: Serielles PCIe Protokoll. Gut fuer hohe Bandbreite im pipelined Betreib. Schlecht fuer niedige Latenz kleiner Pakete im synchronen Betrieb ("Stotterbetrieb": PCIe macht die meiste Zeit nichts und wartet nur).
    • Datenaufkommen
      • Frueher: 16bit fuer ein Event
      • Heute: ca. 400 bit fuer ein Event (256bit timing message, 64bit execution timestamp, 64bit tag, "error flags" ...).
    • ...
  • Gruende fuer die derzeitig maessige Performance
    • Etherbone ist nicht das Problem. Siehe Messungen
    • PCIe Implementierung ist suboptimal. Siehe items 7 und 74 hier. Bisher hatten anderen Dinge immer eine hoehere Prio.
    • Signalling via dbus dauert in der Tat lange. Die damalige Entscheidung fuer dbus wurde getroffen, da es in den freigegebenen Detailled Specs fuer TR keine Anforderung fuer niedrige Latenz gab. An dem Thema "Signals" ohne dbus wird aber bereits gearbeitet, siehe R12.

1.1 Device Access

• Latenz-Zeiten auf einer SE in Device Access:
  • ~80us zwischen Event-Interrupt und Start des EQMs.
  • ~200us zwischen Event-Interrupt und dem (ersten) Sollwert am Gerät (via MIL)
• MIL-Zugriffe auf einer SE in Device Access:
  • ~100us zwischen zwei MIL-Zugriffen beim 16Bit-Sollwert setzen (MX, turboCurrentsEqm, ELI_DIRECT).
  • ~200us zwischen zwei MIL-Zugriffen beim 16Bit-Istwert lesen (MX, turboCurrentiEqm, ELI_DIRECT).
• Siehe Laufzeitmessungen der MX-EQMs im Hochstromtiming.

2 Ziel

2.1 Kurzfristig

• Shared Memory ist in Arbeit. Damit können dem FG-Treiber der SAFT-Lib alle Rampendaten übergeben werden. Die benötigte Zeit zur Vorbereitung der Rampen sollte sich damit von zur Zeit 28ms auf dann schätzungsweise 8ms bis 12ms verkürzen.
• Derzeitige Planung ist, das shared Memory für die Strahlzeit 2018 zur Verfügung zu haben, vorausgesetzt, für die zuvor geplanten ausführlichen Test steht genügend Zeit zur Verfügung.

2.2 Mittelfristig

• Interrupt-Pfade optimieren
  • Über SAFTlib/D-Bus nur noch einen schnellen Pfad (z.B. Message-Queue) initialisieren.
  • Die eigentlichen Interrupts kommen dann über den schnellen Pfad...
  • ...und liefern auch gleich den (Multiplexing-) Kontext mit.
  • Bedenken:
    • Interrupts können nicht nur vom Timing-Receiver kommen.
    • Interrupts können unterschiedliche Prioritäten haben.
• Ob man diesen Schritt tut, oder gleich eine langfristige, 'radikale' Lösung angeht, ist unklar.
• Absprechen mit ACO/TG und ACO/HW bzw. im Controls Steering Board und im CCT.
• Vor Q4/2018 sieht FE keine echte Chance, das anzugehen.

2.3 Langfristig

• Die in Abschnitt 1.1 Device Access angegebenen Latenz-Zeiten auf einer SE müssen auch mit FESA erreichbar sein.
• SAFTLib/D-Bus(1) komplett ersetzen, eigenen (Linux-) Interrupt-Treiber erfinden, der auch den Timing-Receiver mit einbezieht?
• Redesign der SCU-Hardware (mit optimierter oder gar ganz ohne Etherbone/PCIe-Bridge)?
• FESA Workflows stärker auf unsere Bedürfnisse anpassen, dass sie besser zu bei uns häufig auftretenden Anforderungen passen und zur Steigerung der Produktivität beisteuern können?

3 Wie können wir das erreichen?

3.1 Brainstorming-Sammelliste - mittelfristig:

• FG
  • von extern stoppbar machen (den MasterFG dafür erweitern)
  • FG soll alle für eine Sequenz benötigten Rampen halten (1024), inklusive der Alternativen
  • Interrupt-Pfade für SAFTlib-FG-Treiber optimieren
    • Absprechen mit der Timing-Gruppe
  • FG-Treiber soll auf Events reagieren können?
  • Verbesserungen passend zum derzeitigen FIFO-Konzept:
    • flushen des FIFOs durch den Nutzer ermöglichen
    • MasterFG soll abbrechen, wenn eine Rampe geladen wird und er nicht im Zustand running ist (?)
    • Reduktion der vielen Interrupts (von FG@LM32 an SAFTLib) am Ende einer Rampe (?)
• FESA
  • State-Machine in den FESA-Klassen, damit Versorgung der FGs zum richtigen Zeitpunkt geschieht
    • Eine State-Machine ermöglicht ebenso Init, Reset, Power on/off korrekt auszuführen. Siehe auch Kapitel "2.2 Ein-/Ausschalten, Reset, Init" Further Necessary Power Supply Functionality.
  • RT-Actions als Interrupthandler einsetzen -> spart 600ms D-Bus-overhead
  • Achtung bei der Intergration von SAFTlib-Änderungen in FESA: Am Besten als Nightly ausrollen.

• Milestones
  • Wann wird es tatsächlich noetig sein, mit FESA Software samt ihrer third-party Abhaengigkeiten schneller zu sein?
  • Was brauchen wir für die SIS18-Wiederinbetriebnahme, insbesondere was (Vorlauf-) Zeiten bei der PZU-DM-Kopplung betrifft? Sind die derzeitigen 28 ms okay?
  • Welche (Latenz-/Response-) Zeiten brauchen wir für den Unilac-Umbau?

4 Termine

• 5.12.17 - Grundlegende Besprechung der Fragestellung und Brainstorming
• 20.2.18 - Kurz- und mittelfristige Planungen
• Nächster Termin ist offen. LH spricht Thema im Controls Steering Board bzw. im CCT an.

---

(1) Wikipedia meint übrigens: "D-Bus (von englisch Desktop-Bus) ist eine freie Programmbibliothek zur Interprozesskommunikation. Sie orientiert sich insbesondere an den Bedürfnissen von Desktop-Umgebungen." Da fragt sich doch, ob ein Desktop-Bus das geeignete Mittel ist für ein Realtime-System!? Dazu kommt, dass jedes Desktop System mehr PS unter der Haube hat als die SCU...