home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-385-Vol-1of3.iso / x / xntp3.zip / xntpd / ASSUMPTIONS next >
Text File  |  1991-09-28  |  2KB  |  49 lines
  1. * (peer->flags & PEER_CONFIG) iff (peer->hmode in {1, 3, 5})
  2.  
  3. * sys.clock in 3.4.9 == sys.poll in 5.2
  4.   sys.update in 3.4.9 == sys.clock in 3.2.2
  5.  
  6. * It's valid to drop packets from a broadcaster when in active or
  7.   client modes
  8.  
  9. * The new algorithm for dropping packets + the reach/valid rules
  10.   subsumes the peer->trust/poll stuff, so it goes away.
  11.  
  12. * The test for stratum 1 near the end of leap_process is wrong.
  13.  
  14. * leap indicator, stratum and refid follow sys_peer (best selected
  15.   clock). Currently only packets from sys_peer update reftime and the
  16.   local clock --- should it be every packet from a selected peer?
  17.  
  18. * It is no longer a good idea to drop skew update on short intervals
  19.   (note that the update is now multiplied with interval length, not
  20.   divided as in version 2). This is especially true when there are
  21.   multiple update sources (see previous).
  22.  
  23. * peer.dispersion_{index[i]} means \epsilon_i at bottom of page 35.
  24.  
  25. * In clock_select, the test on reach subsumes the old tests on trust,
  26.   delay and stratum.
  27.  
  28. * NTP_SKEWFACTOR will stay equal to 16, so the result in a u_fp is
  29.   just the second part of the interval.
  30.  
  31. * The code in appendix I does not add peer->rootdelay at the places
  32.   that correspond to calls of dist() in the body of the report; it
  33.   doesn't take the absolute value either. We do both, anyway.
  34.  
  35. * Also, even though appendix I calls combine(), it calculates system
  36.   variables based on sys_peer values (including offset), so that's
  37.   what we'll do too.
  38.   Though we'll use sys_peer's select dispersion instead of the
  39.   largest retained one.
  40.  
  41. * The test for "peer passes test 1 to 8" is implemented as a test on
  42.   peer->reach, because no indication is kept of a data invalid event.
  43.   By the way, what happens if a peer in the synch. set starts failing
  44.   data validity consistently? No calls to clock_filter, so it'll just
  45.   stick there until the skew forces its dispersion high.
  46.  
  47. * The descriptions for peer selection status 2 and 3 are weird. For now,
  48.   2 means goes into intersection, 3 means survives.
  49.