[quagga-dev 5867] Re: Monotonic time, RFC
Joakim.Tjernlund at transmode.se
Tue Sep 2 17:23:43 BST 2008
> -----Original Message-----
> From: paul at clubi.ie [mailto:paul at clubi.ie]
> Sent: den 2 september 2008 16:10
> To: Joakim Tjernlund
> Cc: quagga-dev at lists.quagga.net
> Subject: RE: [quagga-dev 5840] Monotonic time, RFC
> On Tue, 2 Sep 2008, Joakim Tjernlund wrote:
> > Perhaps, but somehow I got the feeling that you aren't going to enable
> > this any time soon and I am still unsure if CLOCK_MONOTONIC is
> > supported on older linux.
> I'll happily push the required configure.ac patch.
Please do, but that still leaves Linux 2.4, can't find any support
for CLOCK_MONOTONIC in there, guess who still has such beasts in production :(
> > hmm, don't quite follow. 1/clocks_per_sec is zero with integer math.
> Right, you obviously may need to scale things up and down with shifts
> to keep things in bounds for integer math ("accurately work out" was
> meant to hint at that). The point is, do the divide at init-time so
> the frequent-case only has to multiply - standard trick.
> However, lets not add more hacks, lets just enable the POSIX
> monotonic clock support.
> There aren't even *any* bugs being addressed here. AFAIK everything
> works just fine with the existing delta-ticking, monotonic timer.
> So we're just wasting energy here..
If 2.4 supported CLOCK_MONOTONIC, then yes, a waste. Since not
all platforms can move to the new impl. I think it should be fixed.
There is some problem with clock jumps still in OSPF as your commit outlined.
I don't think OSPF should be tweaked to deal with clock jumps, it should
not need to bother. Instead the clock jumps should be eliminated.
The current api for relative time is not very optimal for using times(2) but
it can be made to work with little effort. Perhaps it can be streamlined not
to do too much math, but I havn't looked into how much code that needs to
More information about the Quagga-dev