1. 04 Sep, 2017 1 commit
  2. 31 Jul, 2017 1 commit
  3. 23 Jun, 2017 3 commits
  4. 12 Jun, 2017 3 commits
    • Alessandro Rubini's avatar
      pdelay: rework and extend prev commit · 31f08f19
      Alessandro Rubini authored
      The previous commit is not enough as a fix.  This may happen:
      
          - we invalidate stamps after processing them
          - we send request
          - get reply, loose reply-fup
          - send request
          - loose reply, get f-up
      
      So we now invalidate when sending the request. And invalidate t4 alone
      as the beautifulness and symmetry of the previous commit is lost
      anyways.
      
      Note: there no need to invalidate stamps in e2e mode, because checking
      the sequence number to validate RX frames is enough.  But here all
      replies match the sequence number, so the problem is not caught and
      stamps from different tuples are mixed.
      
      Example beofre this commit, with trimmed stamps (was 1497283863):
      
         diag-frames-1-wr1: SENT 54 bytes at 863.333173928 (pdelay_req)
         diag-frames-1-wr1: RECV 54 bytes at 863.334158796 (type 3, pdelay_resp)
         diag-frames-1-wr1: Drop received frame
         diag-frames-1-wr1: SENT 54 bytes at 864.479336104 (pdelay_req)
         diag-frames-1-wr1: Drop received frame
         diag-frames-1-wr1: RECV 54 bytes at 864.481095164 (type a, presp_follow_up)
      
         diag-servo-2-wr1: servo:t3 = 864:479336104:0
         diag-servo-2-wr1: servo:t4 = 863:333174267:586
         diag-servo-2-wr1: servo:t5 = 864:480295312:0
         diag-servo-2-wr1: servo:t6 = 863:334158796:773
         diag-servo-2-wr1: ->mdelay = -2:-292298352:359
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      31f08f19
    • 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
  5. 06 Apr, 2017 1 commit
  6. 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
  7. 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
  8. 03 Mar, 2017 4 commits
  9. 01 Mar, 2017 4 commits
  10. 27 Feb, 2017 1 commit
  11. 31 Jan, 2017 3 commits
  12. 17 Jan, 2017 1 commit
  13. 07 Dec, 2016 1 commit
  14. 03 Dec, 2016 1 commit
  15. 02 Dec, 2016 1 commit
  16. 01 Dec, 2016 4 commits
  17. 21 Nov, 2016 1 commit
  18. 04 Nov, 2016 8 commits