87 Software Moving timestamping further from the cable increases both static timestamp error and variation (PDV) FIGURE 8-21 Effect of timestamping point. close to the physical network connection as possible. As soon as the timestamping point is pushed away from the actual cable into the bowels of the hardware there will be FIFOs, clock domain crossings, etc., between it will add errors to the timestamping accuracy. If the hardware has no timestamping capability and it is instead handled by software then the accuracy will be even worse given the nondeterministic nature of most operating systems. This is illustrated in Fig. 8-21. We will come back to where timestamping realistically needs to be done in an O-RAN application later. Network asymmetry-i there is a true, static network asymmetry then the only way to eliminate the effect of this on the accuracy of the synchronized time is to manually program the error into each device based on either knowing the asymmetry through design analysis or measuring it in some way. For example, if a slave is connected to the master by a pair of fibers that are not length matched, with the result that there is a 1 us difference in the time it takes data to go in each direction then, without any correction, this will cause an offset in the recovered time of exactly half this-500 ns. However, if the network installer tells us about the 1 us difference, we can program the slave to always offset its time by 500 ns to null out the error. Alternatively, when installing the slave, we could temporarily hook up a local GNSS receiver to the slave and compare the time from that with the time we derive from PTP and program the difference as a known offset. Network PDV-This is the tricky one, and the problem that can make or break the usefulness of PTP. There are two ways that PDV can be handled. The first is to accept 288 Open Radio Access Network (O-RAN) Systems Architecture and Design that the network will have PDV and force the slave to somehow filter this out. In order to do this, the c