From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Fri Feb 26 2010 - 12:24:39 PST
Nikita, 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 meaningless. 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. -Paul 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