On Fri, Aug 24, 2018 at 2:45 PM, Mark Morgan Lloyd <markmll.fpc-pas...@telemetry.co.uk> wrote: > On 24/08/18 09:15, R0b0t1 wrote: >> >> On Thu, Aug 23, 2018 at 6:28 AM, Mark Morgan >> Lloyd<markmll.fpc-pas...@telemetry.co.uk> wrote:> On 23/08/18 10:00, Martin >> Schreiber wrote:>>>> On Thursday 23 August 2018 11:11:34 Bo Berglund wrote:> >> On Thu, 23 Aug>> 2018 09:00:07 +0200, Bo Berglund>> <bo.bergl...@gmail.com> >> wrote:> >I will>> need a higher resolution GetTickCount for this...>> Is >> there in fact a way>> (on Linux - Raspbian) to get a tickcount with> higher >> resolution than 1 ms?>>> On a mid-00s server I'm using >> clock_gettime(CLOCK_REALTIME which is> apparently better than 1uSec, but >> from previously looking at older PCs and> (I think) RPi3 your mileage may >> vary enormously. AIUI there's been a lot of> issues over the years with >> different cores not having their counters in> step, with counter frequency >> following dynamic clocks rather than being> fixed and so on.> >> There is clock_getres(2) to test this. > > > That shows the nominal resolution, not the actual rate that the counter is > updated. >
The counter is updated, generally, at its resolution; the implementation as far as I know reads the counter value directly which may be associated with hardware. What is more problematic is the scheduler's minimum timeslice. I couldn't exactly find a way to find it though it exists as a define in the Linux kernel, but that value may or may not be used as-is. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
