1. 13 Oct, 2015 2 commits
  2. 09 Oct, 2015 1 commit
    • Alessandro Rubini's avatar
      wr-servo: TRACK_PHASE now monitors delays to zero it · e052a9be
      Alessandro Rubini authored
      During track-phase we used to find the setpoint and then track changes in
      the master-to-slave delay, thus not zeroing any initial error that may
      happen (e.g. the initial sample was more jittery than average).
      
      Now we use the clock offset as correction source. Setpoint is
      adjusted by 1/4th of the current offset, to smooth a little the jitter.
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      e052a9be
  3. 08 Oct, 2015 1 commit
    • Alessandro Rubini's avatar
      wr-servo: fix a synchronization bug · 4070caf1
      Alessandro Rubini authored
      This is likely the result of my cleanup of wr-servo, where I forgot
      some pieces.
      
      Greg collected some interesting logs in wrpc where the setpoint
      was calculated wrongly. This fixes the thing and removes some redundancy.
      
      I "git diff" order:
      
      - avoid WR_UNINITIALIZED, really unused. Do what's needed at
        wr_servo_init() time
      
      - adjust phase to 0 at init time, where s->cur_setpoint is set (we
        really should set and use in a single unified place)
      
      - set delta_ms_prev before entering TRACK_PHASE, not earlier where it
        doesn't fit
      
      - avoid extra checks of non-zero offset.seconds and
      offset.nanoseconds, because they are checked at the beginning anyways.
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      4070caf1
  4. 01 Sep, 2015 5 commits
  5. 24 Aug, 2015 2 commits
  6. 21 Aug, 2015 4 commits
    • Alessandro Rubini's avatar
      wrs-socket: decrease the timeout when waiting for a timestamp · 2f989cb5
      Alessandro Rubini authored
      Even under load, with queues full, the wrs delays frames less than one ms.
      
      Thus, if we didn't get a timestamp in 1ms, we won't ever get it. Add
      some software delay and clearly we don't need 100ms as in current
      code.  Please note that all state machines are not running during this
      wait, as we are single-process single-thread.
      
      So now we wait for 6ms at most (3 times 2ms at most, but the first
      time we may get an older timestamp, then discarded).
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      2f989cb5
    • Alessandro Rubini's avatar
      wrs-socket: simplify the code retrieving timestamps · 9250cea8
      Alessandro Rubini authored
      This turns the while(1) with internal retry++ to a loop based on retry.
      With two changes:
      
      1- when recvmsg() gets EAGAIN (or other errors), we loop over instead
      of returning. Maybe this doesn't happen anymore thanks to the change
      from POLLIN to POLLERR (previous commit), but this is philosophically
      correct anyways.
      
      2- we don't print anything when poll() returns 0, as these messages
      were redundant, especially when there were many in a row. And if
      nothing is there we expect to get 0. So we removed these:
      
         poll_tx_timestamp: poll() = 0 (Success)
      
      Still, knowing the timestamp was late is useful, but a single message
      suffices, and it's there now.  If you wonder why we loop instead of
      using a longer timeout, the reason is we must get rid of timestamps
      for older frames (the ones that timeout at the previous iteration).
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      9250cea8
    • Alessandro Rubini's avatar
      unix and wrs socket: open in non-blocking mode and report write errors · 4c6953fb
      Alessandro Rubini authored
      It may happen, though rarely, that frames are not sent (or not freed
      at kernel level), and we build up an output queue, so at some point we
      get -EAGAIN on sending.
      
      With blocking writes, this situation was stalling the whole process.
      This patch helped us diagnosing a problem in our own network driver,
      which had a memory leakage, but using non-blocking sockets and
      reporting erors is the right thing to do anyways.
      
      This patch reports the error using pp_diag with a priority 0; thus
      the message is always printed, but by virtue of pp_diag we have the
      name of the port automatically added.
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      4c6953fb
    • Alessandro Rubini's avatar
      wrs-socket: use POLLERR for timestamps · 0bef6863
      Alessandro Rubini authored
      While the manual pages say nothing, https://lwn.net/Articles/291793/
      hints that we should use POLLERR instead of POLLIN.
      
      I hoped to get rid of some of the poll messages, but nothing changes
      in simple tests. I hope we get rid of the EAGAIN in the later recvmsg()
      (likely with POLLIN we got the socket as readable, but nothing was
      in the error queue -- we had a new incoming frame instead).
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      0bef6863
  7. 23 Jul, 2015 1 commit
  8. 22 Jul, 2015 3 commits
    • Alessandro Rubini's avatar
    • Alessandro Rubini's avatar
      wr-servo: run twice as fast · 6ecdf970
      Alessandro Rubini authored
      The old code used to discard every other tuple, because when "wait for
      hardware was set", the code cleared the flag and did nothing. This was
      exposed by one of the clean-up passes, but I chose not to change the
      behaviour.
      
      Now I do the normal work when wait_for_hw gets cleared.  However, as a
      side effect, wr_mon was always saying "wait for hardware", because any
      action would set the flag.
      
      Thus, the solution is not setting the flag in TRACK_PHASE, but only
      in the initial SYNC_SEC and SYNC_NSEC states. The code then checks
      if the hardware is busy, irrespective of any flag.  The result in wr_mon
      is matching reality, and the code works twice as fast as it used to.
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      6ecdf970
    • Alessandro Rubini's avatar
      WR: set system time from WR time · 11c199bc
      Alessandro Rubini authored
      The previous code to set system time from WR time is not really
      working.
      
      It is implemented in wrs_time_ops->set and it relies on ppsi being
      non-wr slave before being wr slave, but this should not happen.  Such
      code, with its "weird" message, remains in place to be used when we
      run in non-wr mode (as slaves).
      
      This new code is the right thing to do: when we are done syncing the
      "big steps" in WR, and start dealing with sub-tick, we jump system
      time.
      
      There is no correction for TAI/UTC because the time operations for
      arch-unux (set/get) already do the conversion.
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      11c199bc
  9. 21 Jul, 2015 5 commits
  10. 20 Jul, 2015 2 commits
  11. 10 Jul, 2015 1 commit
  12. 09 Jul, 2015 3 commits
    • Alessandro Rubini's avatar
      wr-servo: changes for the better · ac320650
      Alessandro Rubini authored
      What happened, sometimes, is that the phase setpoint take a meaningless
      (and high) value. This is because we were into SYNC_NSEC and moved
      to SYNC_PHASE without checking. Maybe because of other problems too.
      That situation led to a lockup of the softpll, which tries to
      reach an unreachable setpoint.
      
      Now we force to stay in SYNC_NSEC if the offset is more than one cycle
      (and SYNC_SEC if more than one second).
      
      As a side effect, the phase setpoint is always 0..16ns (while earlier
      I got setpoints of 1.5 of 17.5 etc, up to 64.5 for the same setup and
      same temperature).
      
      The problem here is: what is going to happen if, by thermal effect,
      the phase setpoint crosses the 0..16n interval?
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      ac320650
    • Alessandro Rubini's avatar
      c385d8aa
    • Adam Wujek's avatar
      Merge branch 'adam-snmp_tune' · a5a85d39
      Adam Wujek authored
      a5a85d39
  13. 08 Jul, 2015 3 commits
  14. 06 Jul, 2015 7 commits
    • Benoit Rat's avatar
      wr: Adding hook for WR state · 78b2d08c
      Benoit Rat authored
      When changing the state of the WR servo we can call a hook (function
      pointer) to a function defined by a user in the upper layer (wrpc-sw).
      The purpose of the hook is to add new functionalities when we reach a
      specific state (Alarms, IRIGB, etc...) without needing to change the
      code of PPSI.
      
      [This is a rework of the original patch by Benoit. Mainly, I added
      the extra integer argument to the hook (so I call it twice: both
      entering and leaving the servo), and I removed the function to
      set the hook from wrpc: the main function can set the pointer directly]
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      78b2d08c
    • Alessandro Rubini's avatar
      1d5a461d
    • Alessandro Rubini's avatar
      Merge branch 'vlan-unix-wrs' · bc172173
      Alessandro Rubini authored
      bc172173
    • Alessandro Rubini's avatar
      arch-wrs: pad frames sent with VLAN tag · d37136ea
      Alessandro Rubini authored
      The switch is padding short frames sent from the CPU in the nic core.
      When the frame is then being sent to an "access" port, the tag is
      removed, and thus the frame gets shorter.  The net effect is that
      sync/f-up/delay-rep were sent short, and discarded by the recipient.
      
      Greg could move padding to the endpoint, but this extra work is not
      really needed, as nobody else is expected to get frames from the CPU
      over the SFP ports. So we chose to fix transmission in software and
      avoid to change the gateware.
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      d37136ea
    • Alessandro Rubini's avatar
      arch-wrs: fixes for vlan · 7f97e9cd
      Alessandro Rubini authored
      The way vlan frames are received is different on wrs than in normal
      Linux. Likely my own driver (for wrs hardware) is not doing the right
      thing.
      
      So, when we receive tagged frames, they reach us as-is (not as the
      payload only, with "aux" data on a side). This commit considers this
      case.
      
      The commit also fixes a pair of other details -- mostly, the amount of
      "short packet of 0 bytes, ignored", by returning -2 to mean "drop with
      no error".
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      
      SQUASH fix for ARCH_WRS
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      7f97e9cd
    • Alessandro Rubini's avatar
      doc: document vlan support · d3613623
      Alessandro Rubini authored
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      d3613623
    • Alessandro Rubini's avatar
      master: obey vlans · 3b985b02
      Alessandro Rubini authored
      When we support multiple vlans, we must issue announce to all
      supported vlans. Same applies to sync/follow-up. This changes
      state-master.c to do the sending several times.
      
      Initially I changed msg.c (for the announce message only), this saved
      the repeated call to msg_pack_announce() but by doing it at
      state-master level I have simpler code and layer consistency (doing
      sync/fup at msg.c level would be a mess).
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      3b985b02