wapp clock drift.

19apr05

The time on the wapps has been drifting when pulsar datataking is run. The ntp time synchronization system is run and tries to correct for this. On 19apr05 the ntpd daemon was stopped and measurements were made to see how much the wapp clock drifted by itself.
To measure the drifts a program (testClk) was written that:

query the wapp time stamp counter (counts cpu clock).
send a request to da computer asking for the current time (accurate to usecs)
query wapp time stamp counter
call gettimeofday on wapp to read current time.
print out the da time, wapp time, time to make dacall, and the difference in da-wapp time.

When called, the time to make the da call was around 1e6 to 2e6 cycles. With a 1 Ghz clock, this was about a 1 millisecond error. The table below shows the results

time hh:mm:ss	event	datime seconds	wapptime seconds	diff secs	jump secs
15:30:39	time with ntpd off	39.001	39.002	-.001
15:31;45	start wapps running
15:33:0	start snap on wapp4
15:35:05	stopped data taking
15:35:20		21.000	20.702	.298	.299
15:38:00	start wapps, no snap running
15:42:09	stopped data taking	9.891	9.574	.317	.018
16:02:38	dd if=/dev/zero of=/export/wapp41/junk transfer 6gb of data
16:08:04	done with xfer	4.897	4.571	.326	.009
16:14:00	dd dev/zero to /tmp/junk 200 mb
16:15:26		26.465	26.141	.324	-.002
	dd dev/zero to /tmp/junk 1.2 gb transferred
16:21:20		20.416	20.037	.379	.055

Between the actions i measured the time and it remained stable.
The largest jump was when pulsar data taking (p2030 setup) was run with snap on wapp4. This caused a 300 ms jump. Transferring files /tmp (which is a journaled file system) cause a jump of about 55 ms.

When snap and data taking was run, the dual processor cpu was 68% busy on both cpus.

The slowing down must be coming from lost timer interrupts.

logging:x101/ntp/19apr05.log
home_~phil