-
Alessandro Rubini authored
This removes some needless local variables related to correction field, but relying on a new "cField" entry in pp_instance, near the t1,t2,t3,t4 status stamps. The commit also adds a FIXME note: it is not clear to me how the correction field can be managed in the back message (t3, t4). Since the correctionField is updated by transparent clocks, I think we need the one of the delay request (the one stamped in t3, t3), *not* the delay response that I don't care about. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
05e8a274