[ILUG] [OT] C time_elapsed function

[Padraig Brady]

Kenn Humborg wrote:

>>kevin lyda wrote:
>>
>>
>>>On Tue, Nov 06, 2001 at 06:47:03PM +0000, Padraig Brady wrote:
>>>
>>>
>>>>Feck that. It would be easier to write a simple kernel module
>>>>to export /proc/seconds_since_boot
>>>>
>>>>
>>>again, what is the problem you're trying to solve?
>>>
>>>you seem to want a number that increments.  a thread could supply that.
>>>if it needs to cross process instances, you could use a sequence file.
>>>
>>Yes within process is trivial.
>>Across process a sequence file will not do as I need the correct
>>number of seconds since boot, not just a unique monotonically
>>increasing number (I'm writing a scheduling app).
>>doze had GetTickCount in 3.1!
>>
> 
> ... but GetTickCount() wrapped after 49.7 days.


LOL, shame on me for thinking doze would use a sensible size for this.


> Anyway, if you can guarantee that you will read the
> 32-bit jiffies counter at least once every 497 days,
> then simply watch for the new reading being less
> that the old and increment another 32-bit count.


But what if my app isn't running on the wrap around?

Hmm, I could write current BOOT_TIME & jiffies to file on startup,
and each startup check:

if (curr_BOOT_TIME == saved_BOOT_TIME && curr_jiffies <= saved_JIFFIES)
     handle_wrap_around();

messy, but not too bad.


> Note that, (at least in earlier versions of linux
> development kernels and maybe even now), Linus often
> preloads jiffies with a very high value (rather than
> zero) to force jiffy wraparound to happen much sooner,
> to force other kernel developers and driver writers
> to deal with wraparound properly.
> 
> So you probably can't trust the raw jiffies value anyway,
> only the delta between two readings.  Which is not much good
> if you need the "correct number of seconds since boot".


Delta is all that's required.



> Would the "correct number of seconds since the start of your
> scheduling app" be enough?


No this is trivial, and can be just implemented within my app.


> 
> Later,
> Kenn

thanks,
Padraig.