11

I see no such option for date

/proc/uptime is bootbased, not monotonic.

And at last I found cat /proc/timer_list | grep now which yields number of nsecs which is obtained via ktime_get which is returning monotonic time if I understand correctly, but that's quite cumbersome.

update: the returned value must be the same as returned by clock_gettime

ivan_pozdeev
  • 33,874
  • 19
  • 107
  • 152
Jan Matějka
  • 1,880
  • 1
  • 14
  • 31
  • 1
    what precision do you need? – Dru Sep 01 '13 at 04:54
  • 2
    So `/proc/uptime` is not monotonic? Is that a bug? – auselen Sep 02 '13 at 08:05
  • @Dru at the moment I'm not concerned about precision. Something subsecond I'd expect. – Jan Matějka Sep 03 '13 at 12:54
  • 5
    I'm sorry, seriously can't understand why uptime is not monotonic. – auselen Sep 03 '13 at 12:57
  • because it's bootbased – Jan Matějka Sep 03 '13 at 14:09
  • 3
    Unrelated. I would read definition of monotonic. – auselen Sep 03 '13 at 15:39
  • 1
    Are you looking for a monotonic behavior between reboots? – auselen Sep 03 '13 at 15:58
  • 2
    All global monotonic timers in Linux are boot based. Can you explain why boot-based is bad? – ash Sep 04 '13 at 04:49
  • bootbased keeps ticking during kind of "system sleep" - which I would also like to know what exactly that means. see kernel/time/timekeeping.c void monotonic_to_bootbased(struct timespec) – Jan Matějka Sep 04 '13 at 12:02
  • 4
    It seems you don't even **know** what you want. As for us, we don't even know why you need this value. I'm not even sure you know yourself. –  Sep 06 '13 at 15:12
  • Just as an extra `cat /proc/timer_list | grep now` is also boot based. And monotonic while your computer is up and running. If you want something monotonic across reboots, juste use `date` as suggested bellow. –  Sep 06 '13 at 15:17
  • `/proc/timer_list` is only readable by root since Linux v4.15 (8e7df2b5b7f245c9bd11064712db5cb69044a362), and it appears from https://lore.kernel.org/patchwork/patch/854817/ that it may go away altogether eventually. – Mike Crowe Oct 04 '18 at 08:46

3 Answers3

8

Looks like it's available in python 3.3: http://www.python.org/dev/peps/pep-0418/

Failing that, you could write a small C program which calls clock_gettime: http://linux.die.net/man/3/clock_gettime

We Are All Monica
  • 13,000
  • 8
  • 46
  • 72
7

This does not answer the current question but answers the original one. So, it is being kept as it has been useful to some people so far.

In shell you could just use the date utility:

date +%s.%N
date +%s%N
nanoseconds_since_70=$(date +%s%N)

From man date:

       %s     seconds since 1970-01-01 00:00:00 UTC
       %N     nanoseconds (000000000..999999999)

The nanoseconds portion complement the seconds in the right way: when %N goes from 999999999 to 0 the %s increments one second. I dont have a reference for that (please edit if you can found it) but just works.

date utility x clock_gettime

Note that the number is not affected by changes in time zone but will be affected by changes in the system clock, like the changes made by the system administrator, NTP and adjtime function. However the CLOCK_MONOTONIC in the clock_gettime function is also affected, except by the administrator changes.

 CLOCK_MONOTONIC -- Clock  that  cannot  be set and represents monotonic time
 since some unspecified starting point.  This clock is not affected by 
 discontinuous jumps in the system time (e.g., if the system administrator 
 manually changes the clock), but is affected by the incremental adjustments
 performed by adjtime(3) and NTP.

Newer system has a better solution: CLOCK_MONOTIC_RAW. Despite that, this is a shell solution as requested.

To know more

Monotonic function in Wikipedia

The @caf user answer from Difference between CLOCK_REALTIME and CLOCK_MONOTONIC?:

CLOCK_MONOTONIC represents the absolute elapsed wall-clock time since some
arbitrary, fixed point in the past. It isn't affected by changes in the 
system time-of-day clock. 

