Re: Privilege Levels Below User

On 6/8/2024 7:29 PM, MitchAlsup1 wrote:

BGB wrote:
 

On 6/8/2024 11:01 AM, EricP wrote:

Scott Lurndal wrote:

John Savard <quadibloc@servername.invalid> writes:

 

Though, the time returned by the CPUID microsecond timer is not currently the same as the one given by "TK_GetTimeUS()", where the latter effectively gives a 64-bit value (conceptually) representing the
>
number of microseconds since 1/1/1970; though with the kernel currently
>
assuming that its build-time is the starting time for the clock (and none of the FPGA boards support a hardware clock, and one would need internet access to use NTP, ...).

 

A 64-bit value in microseconds can express around +/- 300k years, which
>
should be plenty.

 What do you do when you need a 200 picosecond timer ?? (5GHz cycle
counter)
 

For most use cases where you need the date and time, one does not need picoseconds.
Something like a 1us resolution is sufficient for both "what is the current calandar date" and "how much time has elapsed" for most applications.
But, yeah, a 128-bit time value could express both picoseconds and the current age of the universe.
But, we don't need 128 bits for things like time and date stamps in a filesystem.
OTOH: A 32-bit value in seconds will overflow in 2038, so isn't really sufficient at this point.
Similarly, a microsecond counter is often useful, but a 32-bit signed-int counter will overflow in around 34 minutes or so, and this is a short enough timescale as to overflow many times over in the runtime of typical applications (full wraparound roughly once every 68 minutes).
Whereas, 64-bit microseconds-since-epoch addresses both use-cases at the same time.
And, for a 64-bit microsecond timer, if anyone is still around in 300k years, they can come up with a solution. Going by historical precedent, the calendar will have been replaced several times over by then.
Like, chances are people aren't going to still be using the Gregorian calendar in Jan 1, 300970 ...

A 64-bit value expressed in seconds could express values relative to
the
current age of the universe, but this is likely unnecessary for most purposes, and ability to express fractions of a second is likely more useful than the ability to express the age of the universe.

 Interesting factoid::
The universe is currently 10^80 Plank times old since Big Bang,
and universe will die around 10^80 years,
and there are about 10^80-10^88 particles in the universe.
 

Granted, one could use a 128-bit value, and have both (and in picoseconds if they wanted). But, this would be overkill.

 

Or, go extra overkill, and use 256 bits, to express the current age of the universe in Planck units...

 160-bits will be shown to be sufficient to count Plank times.

Yeah, but 160 is not a power of 2, so one can pad up to 256 bits.
It doesn't fit into a 128-bit value though, in any case.
Where, one could represent the whole age of the universe, but probably only in picoseconds or femtoseconds.
Would be needless overkill for a filesystem or database though...