Displayed update timestamps vary by 1 second for the exact same update

[Ondrej Zajicek]

On Fri, Nov 26, 2021 at 07:51:21AM +1100, bird21 at sensation.net.au wrote:
> Hi all,
> 
> If I do several consecutive "show route" queries, the timestamp keeps
> changing back and forth, by about a second. Example:
> 
> 0.0.0.0/0          via x.x.x.x on em2.100 [aapt 05:20:28] * (100) [AS2764i]
> 0.0.0.0/0          via x.x.x.x on em2.100 [aapt 05:20:28] * (100) [AS2764i]
> 0.0.0.0/0          via x.x.x.x on em2.100 [aapt 05:20:27] * (100) [AS2764i]
> 0.0.0.0/0          via x.x.x.x on em2.100 [aapt 05:20:28] * (100) [AS2764i]
> 
> I notice (via public route servers) that Quagga and FRRouting seem to do the
> same thing. Example:
> 
>       Last update: Thu Nov 25 18:20:31 2021
>       Last update: Thu Nov 25 18:20:30 2021
>       Last update: Thu Nov 25 18:20:30 2021
>       Last update: Thu Nov 25 18:20:31 2021
> 
> Does Bird do this in order emulate some convention (like perhaps something
> Cisco has done for decades), or is there some other reason it's displaying
> an inconsistent timestamp?

Hi

The reason is that the timestamp is stored in monotonic time and is
recomputed to wall-clock time during printing, and all these computations
are done with precision of seconds, so the difference between monotonic
time and wall-clock time is sometimes rounded down, sometimes up.

In BIRD 2.0, time computations use microsecond precision (while printed
values are rounded to milliseconds), so these rounding effects are much
less visible.


> I have a script that compares the md5 of the current output with the
> previous minute to decide whether to log the routing table, but because of
> this quirk the md5 changes almost every time...

You could use sed expression to remove the timestamp. We use something
similar in our testing setup to normalize output to canonical format to
see whether we get the same result as expected.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."