[comp.protocols.time.ntp] xntpd

jmattson@UCSD.EDU (Jim Mattson) (05/04/91)

On a machine listening to broadcast ntp, where the broadcast delay is set to
0.06 seconds, xntpdc sysinfo shows:

broadcast delay:  0.000000915490

(On the same machine, if no broadcast delay is specified, xntpdc sysinfo
shows the expected default: broadcast delay:  0.007999999914)

It seems that the broadcast delay parameter should be handled the same way
as the authdelay parameter, so I took the code from there, and now it seems
to work.

--jim

BTW, I chose 0.06 seconds because that was the delay xntpdc reported when I
was running as a peer rather than a broadcast client.  Is this value
meaningful?  It seems odd that it's an order of magnitude higher than the
default value.

*** /tmp/RCSAa09736	Sat May  4 00:11:08 1991
--- ntp_config.c	Sun Apr 28 16:05:03 1991
***************
*** 394,400 ****
  		case 'r':
  			do {
  				l_fp tmp;
- 				u_fp utmp;
  
  				if (!atolfp(optarg, &tmp)) {
  					syslog(LOG_ERR,
--- 394,399 ----
***************
*** 405,412 ****
  			 "command line broadcast delay value %s is unlikely",
  					    optarg);
  				} else {
! 					utmp = LFPTOFP(&tmp);
! 					proto_config(PROTO_BROADDELAY, utmp);
  				}
  			} while (0);
  			break;
--- 404,410 ----
  			 "command line broadcast delay value %s is unlikely",
  					    optarg);
  				} else {
! 					proto_config(PROTO_BROADDELAY, tmp.l_f);
  				}
  			} while (0);
  			break;
***************
*** 734,740 ****
  		case CONFIG_BDELAY:
  			if (ntokens >= 2) {
  				l_fp tmp;
- 				u_fp utmp;
  
  				if (!atolfp(tokens[1], &tmp)) {
  					syslog(LOG_ERR,
--- 732,737 ----
***************
*** 745,752 ****
  					  "broadcastdelay value %s is unlikely",
  					    tokens[1]);
  				} else {
! 					utmp = LFPTOFP(&tmp);
! 					proto_config(PROTO_BROADDELAY, utmp);
  				}
  			}
  			break;
--- 742,748 ----
  					  "broadcastdelay value %s is unlikely",
  					    tokens[1]);
  				} else {
! 					proto_config(PROTO_BROADDELAY, tmp.l_f);
  				}
  			}
  			break;
*** /tmp/RCSAa09744	Sat May  4 00:11:24 1991
--- ntp_proto.c	Sun Apr 28 16:08:03 1991
***************
*** 1921,1927 ****
  		/*
  		 * Set default broadcast delay
  		 */
! 		sys_bdelay = (u_fp)value;
  		break;
  	
  	case PROTO_AUTHENTICATE:
--- 1921,1927 ----
  		/*
  		 * Set default broadcast delay
  		 */
! 		sys_bdelay = (((u_long)value) + 0x00000800) & 0xfffff000;
  		break;
  	
  	case PROTO_AUTHENTICATE:

saf@ATHENA.MIT.EDU (05/09/91)

I have been trying to do a test run for xntpd here at MIT at the Media Lab.
I have everything set up. I have root running xntpd and so on.  My configuration file for the current test machine is ...

peer 18.72.0.3  key 1   # bitsy.mit.edu
peer 130.105.1.156 key 2        # clock.osf.org
peer 128.118.25.3 key 3 # clock.psu.edu

authneticate yes
trustedkey 1 2 3
keys /etc/ntp.keys
authdelay 0.000323
requestkey 65535 # for mode 7 request
driftfile /etc/ntp.drift
moniter yes

the problem is that I cannot get any updating of the clock when I run it.
All I am gettin from ntpq is ...

 BITSY.MIT.EDU   0.0.0.0         16 never   64    0     0.0    0.00  64000
pmax6.osf.org   0.0.0.0         16 never   64    0     0.0    0.00  64000
otc2.psu.edu    0.0.0.0         16 never   64    0     0.0    0.00  64000


I wonder if you could shed some light on what the problem could be.

The drift file is also not being updated.  Do I have to add some more configeration or notify the peers before I can get this thing to strart working?

I got the software by ftping into louie.udel.edu.  

Safroadu.
Student Researcher At the Media Lab.
MIT.