That will be very difficult for the Windows ones. For the Linux ones,
add code to the clock interrupt routine that pulses a printer port line
or modem control signal (do not use USB ports), and simultaneously
writes the offset between the software clock time and the nominal, round
number of milliseconds, tick time, to a buffer. At user level copy that
buffer to a file.
Do this on both client and server.
Set up some suitable instrumentation to measure and log the time delay
between the pulses on client and server, then process the results in
conjunction with the client and server's idea of the time at the time of
This assumes that the machines are electrically close.
Don't worry too much on Windows, as the time is likely to be more
accurate than the resolution with which ordinary application programs
can read it. If you are using w32time on XP, don't worry, because
w32time is not intended for precision time keeping on that platform, and
doesn't default for it on 2003.
If you want to measure the value during the startup and other transients
that Dave Mills considers unimportant, use ntpq on the server. This
will not work for any machines using w32time. You might also configure
the client as an ignored server for the server, or maybe peering them,
to allow ntpq peers run on the server, against the server, to give a
reverse "offset" value. Note these methods only give you historical
information. For a near instantaneous snapshot, use ntpdate -d.
The reason you are getting such complex answers is that you are asking
to measure something that, in an ideal system, is theoretically