Not necessarily -- the jitter from the two local-net machines with low
delay figures is probably due to the local machine's clock drifting.
Without guessing the hostnames of the remote and local machines, I
can't speculate on the network connectivity between them, but observe
how my local performance has gone down the tubes to my next hop,
simply by pumping out traffic on the network, slightly more than tin
cans and string:
+GENERIC(1) .DCFa. 0 ? 9 16 77 0.000 0.530 0.538
Cabal-GW 220.127.116.11 3 u 44 64 3 411.963 201.224 0.935
(yes, this is right after a restart, compare this a few minutes later:)
xCabal-GW 18.104.22.168 3 u 30 64 377 288.182 139.960 132.882
Normally, the delay is some 7msec, and jitter somewhat less, with
fairly minimal traffic to/from the real world.
That may not help -- if the traffic levels are too high. In my
case shown, with a premium-rate connection, as the Cabal-GW peer
is in fact the next hop upstream, I'm not going to see better
figures from anywhere, without drastically reducing the network
traffic flowing. On the other hand, if the OP's machine and the
mailworx reference are continents apart, that delay figure may
not be as traffic-impaired as my values, and may be improved by
selecting a much closer reference.
Seeding it with `0' is worse, because if no drift file is present,
then ntpd goes into a special initialization mode to calculate the
value needed, quickly. If the file is present, ntpd has reason to
believe it's correct and isn't going to calculate a new value so
quickly, and it will take even longer to stabilize.
This is why it's better to remove the drift file when swapping OS
disks into new hardware, or juggling boards, or whatever, as the
calculated value is specific to the hardware. (When I was hardware-
hopping, I grabbed the CPU speed at boot and referred to a different
drift file for each of several machines, all of which had rather