Re: Tick to sec conversion

From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Fri Feb 26 2010 - 12:24:39 PST

  • Next message: Lingyuan Wang: "thread safety of UPC memory copy library funtions"
    I believe you have a correct understanding.
    The problem is two-fold:
       + UPC threads X and Y could have a different tick value at the start 
    of execution, for instance if the ticks are TSC values from CPUs that 
    were not booted at the identical time.
       + While less likely, it is possible that X and Y could be running at 
    different rates
    It is the second one that prevents one from reliably converting 
    tick-intervals to real time on a UPC thread other than the one the 
    values where collected from, while the first means that the difference 
    between tick values recorded on two different UPC threads is typically 
    If you are concerned about the costs (time for conversion or space for 
    storage) then it may be possible that one could record "raw" ticks in a 
    trace file plus enough additional information to allow ticks-to-ns 
    conversion to be performed outside of the UPC code (e.g. by a tool that 
    processes the trace file).  Just thinking on-the-spot it would probably 
    be sufficient to store just "raw" tick values in your trace file, and at 
    the very end of the file store the result of 
    bupc_ticks_to_ns(last_tick_value - first_tick_value).  Then you could 
    interpolate the realtime of all the tick values between the first and last.
    It may be worth asking the PPW group at UFL if they tried anything like 
    the trick I described above.
    On 2/26/10 7:14 AM, Nikita Andreev wrote:
    > Hi,
    > I want to clarify one thing. I need to collect tracing data from 
    > parallel application's threads and I use bupc_ticks_now call to do 
    > that. Documentation says:
    > " It's important to keep in mind that raw bupc_tick_t values are 
    > thread-specific quantities with a thread-specific interpretation (e.g. 
    > they might represent a hardware cycle count on a particular CPU, 
    > starting at some arbitrary time in the past). ... Therefore as a rule 
    > of thumb, raw bupc_tick_t values and bupc_tick_t intervals obtained by 
    > different threads should never be directly compared or arithmetically 
    > combined, without first converting the relevant tick intervals to wall 
    > time intervals. "
    > So am I understanding correctly that if I'm going to merge all trace 
    > files on one node then I need to write timestamps to trace files in 
    > seconds using bupc_ticks_to_ns? Apparently if I would try to convert 
    > tick to sec on node different form those at which it was collected I 
    > could get weird results, could I?
    > Nikita

  • Next message: Lingyuan Wang: "thread safety of UPC memory copy library funtions"