Re: QueryPerformanceCounter() on multiprocessor???

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance




"Arkady Frenkel":
<maruk2@xxxxxxxxxxx> wrote in message

OTOH I see that point 3 in paragraph "Background" contradict to
point 5 in paragraph "Recommendations"

The background section talks about about floating CPU-frequency, that
implies inconsitent CPU-cycle intervalls. This doesn't necessarily
change the APIs timer precision, because the system could take
changes in CPU-frequency into account (or even use a CPU-independent
timing source).

How the "main thread" would update the timestamp? The timestamp would
have to be continuously updated by the "main thread" or updated on
demand.

If the system doesn't have any high precision timing sources other than
the one built into the CPUs, it will probably prefer to choose one
specific CPU as source, to avoid incorrectness depending on wich
CPU calls the timing API.
So if thread actually running on a non-timing-source CPU attempts
to read the timestamp, it might be either moved to the timig-CPU,
or at least interupt the timing-CPU to instruct it to deliver
the timestamp.

I'm quite sure that Chuck Walbourn didn't mean you should use a
timestamp-reader-thread, that continiously read the timer to
write the result to some global variabe.

Perhaps better read it like "Avoid having all threads rely on
timestamp-reads. Be prepared for scenarios, where threads that
read timestamps can only be executed on a specific core".

Gruss

Jan Bruns
.



Relevant Pages

  • Re: bug in sched.c:task_hot()
    ... > Peter Williams wrote: ... I assumed that was why all the "timestamp correction on changing CPU" ...
    (Linux-Kernel)
  • [PATCH] softlockup detection vs. cpu hotplug
    ... I'm able to trigger bogus softlockup warnings during cpu hotplug ... the cpu starts servicing timer interrupts. ... Before starting a cpu's watchdog thread, touch the cpu's timestamp to ...
    (Linux-Kernel)
  • Re: [2.6.16-mm1 patch] throttling tree patches
    ... task with a computed timestamp, stamp with the already called clock. ... As far as I can remember I only ever saw this when measuring "delay" (i.e. time on the run queue waiting to get on to a CPU which can be quite short :-) when the systems not heavily loaded) as other time intervals that I measure are generally long enough for the error in the delta not being big enough to make the value negative. ... I think that the original code which used the computed "now" was correct as otherwise the task's timestamp will not have the correct time for its CPU. ... PPS I'm not sure that the timstamp adjustment in __migrate_taskis completely valid as the timestamp will be modified in activate_taskusing the wrong clock. ...
    (Linux-Kernel)
  • Re: [PATCH]: Fix bogus softlockup warning with sysrq-t
    ... happens if you do a global re-enable while a CPU is locally disabled. ... think it won't matter; it will end up in the "enabled but need to update ... update the timestamp and carry on. ... (This is relative to the other two softlockup patches, ...
    (Linux-Kernel)
  • Re: Java MIDI message problem
    ... Java Sound Programmers Guide suggests to put -1 as the ... timestamp is you dont care about timing. ... "You can use -1 for the timeStamp argument to indicate that you don't ...
    (comp.music.midi)