You are here: Foswiki>Applications Web>LsaMainPage>LsaTimingNotes (03 Mar 2016, RaphaelMueller)Edit Attach

Discussed Timing Structure for CRYRING

\\WinFileSvG\BEL$Root\belgroup\Machines\CRYRING\_Old_project_filesystem\TimingStructure

Timing Makerule

Basic working: It was decided that generating the timing information will be modeled in the LSA hierarchy.

So we generated enumaration for timing groups and timing messages (events) from the database tables to ease programming. These classes can be found in the project "lsa-domain-generated-gsi".

Calculating event tables:

  • Each beamprocess has a parameter with a table of events
    • each row contains TIMING_GROUP, PROCESS_KEY, SEQUENCE_KEY, EVENT_NUMBER, EVENT_TIME (relative to the beamprocess start)
  • This table is 'calculated' by the TimingScheduleMakeRule depending ...
    • ... on the beamprocess purpose (e.g. BEAM_IN / BEAM_OUT)
    • ... the particle transfer (e.g. YRLE / YRME / CRYRING_RING)
    • ... the value of the parent parameters (e.g. BEAM_PULSE_LENGTH / BI_DELAY / RF_PAUSE_PULSE_LENGTH)
    • ... if the context is not resident SEQUENCE_KEY and PROCESS_KEY are '-1'

Generating the XML:

  • When a pattern is made resident the parameters PROCESS_KEY and SEQUENCE_KEY in each beamprocess are set (event tables are not filled with -1 anymore)
  • If a change (trim) is made and the context is resident the drive ...
    • ... test if one of the timing tables changed, if yes we need to send values the DM
    • ... if timing changed all event tables are gathered and merged
    • ... the merged events are converted into an XML description (relative times becoming absolute)
    • ... we stop the data master (or one core) resupply the XML and start it again
Example of an LSA timing event table for one beamprocess (not resident, so sequence and process index are -1) and timing hierarchy for the cryring injection line. timingHierarchy.png

Supplying the Data Master:

The data master interface does not follow our usual FESA Guidelines (e.g. no Setting Property) there is some special handling needed to supply it with XMLs. Specific selection of the core/thread through matrices.... etc.

Line 124:
https://www-acc.gsi.de/svn/lsa/core/lsa-core-gsi/trunk/src/main/java/cern/lsa/client/spi/ExploitationServiceImpl.java
and the dedicated class
https://www-acc.gsi.de/svn/lsa/core/lsa-core-gsi/trunk/src/main/java/de/gsi/cs/co/lsa/exploitation/timing/FairTimingController.java

Basically while sending an XML you also specify which core and thread should execute it. After that you can access fields like 'operation outcome' to check if sending the XML was successfull.

The Command property is for control (run, stop, abort) threads.

The Simple Scheduler is for supplying and retrieving data.

Timing Master Interface (FESA)

See also: https://www-acc.gsi.de/wiki/Timing/TimingSystemLSAInterface 
Max CPUs    m = 8
Max Threads n = 8
I -> FESA Property has Set
O -> FESA Property has Get

DataMaster
Proposed FESA Interface Structure

DM
|
+- Command
|   |
|  I+- Cpu    Idx 0..m-1, all
|  I+- Thread Idx 0..n-1, all
|  I+- CPU/Thread destination Bitfield m x n -1 (default use is CPU and Thread Index. if Bitfield is used, it will override CPU and Thread index choice)
|  I+- Cmd (Global:(Enable, Disable, Rst DM), per CPU(Rst CPU), per Thread(Run, Stop, Abort, Idle, Rst))
|
+- Simple Scheduler
|   |
|  I+- Cpu    Idx 0..m-1
|  I+- Thread Idx 0..n-1
|  I+- Op (check, put, get, clear, dump, request swap, force swap))
|  I+- XML Schedule String (to DM)
|  O+- Plain Text Get/Dump String (from DM)
|  O+- Operation outcome

