1. 12 Jun, 2017 2 commits
    • Alessandro Rubini's avatar
      pdelay: mark stamps as invalid after use · 223459dd
      Alessandro Rubini authored
      The code is checking the sequence number of pdelay-rep and
      pdelay-rep-fup, but we may miss the reply and get the f-up.
      
      The result was something like this (first tuple is ok, next is wrong):
      
         diag-servo-2-wr1: servo:t3 = 1497279009:22584224:0
         diag-servo-2-wr1: servo:t4 = 1497279009:22584574:759
         diag-servo-2-wr1: servo:t5 = 1497279009:23564032:0
         diag-servo-2-wr1: servo:t6 = 1497279009:23564365:547
         diag-servo-2-wr1: ->mdelay = 0:684:306
      
         diag-servo-2-wr1: servo:t3 = 1497279009:663586672:0
         diag-servo-2-wr1: servo:t4 = 1497279009:22584574:759
         diag-servo-2-wr1: servo:t5 = 1497279009:683142000:0
         diag-servo-2-wr1: servo:t6 = 1497279009:23564365:547
         diag-servo-2-wr1: ->mdelay = -1:-300579732:306
      
      Here, t4 and t6 are old. The former is the receipt of the request,
      send back to the "slave" in the pdelay-reply payload; the latter is
      the receive time of such frame.
      
      We now invalidate t4 and t5 when using the tuple. They are the two
      "remote" times, one sent back in the response and the other sent back
      in the response-fup.
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      223459dd
    • Alessandro Rubini's avatar
      dfeb1890
  2. 06 Apr, 2017 2 commits
  3. 05 Apr, 2017 9 commits
  4. 29 Mar, 2017 1 commit
  5. 20 Mar, 2017 1 commit
  6. 14 Mar, 2017 1 commit
  7. 08 Mar, 2017 1 commit
  8. 06 Mar, 2017 1 commit
  9. 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
  10. 03 Mar, 2017 7 commits
  11. 01 Mar, 2017 6 commits
  12. 28 Feb, 2017 4 commits
  13. 27 Feb, 2017 4 commits