The plots attached all use the same initial calibration done on data from day 345 + global T0 adjustments taken from the database, so basically directly the data that is saved in the FastOffline Dsts.
So right out of the box the data looks very nice.

We still have clock jumps in several counters when one of the Get4 clocks jumps by one clock tick of 6.25ns. This leads to hit distributions that are shifted by ~50cm ( 3.125ns * signal velocity) as the hit position is determined from the time difference of the signals registered on both sides of a strip.
This can be "cured" by shifting all hits that have a local Y position larger then ~40 cm by 3.125ns towards smaller absolute values of localY.

The hit time is calculated as the average of the two digi times, so if one of the signals is off by 6.25ns, the hit time is shifted by 3.125ns.
Currently (code in CVS) we just add 3.125ns to the hits that get shifted based on their position.
I'm not sure what is the reasoning behind this? Do we assume that it is more likely that a clock misses one tick and reports times that are too early compared to the clock jumping one tick ahead?

This seems to give bad results in some of the cases as shown in the plots "t0_clockjump_plus" and "pid_clockjump_plus".
There are certainly bands of particles that are 6.25ns to late, meaning we shift in the wrong direction.

If one subtracts 3.125ns from all hits with jumped position, then one gets the two plots "t0_clockjump_minus" and "pid_clockjump_minus" which look certainly better, but there are now (smaller) bands on particles that come 6.25ns to early.

So two options to to forward:
1) Do dedicated calibrations for each run... to reduce the amount of "jumped" hits.
For example in the fixed target test run most of the hits in counter 23-2-3 belong to the side bands with jumped hits, so doing a special calibration will put them at localY=0 and the amount of jumped hits is reduced.

2) Find a good way to tell early on in which direction the hit time needs to be shifted.
Any ideas on that?