1. 05 Apr, 2017 1 commit
    • Alessandro Rubini's avatar
      general fix: implement SYNCHRONIZATION_FAULT · a438acc9
      Alessandro Rubini authored
      If we stopped sending to the master or the peer (for traffic or
      whatever; in my case with "fault drop"), we wouldn't notice the
      problem.
      
      This looks like SYNCHRONIZATION_FAULT (9.2.6.12), so this reuses the
      almost-unused TO_FAULTY, renaming it to a more generic TO_FAULT.
      
      9.2.6.12 says we should reach uncalibrated, but since uncalibrated doesn't
      exits (it is never entered, it's dead and untested code at this point),
      I handle the problem just like the timeout receiving announce messages.
      
      For wr, I reset the servo, so the problem can be seen.
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      a438acc9
  2. 05 Mar, 2017 1 commit
    • Alessandro Rubini's avatar
      standard servo: bugfix (introduced with pp_time) · cfed2306
      Alessandro Rubini authored
      If meanPathDelay is calculated negative at the first iteration, we
      must zero it immediately, or this will loop forever:
      
      	while (mpd_fltr->y >> (63 - s))
      		--s;
      
      The bug only appears with e2e mechanism, where t3 happens long after
      t2, if the slave clock when ppsi starts is running much slower than
      the master.
      
      Before changing data structures we used abs() in that loop (which was
      suboptimal), and I made a mistake in converting it in a check before
      the loop itlsef.
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      cfed2306
  3. 03 Mar, 2017 1 commit
  4. 31 Jan, 2017 1 commit
  5. 04 Nov, 2016 6 commits
  6. 20 Sep, 2016 1 commit
    • Davide Ciminaghi's avatar
      compliance, 11.3, d: take delay_resp cf into account · a44cadcb
      Davide Ciminaghi authored
      11.3 d says:
      
      Upon receipt of the Delay_Resp message by the slave:
      
      1) If the received Sync message indicated that a Follow_Up message will not
         be received, the <meanPathDelay> shall be computed as:
         <meanPathDelay> = [(t2 - t3) + (receiveTimestamp of Delay_Resp message -
         originTimestamp of Sync message) -
         correctionField of Sync message -
         correctionField of Delay_Resp message]/2.
      2) If the received Sync message indicated that a Follow_Up message will be
         received, the <meanPathDelay> shall be computed as:
         <meanPathDelay> = [(t2 - t3) + (receiveTimestamp of Delay_Resp message -
         preciseOriginTimestamp of Follow_Up message) -
         correctionField of Sync message -
         correctionField of Follow_Up message -
         correctionField of Delay_Resp message]/2.
      
      We assume that:
      
      t1 = originTimestamp of Sync message (one step) or
      t1 = preciseOriginTimestamp of Follow_Up message (two steps)
      
            and
      
      t4 = receiveTimestamp of Delay_Resp message
      
      wich is true for masters not supporting sub-nanosecond
      timestamps (we don't support sub-ns precision via standard protocol, so the
      assumption should be true for us).
      
      As sync (or followup) arrives, we calculate m_to_s_dly, which is:
      
      t2 - t1 - cf_sync - cf_followup
      
      When delay_resp arrives, we calculate s_to_m_dly, which is:
      
      t4 - t3 - cf_delay_resp
      
      So [(m_to_s_dly + s_to_m_dly) / 2] should be equal to:
      
      (t2 - t3 + t4 - t1 - cf_sync - cf_followup - cf_delay_resp) / 2
      
      which looks like the 11.3 d expression for mean path delay
      (note that cf_followup is zero for a one-step master).
      
      To get this result, we just save the delay_resp cf to ppi->cField.
      a44cadcb
  7. 16 May, 2016 4 commits
  8. 21 Jul, 2015 1 commit
  9. 07 Nov, 2014 2 commits
  10. 21 Jul, 2014 1 commit
  11. 18 Jul, 2014 3 commits
    • Pietro Fezzardi's avatar
      std servo: no running avg and outlier removal on ofm · 8ddfbcec
      Pietro Fezzardi authored
      There is no need to remove outliers and to make a running
      average on ofm. Indeed we know that ofm = t2 - t1 -mpd.
      We are already removing outliers and averaging on mpd.
      So, if after mpd has been "cleaned", ofm still shows outliers
      or irregularities they are for sure due to t1 and t2. So they
      are errors coming from the clocks and they have not to be
      ignored. Instead they must be corrected ASAP, and to do that
      the software must be able to see them instantly. So no
      running avg nor outlier removal has to be performed on ofm values.
      8ddfbcec
    • Pietro Fezzardi's avatar
      standard servo: store accumulator in scaled nsecs · 67258e3b
      Pietro Fezzardi authored
      The integral accumulator of the PI servo is now a 64bit integer.
      The stored values are bit shifted by 10, so we have a finer
      granularity on the control.
      With the previous implementation the integral part stopped working
      when ofm was under the value of OPTS(ppi)->ai. This problem has
      been solved with this changes.
      I had to use __div64_32() from lib/div64.c, because dividing for
      a long long is not allowed in arch-wrpc (it takes too much RAM).
      67258e3b
    • Pietro Fezzardi's avatar
      arch-sim: new simulator diagnostics and config · 717a8f5e
      Pietro Fezzardi authored
      diagnostics:
      
      For testing purposes we can't just read the ofm value
      printed out by the slave, because that's only the offset
      perceived by the slave and can be wrong. We need instead to
      print out the offset obtained subtracting the real time of
      the master from the real time of the slave.
      To print out the ofm we use the "ext" flag of pp_diag.
      The ofm is printed only when the slave gets a
      DelayResp message from the master.
      A new tool to strip ofm out of simulator log is provided
      
      config:
      
      now the max number of simulated ptp iterations can be configured.
      previously one could set the number of seconds to simulate.
      this is not possible anymore.
      717a8f5e
  12. 02 Mar, 2014 3 commits
  13. 06 Nov, 2013 1 commit
    • Alessandro Rubini's avatar
      bug workaround for slave states: don't refuse a new master · 577ed159
      Alessandro Rubini authored
      This works around a design problem that must be checked carefully.
      The "is from current parent" flags set at receive time reveales bad,
      as we should only check when needed.
      
      So by now just say it is the current parent if we don't have a current
      parent yet (i.e., we are not in error, even if it is not from current
      parent).
      
      Also, forget about current parent and foreign masters when the servo
      is initialized (e.g., at link-up on the wr node).
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      577ed159
  14. 05 Oct, 2013 1 commit
    • Alessandro Rubini's avatar
      general: rename oneWayDelay to meanPathDelay · 6a33f66e
      Alessandro Rubini authored
      The 1588 standard talks extensively about "mean path delay"
      and the meanPathDelay variable.   Even if the name is not the
      best one, we'd better rename the fields and variable.
      
      This is a massive change, but the currenct code has been validated at
      the Lemgo plug fest, and I don't expect any need to revert older
      patches at this point.  I'm sorry for git-blame users, including myself,
      but this change is a step forward.  I should have knonw better when
      choosing "one way delay" between the two names of the older code.
      
      Thanks to Aurelio for noting the problem.
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      6a33f66e
  15. 19 Sep, 2013 1 commit
    • Alessandro Rubini's avatar
      servo: when setting time, make no calculations · ec537cd1
      Alessandro Rubini authored
      When offset from master is more than one second, the code used to
      time->get, subtract and then time->set.
      
      However, in white rabbit we cannot get the WR time and time->get
      returns the unix time instead. The only way to have hardware time is
      timestamping a frame.  Thus, use the master's "T4" that we just
      received plus the one-way-delay as an approximation of the current
      hardware time. Later T1..T4 tuples will complete the fine
      synchronization.
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      ec537cd1
  16. 16 Sep, 2013 2 commits
    • Alessandro Rubini's avatar
      time_operations: add init_servo() method · 6dcafdcf
      Alessandro Rubini authored
      This function allows a servo to initialize its hardware and return the
      current "observed drift" value that is in charge.
      
      In unix-time this is used to return the current value for frequency
      correction -- being consistent with current naming and use of values,
      which unfortunately is not really correct.
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      6dcafdcf
    • Alessandro Rubini's avatar
      servo: average ofm like we do for owd, with some care · 5927cf03
      Alessandro Rubini authored
      In my opinion, it makes no sense to make calculations with a
      well-filtered OWD and the instantaneous OFM, which is subject to the
      same oscillations.  Thus, this commit filters OFM with the same rules
      used for OWD.
      
      However, the detection of outliers is more difficult because OFM can
      have either sign, and OFM is really changing while we are not yet
      synchronized.  So the code does the following:
      
      - if we are at PP_ADJ_FREQ_MAX it means we are bridging a gap as
      fast as possible. In that case, don't average OFM.
      
      - if we receive a bigger-than-expected OFM value, trim it, but relax
      the expectation so we can track a real change if futher samples confirm
      it or push it farther.
      
      - if the averaged OFM changed sign, start averaging from scratch.
      
      The second item works by keeping the average of ofm magnitude, and we
      accept a change no bigger than the averaged magnitude.  So, if we are
      synced in the millisecond range we accept changes of the order of
      milliseconds (this usually applies while syncing, and OFM is expected
      to change in that case); if we are in the microsecond range outliers
      move us by a few microseconds, but such trimming is then relaxed so we
      increase our ability to move exponentially.
      
      The last item prevents oscillations: this OFM is fed to a PI controller,
      so if we are late in responding to changes in sign, both P and I
      continue pushing in the wrong direction. So, combining the average and
      the PI we have an almost inversion in phase of the error, and the
      servo oscillates a lot while converging.
      
      Unfortunately, while working on this I realized there's a bug when
      dealing with very short and consistent timestamps. For example, a
      current average of 20ns, will never reach 40ns even if all further
      samples request 40ns, due to integer truncation.  We need to either
      move to floating point or count fractional bits as the magnitudes
      permit.
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      5927cf03
  17. 15 Sep, 2013 10 commits