uso - ver caracteristicas de mi pc linux centos
precisión rdtsc en los núcleos de la CPU (6)
De hecho, parece que los núcleos no comparten TSC, verifique este hilo: http://software.intel.com/en-us/forums/topic/388964
Resumiendo, diferentes núcleos no comparten TSC, a veces TSC puede perder la sincronización si un núcleo cambia a un estado de energía específico, pero depende del tipo de CPU, por lo que debe consultar la documentación de Intel. Parece que la mayoría de los sistemas operativos sincronizan TSC en el arranque.
Revisé las diferencias entre TSC en diferentes núcleos, utilizando un algoritmo de reacción emocionante, en una máquina Debian de Linux con procesador Core i5. El proceso de excitación (en un núcleo) arregló el TSC en una variable compartida, cuando el proceso de reacción detectó un cambio en esa variable, compara su valor y lo compara con su propio TSC. Este es un ejemplo de salida de mi programa de prueba:
TSC ping-pong test result:
TSC cores (exciter-reactor): 0-1
100 records, avrg: 159, range: 105-269
Dispersion: 13
TSC ping-pong test result:
TSC cores (exciter-reactor): 1-0
100 records, avrg: 167, range: 125-410
Dispersion: 13
El tiempo de reacción cuando la CPU del excitador es 0 (159 tics en promedio) es casi el mismo que cuando la CPU del excitador es 1 (167 tics). Esto indica que están bastante bien sincronizados (quizás con unos pocos tics de diferencia). En otros pares de núcleos, los resultados fueron muy similares.
Por otro lado, la instrucción de ensamblaje rdtscp devuelve un valor que indica la CPU en la que se leyó el TSC. No es su caso, pero puede ser útil cuando desea medir el tiempo en un segmento de código simple y desea asegurarse de que el proceso no se movió de la CPU en medio del código.
Estoy enviando paquetes de red desde un subproceso y estoy recibiendo respuestas en un segundo subproceso que se ejecuta en un núcleo de CPU diferente. Mi proceso mide el tiempo entre el envío y la recepción de cada paquete (similar al ping). Estoy usando rdtsc para obtener una sincronización de alta resolución y poca sobrecarga, que es necesaria para mi implementación.
Todas las medidas parecen fiables. Sin embargo, me preocupa la precisión de rdtsc en los núcleos, ya que he estado leyendo algunos textos que implican que tsc no está sincronizado entre los núcleos.
Encontré la siguiente información sobre TSC en wikipedia
El comportamiento constante del TSC garantiza que la duración de cada tic del reloj sea uniforme y admite el uso del TSC como un temporizador de reloj de pared, incluso si el núcleo del procesador cambia de frecuencia . Este es el comportamiento arquitectónico que está avanzando para todos los procesadores Intel.
Todavía estoy preocupado por la precisión en los núcleos, y esta es mi pregunta
Más información
- Ejecuto mi proceso en una máquina Intel Nehalem.
- El sistema operativo es Linux.
- El indicador de la CPU " constant_tsc " se establece para todos los núcleos.
En linux, puede usar clock_gettime (3) con CLOCK_MONOTONIC_RAW, lo que le brinda una resolución de nanosegundos y no está sujeto a actualizaciones ntp (si es que sucedió).
En los procesadores recientes, puede hacerlo entre núcleos separados del mismo paquete (es decir, un sistema con solo un procesador iX central), simplemente no puede hacerlo en paquetes separados (procesadores), porque no compartirán el rtc. Puede salirse con la suya a través de la afinidad de la CPU (bloquear hilos relevantes a núcleos específicos), pero de nuevo dependerá de la forma en que se comporte su aplicación.
En Linux, puede verificar constant_tsc en / proc / cpuinfo para ver si el procesador tiene un solo tsc válido para todo el paquete. El registro sin procesar está en CPUID.80000007H: EDX [8]
Lo que he leído, pero aún no he confirmado programáticamente, es que las CPU de AMD a partir de la revisión 11h en adelante tienen el mismo significado para este bit de cpuid.
Puede establecer la afinidad de subprocesos utilizando la API sched_set_affinity() para ejecutar su subproceso en un núcleo de CPU.
Te recomiendo que no uses rdtsc. No solo no es portátil, no es confiable y, en general, no funciona. En algunos sistemas, el rdtsc no se actualiza de manera uniforme (como si estuviera usando speedstep, etc.). Si desea información de tiempo precisa, debe configurar la opción SO_TIMESTAMP en el zócalo y usar recvmsg () para obtener el mensaje con una marca de tiempo (resolución de microsegundos).
Además, la marca de tiempo que obtienes con SO_TIMESTAMP ES realmente la hora en que el núcleo recibió el paquete, no cuando tu tarea se dio cuenta.
X86_FEATURE_CONSTANT_TSC + X86_FEATURE_NONSTOP_TSC bits en cpuid (edx = x80000007, bit # 8; verifique la función unsynchronized_tsc del kernel de Linux para más verificaciones)
Vol3b del diseñador de Intel, sección 16.11.1 TSC invariante dice lo siguiente
"16.11.1 TSC invariante
El contador de marca de tiempo en los procesadores más nuevos puede admitir una mejora, denominada TSC invariante. La compatibilidad del procesador con el invariante TSC se indica mediante CPUID.80000007H: EDX [8].
El invariante TSC se ejecutará a una velocidad constante en todos los ACPI P-, C-. y estados T Este es el comportamiento arquitectónico que avanza. En los procesadores con compatibilidad invariable con TSC, el sistema operativo puede usar el TSC para los servicios de temporizador de reloj de pared (en lugar de los temporizadores ACPI o HPET). Las lecturas de TSC son mucho más eficientes y no incurren en la sobrecarga asociada con una transición de anillo o el acceso a un recurso de plataforma ".
Por lo tanto, si se puede usar TSC para wallclock, se garantiza que están sincronizados.