If you want to compute the elapsed time between two events observed on the one
machine without an intervening reboot, CLOCK_MONOTONIC is the best option.
olivecoder
  • 2,858
  • 23
  • 22
  • Please could you, who downvoted, add a comment? Maybe I could fix my mistake and improve the stackoverflow for ourselves. – olivecoder Sep 05 '13 at 11:30
  • This gives just the number of seconds since epoch. – Jan Matějka Sep 05 '13 at 11:34
  • To my knowledge this definition of monotonic is flawed in that it does not neccessarily is elapsed wall clocks. It doesn't even need to be in seconds. – Jan Matějka Sep 05 '13 at 11:35
  • the `man clock_gettime` does say "represents time since some unspecified starting point." but the starting point on linux is always the boot of the system (I'm not aware of any other possible starting point) – Jan Matějka Sep 05 '13 at 11:37
  • "This gives just the number of seconds since epoch.". Negative: this gives the number of nanoseconds since epoch. – olivecoder Sep 05 '13 at 11:47
  • "To my knowledge this definition of monotonic is flawed in that it does not neccessarily is elapsed wall clocks. It doesn't even need to be in seconds.". You have posted the question, so please clarify what is the monotonic time definitition you want. – olivecoder Sep 05 '13 at 11:49
  • "the man clock_gettime does say "represents time since some unspecified starting point." -- The man is not extensive enough, that is an incomplete definition. – olivecoder Sep 05 '13 at 11:50
  • "but the starting point on linux is always the boot of the system (I'm not aware of any other possible starting point)" -- yes there is. You can chose an arbitrary start point is use the current system clock to count. – olivecoder Sep 05 '13 at 11:53
  • @yaccz I am not here to challenge you, I was trying help. A perfect monotonic time should not be affected for changes in system clock and that is my failure. Depiste that my answer is so good as use clock_gettime because it is affected in the same way. – olivecoder Sep 05 '13 at 11:58
  • While your answer is correct considering the monotonic time definition in `man clock_gettime` it is more than useless considering timespec returned by clock_gettime as reference. – Jan Matějka Sep 05 '13 at 12:10
  • Sorry @yaccz but you are wrong again: The timespec returned by CLOCK_MONOTONIC is so useless as my suggestion. Please read the man. – olivecoder Sep 05 '13 at 12:20
  • So that is it... I've earned a downvote to give an answer so not perfect as CLOCK_MONOTONIC and working in shell as requested. – olivecoder Sep 05 '13 at 12:23
  • " A perfect monotonic time should not be affected for changes in system clock " by system clock I assume you mean wall clock, right? So, are you saying monotonic clock is affected by changes in wall clock? Can you back this claim with references? – Jan Matějka Sep 05 '13 at 12:31
  • By system clock I mean the linux system clock. If you change it using ntp my solution and CLOCK_MONOTIC will be affected if you change the time zone they will not. Do you really understand how it works? – olivecoder Sep 05 '13 at 12:34
  • Using the reference I provide you can see than o monotonic function could not decrease after have increased, so if you adjust your system time to time in the past your clock will be decreased. – olivecoder Sep 05 '13 at 12:36
  • Up voted. The time provided by this answer can not decrease so this is a monotonic clock. It is also accessible in shell. In two words: "problem solved". The problem is that you failed to define your problem which is a shame as olivecoder took a lot of his time to write this perfectly valid answer. See my comments above: a clock which is monotonic across reboots, this is just what olivecoder gave you. It is perfectly fine not knowing what you want, but just state it to let us fix your problem in a positive way. –  Sep 06 '13 at 15:20
  • @Gael That's monotonic clock in general sense while I was refering to CLOCK_MONOTONIC as returned by clock_gettime. I haven't realized someone would fail to recognize this and so updated the question accordingly. Also `date %s` is not really monotonic while CLOCK_MONOTONIC is. – Jan Matějka Sep 06 '13 at 16:51
  • @yaccz: sorry but I cant update my answer to fit your update. So I deserve a downvote for that? – olivecoder Sep 07 '13 at 15:34
  • @yaccz: as you stated it in your question, you specified that as an update because this was not obvious. If you want to access clock_gettime just use it! I'd bet that `date` **does** use it. I don't see why it wouldn't. And again, you prove that you really don't know what you are talking about: why do you consider `date +%s` not monotonic? **State your reason.** Tell us the difference! –  Sep 09 '13 at 16:49
  • I almost want to downvote for the giant paragraph begging for no downvotes. Just answer the question to your best ability and accept your fate sir. Some downvotes come from other answerers who simply want their answer to be better. It happens. – Jesse Sep 21 '18 at 15:26
  • I agree @Jesse this looks awful now and I'm going to remove it. However, I think it was necessary at that time as the question changed making a previously perfect valid answer invalid. So, that wasn't about accepting my fate but was just unfair to get downvotes without even a comment. Of course I could have just removed my answer but I kept it as it was seeming like it was being useful to other people. – olivecoder Sep 24 '18 at 09:50
  • It's really subtle, but `CLOCK_MONOTONIC` cannot jump, because `adjtime` slews the clock (runs it faster or slower by a small percentage). This actually means that `CLOCK_MONOTIC_RAW` is not "better" because `CLOCK_MONOTONIC` is more likely to tick accurate [mili]seconds and be monotonic while under the watchful eye of `ntpd` or `chrony`. CLOCK_MONOTONIC_RAW on the other hand would be much more prone to jitter and drift despite being monotonic. – Philip Couling Apr 21 '23 at 21:58
7

Consulting /proc/uptime is only cumbersome if you write out the full line each time. Why not wrap it up like this:

$ alias now="awk '/^now/ {print \$3; exit}' /proc/timer_list"
$ now
396751009584948

This also avoids the Useless Use of cat.

PhilR
  • 5,375
  • 1
  • 21
  • 27
  • 2
    yep. That's the cumbersome. – Jan Matějka Sep 07 '13 at 15:50
  • 1
    Considering the syscall overhead, it's not that much worse than a binary calling clock_gettime(2). From a programming point of view, it's a single-word command to get the info wanted. I don't see the cumbersome, sorry. – PhilR Sep 07 '13 at 17:36
  • 2
    Of the answers here, this is the one that actually answered my question. Thanks! – Mike Andrews Feb 08 '17 at 23:13
  • Minor improvement if you want seconds: `awk '/^now/ {print substr($3, 1, length($3) - 9); exit}' /proc/timer_list` – SimonAlfie Jun 13 '17 at 09:40
  • Unfortunately this requires root: `-r-------- 1 root root 0 ... /proc/timer_list` – i336_ Jun 09 '20 at 15:13