1181834Srobertoadjtime, tick and tickadj: 2181834Sroberto-------------------------- 3181834Sroberto 4181834SrobertoThe SGI value for HZ is 100 under Irix 4, with the system clock running 5181834Srobertoin nominal mode (ftimer off), so the value for tick is 10000 usec. 6181834SrobertoTickadj is a bit more tricky because of the behaviour of adjtime(), 7181834Srobertowhich seems to try to perform the correction over 100-200 seconds, with 8181834Srobertoa rate limit of 0.04 secs/sec for large corrections. Corrections of 9181834Srobertoless than 0.017 seconds generally complete in less than a second, 10181834Srobertohowever. 11181834Sroberto 12181834SrobertoSome measured rates are as follows: 13181834Sroberto 14181834Sroberto Delta Rate (sec/sec) 15181834Sroberto 16181834Sroberto > 1 0.04 17181834Sroberto 0.75 0.04 18181834Sroberto 0.6 0.004 19181834Sroberto 0.5 0.004 20181834Sroberto 0.4 0.0026 21181834Sroberto 0.3 0.0026 22181834Sroberto 0.2 0.0013 23181834Sroberto 0.1 0.0015 24181834Sroberto 0.05 0.0015 25181834Sroberto 0.02 0.0003 26181834Sroberto 0.01 0.015 27181834SrobertoStrange. Anyway, since adjtime will complete adjustments of less than 28181834Sroberto17msec in less than a second, whether the fast clock is on or off, I 29181834Srobertohave used a value of 150usec/tick for the tickadj value. 30181834Sroberto 31181834SrobertoFast clock: 32181834Sroberto----------- 33181834Sroberto 34181834SrobertoI get smoother timekeeping if I turn on the fast clock, thereby making 35181834Srobertothe clock tick at 1kHz rather than 100Hz. With the fast clock off, I 36181834Srobertosee a sawtooth clock offset with an amplitude of 5msec. With it on, 37181834Srobertothe amplitude drops to 0.5msec (surprise!). This may be a consequence 38181834Srobertoof having a local reference clock which spits out the time at exactly 39181834Srobertoone-second intervals - I am probably seeing sampling aliasing between 40181834Srobertothat and the machine clock. This may all be irrelevant for machines 41181834Srobertowithout a local reference clock. Fiddling with the fast clock doesn't 42181834Srobertoseem to compromise the above choices for tick and tickadj. 43181834Sroberto 44181834SrobertoI use the "ftimer" program to switch the fast clock on when the system 45181834Srobertogoes into multiuser mode, but you can set the "fastclock" flag in 46181834Sroberto/usr/sysgen/master.d/kernel to have it on by default. See ftimer(1). 47181834Sroberto 48181834Srobertotimetrim: 49181834Sroberto--------- 50181834Sroberto 51181834SrobertoIrix has a kernel variable called timetrim which adjusts the system 52181834Srobertotime increment, effectively trimming the clock frequency. Xntpd could 53181834Srobertouse this rather than adjtime() to do it's frequency trimming, but I 54181834Srobertohaven't the time to explore this. There is a utility program, 55181834Sroberto"timetrim", in the util directory which allows manipulation of the 56181834Srobertotimetrim value in both SGI and xntpd native units. You can fiddle with 57181834Srobertodefault timetrim value in /usr/sysgen/master.d/kernel, but I think 58181834Srobertothat's ugly. I just use xntpd to figure out the right value for 59181834Srobertotimetrim for a particular CPU and then set it using "timetrim" when 60181834Srobertogoing to multiuser mode. 61181834Sroberto 62181834SrobertoSerial I/O latency: 63181834Sroberto------------------- 64181834Sroberto 65181834SrobertoIf you use a local clock on an RS-232 line, look into the kernel 66181834Srobertoconfiguration stuff with regard to improving the input latency (check 67181834Srobertoout /usr/sysgen/master.d/[sduart|cdsio]). I have a Kinemetrics OM-DC 68181834Srobertohooked onto /dev/ttyd2 (the second CPU board RS-232 port) on an SGI 69181834SrobertoCrimson, and setting the duart_rsrv_duration flag to 0 improves things 70181834Srobertoa bit. 71181834Sroberto 72181834Sroberto 73181834Sroberto12 Jan 93 74181834SrobertoSteve Clift, CSIRO Marine Labs, Hobart, Australia (clift@ml.csiro.au) 75