29/11/2013 14:53, Dmitry Vyal : > On 11/28/2013 03:01 PM, Richardson, Bruce wrote: > >> It's probably due to a frequency scaling. > >> The timer based is initialized when DPDK initialize and the CPU can > >> change > >> its frequency, breaking next timers. > >> > >> The fix is to control the CPU frequency. > >> > >> Please try this, without your patch: > >> for g in /sys/devices/system/cpu/*/cpufreq/scaling_governor; do > >> > >> echo performance >$g; done The right fix for applications (examples and > >> testpmd included) could be to call rte_power_init(). Patches are > >> welcomed. > > > > [BR] Frequency changes should not affect timers for modern Intel CPUs. > > Please see the " Intel(r) 64 and IA-32 Architectures Software Developer's > > Manual" Volume 3 > > (http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-i > > a-32-architectures-software-developer-system-programming-manual-325384.pdf > > ) , Section 17.13 for more details on this. > > Hmm, that's strange. I don't know how to interpret my observations then. > I have access to two platforms, one is based on Intel(R) Xeon(R) CPU > E3-1230 V2 @ 3.30GHz and another on Intel(R) Xeon(R) CPU E3-1270 v3 @ > 3.50GHz. Both running ubuntu-12.04 server. I see repeating errors on NIC > initialisation phase. The error frequency greatly reduces if I patch > loop limit as I described earlier or if I call rte_power_init and > rte_power_freq_max as Thomas suggested. > > But the only way to get rid of them completely is to set performance > governor.
Please check that your hardware do not support invariant TSC. It would explain why you need to fix frequency. I attach a simple code to test CPU feature "Invariant TSC". -- Thomas