+- Smart Scheduler (not to be implemented soon, far future)
|   |
|  I+- add to analysis queue
|  I+- flush analysis queue
|  I+- put analysis queue (queued puts)
|  I+- commit analysis queue (queued swaps)
| IO+- XML Schedule String (to DM)
|  O+- current load
|  O+- Operation outcome
|  O+- CPU/Thread destination Bitfield m x n -1
|
+- Signal
|   |
|  I+- Dst Type(Thread, Interlock, Cmd)
|  I+- Cpu    Idx 0..m-1, all
|  I+- Thread Idx 0..n-1, all
|  I+- CPU/Thread destination Bitfield m x n -1 (default use is CPU and Thread Index. if Bitfield is used, it will override CPU and Thread index choice)
|  I+- Interlock Idx
|  I+- Bitwidth 32/64
|  I+- Value
|  I+- (Mask)
|   
+- Status
|   |
|   +- Global
|   |   O+- Number of CPUs m-1
|   |   O+- Number of Threads per CPU n-1
|   |   O+- current load (shows global load over all CPUs)
|   |   O+- Enabled (Shows if DataMaster is active)
|   |   O+- Running (shows if any thread is running)
|   |   O+- Error flags (thread, several globals)    
|   |   O+- Msg Count (Cumulative TX Message Counter)
|   |   O+- Current FESA Time (UTC time on this host)
|   |   O+- Current DM WR Time (White Rabbit Time on DataMaster)
|   |   O+- WR Status (White Rabbit status on DataMaster)
|   |
|  I+- CPU/Thread (mask) Bitfield m x n -1  (Mask all fields with this selection) 
|  O+- Running Bitfield m x n -1 (Shows running threads) 
|  O+- Loaded A Bitfield m x n -1 (Shows A pages containing threads) 
|  O+- Loaded B Bitfield m x n -1 (Shows B pages containing threads)
|  O+- Active A/B Bitfield m x n -1 (Shows active page per threads (0=A, 1=B))
|  O+- Error Bitfield m x n -1 (Shows threads which have thrown errors)  
|  O+- Idle Bitfield m x n -1 (Shows idling threads) 
|  O+- Conditional Wait Bitfield m x n -1 (Shows threads waiting on condition)  
|  O+- Blocked Bitfield m x n -1 (Threads/Timeslices reserved by the DM for non user operations)
|  O+- Msg Count Vector, m x n -1 (Shows msg counters of threads)

Example XML 

<page>
  <meta>
    <startplan>A</startplan>
  </meta>
  <plan>
    <meta>
      <starttime>0</starttime>
      <lastjump>self</lastjump>
    </meta>
    <chain>
      <meta>
        <rep>-1</rep>
        <period>1000000000</period>
        <branchpoint>yes</branchpoint>
      </meta>
      <msg>
        <id>
          <FID>0</FID>
          <GID>201</GID>
          <!--CMD_SEQ_START-->
          <EVTNO>257</EVTNO>
          <SID>1</SID>
          <BPID>1</BPID>
        </id>
        <par>0x0</par>
        <offs>0</offs>
      </msg>
      <msg>
        <id>
          <FID>0</FID>
          <GID>202</GID>
          <!--CMD_SEQ_START-->
          <EVTNO>257</EVTNO>
          <SID>1</SID>
          <BPID>1</BPID>
        </id>
        <par>0x0</par>
        <offs>0</offs>
      </msg>
      <msg>
        <id>
          <FID>0</FID>
          <GID>202</GID>
          <!--CMD_RF_PREP_PAUSE-->
          <EVTNO>291</EVTNO>
          <SID>1</SID>
          <BPID>1</BPID>
        </id>
        <par>0x0</par>
        <offs>989400000</offs>
      </msg>
      <msg>
        <id>
          <FID>0</FID>
          <GID>202</GID>
          <!--CMD_RF_STOP_PAUSE-->
          <EVTNO>292</EVTNO>
          <SID>1</SID>
          <BPID>1</BPID>
        </id>
        <par>0x0</par>
        <offs>990500000</offs>
      </msg>
      <msg>
        <id>
          <FID>0</FID>
          <GID>202</GID>
          <!--CMD_RF_PREP-->
          <EVTNO>290</EVTNO>
          <SID>1</SID>
          <BPID>1</BPID>
        </id>
        <par>0x0</par>
        <offs>991500000</offs>
      </msg>
      <msg>
        <id>
          <FID>0</FID>
          <GID>201</GID>
          <!--CMD_BI_TRIGGER-->
          <EVTNO>280</EVTNO>
          <SID>1</SID>
          <BPID>1</BPID>
        </id>
        <par>0x0</par>
        <offs>991750000</offs>
      </msg>
      <msg>
        <id>
          <FID>0</FID>
          <GID>201</GID>
          <!--CMD_BEAM_ON-->
          <EVTNO>518</EVTNO>
          <SID>1</SID>
          <BPID>1</BPID>
        </id>
        <par>0x0</par>
        <offs>992000000</offs>
      </msg>
      <msg>
        <id>
          <FID>0</FID>
          <GID>202</GID>
          <!--CMD_BEAM_ON-->
          <EVTNO>518</EVTNO>
          <SID>1</SID>
          <BPID>1</BPID>
        </id>
        <par>0x0</par>
        <offs>992000000</offs>
      </msg>
      <msg>
        <id>
          <FID>0</FID>
          <GID>201</GID>
          <!--CMD_BI_MEAS1-->
          <EVTNO>281</EVTNO>
          <SID>1</SID>
          <BPID>1</BPID>
        </id>
        <par>0x0</par>
        <offs>992100000</offs>
      </msg>
      <msg>
        <id>
          <FID>0</FID>
          <GID>201</GID>
          <!--CMD_BI_MEAS2-->
          <EVTNO>282</EVTNO>
          <SID>1</SID>
          <BPID>1</BPID>
        </id>
        <par>0x0</par>
        <offs>992300000</offs>
      </msg>
      <msg>
        <id>
          <FID>0</FID>
          <GID>201</GID>
          <!--CMD_BEAM_OFF-->
          <EVTNO>520</EVTNO>
          <SID>1</SID>
          <BPID>1</BPID>
        </id>
        <par>0x0</par>
        <offs>993000000</offs>
      </msg>
      <msg>
        <id>
          <FID>0</FID>
          <GID>202</GID>
          <!--CMD_BEAM_OFF-->
          <EVTNO>520</EVTNO>
          <SID>1</SID>
          <BPID>1</BPID>
        </id>
        <par>0x0</par>
        <offs>993000000</offs>
      </msg>
    </chain>
  </plan>
