patchCERTI - Patches: patch #6946, Add an other clock, and reorder...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

patch #6946: Add an other clock, and reorder preference

Submitter:  Mathias Fröhlich <frohlich>
Submitted:  Mon 12 Oct 2009 04:42:36 PM UTC
   
 
Category:  CERTI Priority:  5 - Normal
Status:  Ready For Test Privacy:  Public
Assigned to:  erk Open/Closed:  Closed

Wed 21 Oct 2009 10:51:31 AM UTC, comment #5: 

Will be in 3.3.3

Eric NOULARD <erk>
Group administrator
Fri 16 Oct 2009 09:44:35 PM UTC, comment #4: 

Provided patch now in CVS HEAD.
Thank you Mathias.

Eric NOULARD <erk>
Group administrator
Thu 15 Oct 2009 09:04:22 AM UTC, comment #3: 

Hi Mathias,

I understand your argument
and I'll add some warning inside the TSCClock code.
And yes it is currently Linux specific.
I do agree that modern implementation of clock_gettime
should stay away from syscall.

Some system like Solaris do have such non-syscall function
from about 10+ years:
http://docs.sun.com/app/docs/doc/816-5168/gethrtime-3c?a=view
(we could write GethrtimeClock for that).

Let's say that until we are confident that most system
(used by CERTI users) do have appropriate clock_gettime we could
keep the TSCClock inside the source tree (with appropriate warning) as soons as this is not the default option the user
using it will be fully aware of what he is doing.

I'll check more reference on the TSC varying frequencies
for any kind of machine types.
However I think that currently
powersaving does not fits well with hard realtime, even if it's an interesting research subject: what are the impact of powersaving method on realtime task.

I'll merge the patch soon (probably today).

Eric NOULARD <erk>
Group administrator
Thu 15 Oct 2009 06:13:04 AM UTC, comment #2: 


Hi,

Attached is an updated set including the test and the configure time option for the tsc.

For the record, I would still strongly advise against the tsc.

  • The tsc rate changes not even on laptops. Since a few years all cpus, desktop and server change their frequencies for powersaving reasons. This is triggered by much more opportunities that you have cited. The final key argument here is not to cite the places where this can happen, but that you cannot see when and to which frequency this happens from userspace. So on almost all hardware starting from the days somewhere at Pentium III the tsc may stop, or change its frequency in an unpredictable way.
  • The current implementation just works on linux - requires /proc/cpuinfo. So arguing for any other os makes no sense currently. But on linux with glibc >= 2.8 (I believe, may be way earlier), we have a way to avoid jumping into the kernel to get a timestamp. What happens here is that you get a memory page mapped into userspace that contains some data that is sufficient to get timestamps for example. You may have wondered why you do not any longer see gettimeofday syscalls in strace - this is the reason. The clock_* stuff is handled the same. Which means this is fast and *reliable*.
  • Having that in source suggests a user that it might be a good idea to use that option. Even more if this is a configure option.


Anyway, as already stated - the patch contains your wishes.

Greeting

Mathias

(file #18882, file #18883, file #18884)

Mathias Fröhlich <frohlich>
Mon 12 Oct 2009 10:59:29 PM UTC, comment #1: 

Hi Matthias,

GettimeofdayClock is good as a failover if
nothing better is available.
However NEVER use gettimeofday in a realtime simulation,
this is a syscall that will may ruin performance
if called too often and its usage will change
scheduling behavior on most Unix for sure.

Concerning TSC your are right it may vary for power saving
reason (mostly on laptop-grade computer though)
however in realtime context usage I do not expect
the processors to be stated in ANY powersaving powerstate.
On linux you may even use cpufreq-utils
http://www.kernel.org/pub/linux/utils/kernel/cpufreq/cpufrequtils.html
in order to control frequency variation.

see there too:
http://developer.amd.com/documentation/articles/Pages/1214200692.aspx

My two processors opteron doesn't even have cpufreq
capability, processors are always running at their
full "nominal" speed.

TSC brings other problems on multicore processors
because it's not a serializing instruction:
http://gala.univ-perp.fr/~goossens/Rec/pleumeur-bodou0309.pdf
(the presentation is in french sorry).

In the end RDTSC is nevertheless one of the cheapest
syscall-free way to measure time, granted you know
in which context you can effectively use it without trouble.

So you are right, it shouldn't certainly be the
default choice *but* I won't suppress it from
the source tree either :-)

So I'm basically OK with your change even if I'll certainly
add some way to force back to TSC when available using
some build option.

Howeverr I'd like you to add a small test for
the GettimeofdayClock.

You can add it with the other in:
certi/test/utility/CertiUtilTests.cc

you just have to add a clockTests call for
GettimeofdayClock.

Not applying your patch yet.

Sidenote: If you build your patch with cvs diff -uN
          new files should be added in the patch itself.
          Providing separate files is OK too.

Eric NOULARD <erk>
Group administrator
Mon 12 Oct 2009 04:42:36 PM UTC, original submission:  


Hi,

The Attached change adds a new clock that just calls gettimeofday.
Also the order and preference of clocks is changed for unix.
The preffered clock iis the posix realtime clock that was designed for exactly that purpose. As a fallback the gettimeofday solution is used. There is no UNIX system out there that does not provide gettimeofday. so this is a valuable last resort. Even if the posix clocks are available on almost every halfway modern unix.

Concerning the timestamp counter on i*86 cpus:
Please do not use that at all!
Changing frequencies and varying powerstates influence the increment rate of the time stamp counter and even if it is incremented at all. That depends on plenty things you will not be able to track in userspace.

IMO the TSC implementation should vanish completely.
The attached change just removes it from the clock factory. So the implementation is still there, BUT ...

Please review/Apply

Tanks

Mathias

Mathias Fröhlich <frohlich>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #18884:  GettimeofdayClock.cc added by frohlich (2KiB - text/x-c++src)
file #18883:  GettimeofdayClock.hh added by frohlich (2KiB - text/x-c++hdr)
file #18882:  gettimeofday.diff added by frohlich (5KiB - text/x-patch)
file #18864:  GettimeofdayClock.cc added by frohlich (667B - text/x-c++src)
file #18865:  GettimeofdayClock.hh added by frohlich (893B - text/x-c++hdr)
file #18866:  gettimeofday.diff added by frohlich (3KiB - text/x-patch)

 

Depends on the following items: None found

Digest:
   task dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by erk (Posted a comment)
  • -email is unavailable- added by frohlich (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-10-21 erk Open/ClosedOpen Closed
    2009-10-21 erk Dependencies- task #7929 is dependent
    2009-10-16 erk StatusIn Progress Ready For Test
    2009-10-15 frohlich Attached File- Added GettimeofdayClock.cc, #18884
        Attached File- Added GettimeofdayClock.hh, #18883
        Attached File- Added gettimeofday.diff, #18882
    2009-10-12 erk CategoryNone CERTI
        StatusNone In Progress
        Assigned toNone erk
    2009-10-12 frohlich Attached File- Added GettimeofdayClock.cc, #18864
        Attached File- Added GettimeofdayClock.hh, #18865
        Attached File- Added gettimeofday.diff, #18866

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code