On Wed, Jun 15, 2005 at 11:55:07AM -0700, Shirley Ma wrote: > > in case someone's firmware is less accurate than HP's. > > Shirley, did the patch to get_clock.c fix the problem? > > Cycles is not equal to the clock rate. If you have a processor with > internal doubling or pipelining or whatever, the clock rate isn't the > same.
This test assumes the ITC is running at some fixed rate. Linux expects that rate to be reported in /proc/cpuinfo with "cpu Mhz". Does your machine's cycle counter run at 1600 Mhz like the /proc/cpuinfo output indicated? hyperthreading, pipelining, superscaler, etc are all orthogonal issues. The ITC is what matters. > > Anyway, if get_cpu_mhz isnt reliable people can just dump raw > > cycles data and do the math outside the tool. > > Agree if the rdma_lat, and rdma_bw are only used for debugging/regression > testing not for performance measurement. It would be nice if the test would determine the report result was more than X% (e.g. 2%) off from the what the system clock reported. It would be appropriate to warn the user about bogus results. But this is a benchmarking issue. If rdma_lat is primarily a micro-benchmark and secondarily an RDMA code example, then I think it would be good to address this. grant _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
