Date: Thu, 21 Jul 2022 01:35:42 +1000 From: Ian Smith <smithi@nimnet.asn.au> To: questions@freebsd.org,Steve O'Hara-Smith <steve@sohara.org>,freebsd-doc@fjl.co.uk Subject: Re: How do get elapsed time in milliseconds in a shell script? Message-ID: <AA2BA237-56E3-4331-BFA8-E8EBDA2F33F8@nimnet.asn.au> In-Reply-To: <20220718154227.0b56d2e08c41b1849769c49f@sohara.org> References: <b2107a6a-7b58-9e26-63f4-6a4c71393e2c@panix.com> <20220712194432.AA49E458B955@ary.qy> <20220712205754.928c3f921f42f66fb977f891@sohara.org> <77a16f8f-a70a-3abf-02be-70b1d252bd36@iecc.com> <735428d6-aeeb-2539-c1fa-aee0baf2506e@fjl.co.uk> <20220718154227.0b56d2e08c41b1849769c49f@sohara.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19 July 2022 12:42:27 am AEST, Steve O'Hara-Smith <steve@sohara=2Eorg> w=
rote:
> On Mon, 18 Jul 2022 14:01:01 +0100
> freebsd-doc@fjl=2Eco=2Euk wrote:
>=20
> > I think what may be needed is a base utility to produce the
> accurate=20
> > tick since the epoch or boot - it doesn't' matter for timeing=2E
> Possibly=20
> > an extension to "uptime", which I assume must know=2E
>=20
> There are some counters exposed via sysctl which might be useful,
> kern=2Etimecounter=2Etc=2EHPET=2Ecounter looks promising, the rest seem=
to
> cycle
> rather quickly=2E Of course portability is an issue with using these=2E
I must admit to being puzzled as to the efficacy of looking for millisecon=
d precision for event timing or uptime on a non-realtime OS, when there are=
so many things that bend time going on=2E Sure, the kernel has a pretty g=
ood idea of what's what and when's when, but out here in userland it's pret=
ty fluid=2E
One's system may have a good lock to network time, at boot anyway, but onc=
e we're talking about something that can be called up in a script, anything=
past 100ms is slippery=2E
In concord about HPET being the likely best timecounter for this, if it's =
also on non-Intel systems? So I've had a bit of a play in the script below=
=2E HPET wraps at ~300 seconds, so anything longer term has to be driven b=
y interrupts off that=2E We have kernel hackers for that =2E=2E=2E
Anyway, I think running this should illustrate, if nothing else, the vagar=
ies of userland timesharing especially in scripts=2E This tested on 12=2E3=
-RELEASE, 2=2E6GHz i5 3320M, otherwise idle=2E
Also, csh's time command already reports millisecond system and user times=
, with decisecond elapsed time for process timing; it's in base; and can be=
invoked from sh by such as
$ csh -c 'time sh -c "${myscript}"'
cheers, Ian
* tabs may not survive pasting
<code>
#!/bin/sh
# kern=2Etimecounter=2Etc=2EHPET=2Efrequency: 14318180 period: 69=2E841ns
# kern=2Etimecounter=2Etc=2EHPET=2Emask: 4294967295 repeat: 299=2E966s
period=3D69=2E841 # ns
[ "$1" ] && j=3D"$1" || j=3D25
j=3D$((j+1))
for i in `jot - 1 $j`; do
this=3D`sysctl -n kern=2Etimecounter=2Etc=2EHPET=2Ecounter`
if [ $i -eq 1 ]; then
echo "this prev step msec"
else
step=3D`echo "scale=3D12; $this - $prev" | bc`
msec=3D`echo "scale=3D3; $step * $period / 10^6" | bc`
echo "$this $prev $step $msec"
fi
prev=3D$this
done
exit 0
</code>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AA2BA237-56E3-4331-BFA8-E8EBDA2F33F8>