</page>

Comments from Hanno

Die wesentlichen Fragestellungen sind Jutta und Dir klar, denke ich, meine spontanen Einfälle nochmal kurz als Stichpunkte zum Abgleichen:
  • Auf welchem Abstraktionsniveau versorgen wir (nur Events und Schedulefragmente oder kennt die "Zwischenschicht" auch Chains und Patterns? Wäre vielleicht praktisch für's Definieren von alternativen Patterns / optionalen Chains und das "Erlauben" / "Verbieten" von bestimmten Strahlen wie Pilot / Hochenergie, hab aber keine genaue Vorstellung wie das konkret aussehen sollte)?
  • Wie werden Bedingungen (konkret) formuliert und versorgt? Wie werden die Bestandteile der Bedingungen gesetzt? Das brauchen wir eher früher als später für unsere Speicherring-Geschichten.
  • Soll die "Zwischenschicht" Teil des MASP sein oder nicht? Wie ist das Zusammenspiel dieser Ganzen Komponenten überhaupt und welche Daten erwarten die von uns?
  • Wie sind die Zeitanforderungen an die Zwischenschicht? Wie schnell muss sie potentiell den Data Master umprogrammieren können (falls das der Plan ist, klang so in Mathias' Vorschlag), damit dieser rechtzeitig reagiert?
  • Brauchen wir dann zwei Schnittstellen (eine zum Data Master, eine zur Zwischenschicht, das wär nicht so toll) oder geht dann alles durch die Zwischenschicht?
Und dann noch das Übliche, d.h. was ist mit "partiellem" Versorgen, d.h. nur bestimmte Chains / Patterns ändern, wie machen wir Commits, also auch an die Geräte, wie abstrahieren wir von Cores und Threads.

An der Schnittstelle ist noch einiges zu tun. Das meiste kennst Du, bzw. kannst Du auch im FairTimingController (o.ä.) nachschauen. Das letzte Merkwürdige war das Zurücklesen der Schedule, das sollte eigentlich über die Setting-Property gehen, schätze ich, ist aber aktuell vollkommen woanders. Und das "Errorhandling" per operationOutcome-Feld scheint mir auch noch etwas merkwürdig, mit den inkonsistenten String-Konstanten, die ich aktuell vergleiche. Aber das sind dann wahrscheinlich schon Details.

Open Points

Edit  | Attach | Print version | History: r4 < r3 < r2 < r1 | Backlinks | View wiki text | Edit wiki text | More topic actions
Topic revision: r4 - 03 Mar 2016, RaphaelMueller
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback