>Number:         21406
>Category:       port-sparc64
>Synopsis:       ntpd acting strange in 1.6.1 sparc64?
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-sparc64-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Apr 30 14:32:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Frank Kardel
>Release:        NetBSD 1.6.1
>Organization:
	
>Environment:
	
	
System: NetBSD mephisto 1.6.1 NetBSD 1.6.1 (GENERIC) #0: Mon Apr 7 10:27:16 UTC 2003 autobuild@cs20.apochromatic.org:/autobuilder/build/netbsd-1-6/sparc64/OBJ/autobuilder/build/netbsd-1-6/src/sys/arch/sparc64/compile/GENERIC sparc64
Architecture: sparc64
Machine: sparc64
>Description:
	I just set up an U10 clone (Tritec) with 1.6.1 from the multi1cd.iso.
	I do see strange ntpd behaviour in the output from ntpq wrt/ time values:
	It seems the the daemon delivers 0x7fffffff for the fractional part
	of the time stamp when i actually should have its high bit set. 
	e.g.
status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
processor="sparc64", system="NetBSD1.6.1", leap=00, stratum=2,
precision=-15, rootdelay=0.062, rootdispersion=828.563, peer=58412,
refid=satan.acrys.com,
reftime=c25a2563.7fffffff  Wed, Apr 30 2003 12:35:15.500, poll=6,
clock=c25a258a.66ed1394  Wed, Apr 30 2003 12:35:54.402, state=3,
phase=516.607, frequency=500.000, jitter=313.228, stability=166.527

status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
processor="sparc64", system="NetBSD1.6.1", leap=00, stratum=2,
precision=-15, rootdelay=0.062, rootdispersion=828.728, peer=58412,
refid=satan.acrys.com,
reftime=c25a2563.7fffffff  Wed, Apr 30 2003 12:35:15.500, poll=6,
clock=c25a2595.7fffffff  Wed, Apr 30 2003 12:36:05.500, state=3,
phase=516.607, frequency=500.000, jitter=313.228, stability=166.527

status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
processor="sparc64", system="NetBSD1.6.1", leap=00, stratum=2,
precision=-15, rootdelay=0.062, rootdispersion=828.923, peer=58412,
refid=satan.acrys.com,
reftime=c25a2563.7fffffff  Wed, Apr 30 2003 12:35:15.500, poll=6,
clock=c25a25a2.7fffffff  Wed, Apr 30 2003 12:36:18.500, state=3,
phase=516.607, frequency=500.000, jitter=313.228, stability=166.527

	Accessing a daemon on i386 does not show this behaviour.

status=0294 leap_none, sync_lf_clock, 9 events, event_peer/strat_chg,
processor="i386", system="NetBSD1.6E", leap=00, stratum=1,
precision=-18, rootdelay=0.000, rootdispersion=2.910, peer=41060,
refid=DCFa, reftime=c25a2632.08a91537  Wed, Apr 30 2003 12:38:42.033,
poll=6, clock=c25a2636.207f1305  Wed, Apr 30 2003 12:38:46.126, state=4,
phase=0.359, frequency=11.454, jitter=0.006, stability=0.074

status=0294 leap_none, sync_lf_clock, 9 events, event_peer/strat_chg,
processor="i386", system="NetBSD1.6E", leap=00, stratum=1,
precision=-18, rootdelay=0.000, rootdispersion=1.943, peer=41060,
refid=DCFa, reftime=c25a26b2.08b84988  Wed, Apr 30 2003 12:40:50.034,
poll=6, clock=c25a26b4.d431df76  Wed, Apr 30 2003 12:40:52.828, state=4,
phase=0.094, frequency=11.492, jitter=0.005, stability=0.066
	Here a fractional part having the high bit set is reported
	correctly. That takes ntpq out of the equation.

	The ntpd makes the common assumption the int32 arithmetic is mod 2^32.
	The fractional parts i see look like a clamping strategy where overflows
	are clamped to the maximum representable value. But it could also be a 
	conversion error in the mode 6 output code.

>How-To-Repeat:
	Let ntpd run in sparc64. Watch the clock value by ntpq -c rv

>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: