Searched hist:c32f1362 (Results 1 – 5 of 5) sorted by relevance
| /dragonfly/usr.sbin/dntpd/ |
| H A D | system.c | c32f1362 Tue Apr 26 07:01:43 GMT 2005 Matthew Dillon <dillon@dragonflybsd.org> Do not try to collect offset data if a prior offset correction is still
in progress. Since we do not compensate for the prior offset correction,
any corrections based on data accumulated while the prior correction is
active will overshoot or undershoot.
Offset calculations are based on compensated real time rather then
uncompensated real time, which is why this is a problem. Frequency
corrections are based on uncompensated real time and do not have any
similar issue. It would be even better, but more difficult, to adapt
the offset correction code to use uncompensated real time and then take
the compensation into account, but this is a considerably more complex
equation to get right.
There is still another problem and that is the offset error will continue
to build when the frequency is not corrected, potentially resulting in a
longer sync-up time. On the positive side, the offset correction is based
on a standard deviation that only requires a minimum of 4 samples.
Correct a minor compiler warning.
|
| H A D | client.h | c32f1362 Tue Apr 26 07:01:43 GMT 2005 Matthew Dillon <dillon@dragonflybsd.org> Do not try to collect offset data if a prior offset correction is still
in progress. Since we do not compensate for the prior offset correction,
any corrections based on data accumulated while the prior correction is
active will overshoot or undershoot.
Offset calculations are based on compensated real time rather then
uncompensated real time, which is why this is a problem. Frequency
corrections are based on uncompensated real time and do not have any
similar issue. It would be even better, but more difficult, to adapt
the offset correction code to use uncompensated real time and then take
the compensation into account, but this is a considerably more complex
equation to get right.
There is still another problem and that is the offset error will continue
to build when the frequency is not corrected, potentially resulting in a
longer sync-up time. On the positive side, the offset correction is based
on a standard deviation that only requires a minimum of 4 samples.
Correct a minor compiler warning.
|
| H A D | main.c | c32f1362 Tue Apr 26 07:01:43 GMT 2005 Matthew Dillon <dillon@dragonflybsd.org> Do not try to collect offset data if a prior offset correction is still
in progress. Since we do not compensate for the prior offset correction,
any corrections based on data accumulated while the prior correction is
active will overshoot or undershoot.
Offset calculations are based on compensated real time rather then
uncompensated real time, which is why this is a problem. Frequency
corrections are based on uncompensated real time and do not have any
similar issue. It would be even better, but more difficult, to adapt
the offset correction code to use uncompensated real time and then take
the compensation into account, but this is a considerably more complex
equation to get right.
There is still another problem and that is the offset error will continue
to build when the frequency is not corrected, potentially resulting in a
longer sync-up time. On the positive side, the offset correction is based
on a standard deviation that only requires a minimum of 4 samples.
Correct a minor compiler warning.
|
| H A D | defs.h | c32f1362 Tue Apr 26 07:01:43 GMT 2005 Matthew Dillon <dillon@dragonflybsd.org> Do not try to collect offset data if a prior offset correction is still
in progress. Since we do not compensate for the prior offset correction,
any corrections based on data accumulated while the prior correction is
active will overshoot or undershoot.
Offset calculations are based on compensated real time rather then
uncompensated real time, which is why this is a problem. Frequency
corrections are based on uncompensated real time and do not have any
similar issue. It would be even better, but more difficult, to adapt
the offset correction code to use uncompensated real time and then take
the compensation into account, but this is a considerably more complex
equation to get right.
There is still another problem and that is the offset error will continue
to build when the frequency is not corrected, potentially resulting in a
longer sync-up time. On the positive side, the offset correction is based
on a standard deviation that only requires a minimum of 4 samples.
Correct a minor compiler warning.
|
| H A D | client.c | c32f1362 Tue Apr 26 07:01:43 GMT 2005 Matthew Dillon <dillon@dragonflybsd.org> Do not try to collect offset data if a prior offset correction is still
in progress. Since we do not compensate for the prior offset correction,
any corrections based on data accumulated while the prior correction is
active will overshoot or undershoot.
Offset calculations are based on compensated real time rather then
uncompensated real time, which is why this is a problem. Frequency
corrections are based on uncompensated real time and do not have any
similar issue. It would be even better, but more difficult, to adapt
the offset correction code to use uncompensated real time and then take
the compensation into account, but this is a considerably more complex
equation to get right.
There is still another problem and that is the offset error will continue
to build when the frequency is not corrected, potentially resulting in a
longer sync-up time. On the positive side, the offset correction is based
on a standard deviation that only requires a minimum of 4 samples.
Correct a minor compiler warning.
|