Sincronización horaria en un entorno heterogéneo.

Question 1

[EDITAR] Una reescritura importante con referencias, ya que acabo de anotar la respuesta anterior de memoria.

Respuesta corta: no.Hoy en día no es posible obtener una precisión de casi milisegundos con un sistema operativo común y corriente en una plataforma x86/x64.

DESCARGO DE RESPONSABILIDAD Esta es una respuesta sencilla, ya que soy un administrador de sistemas común y corriente con una visión normal de las computadoras como administrador de sistemas. Es probable que algunos desarrolladores de kernel y arquitectos de hardware tengan un nivel profesional de conocimiento del cronometraje.

Respuesta larga:

Hay que empezar por algún lado. Haré esto de arriba hacia abajo, comenzando con las aplicaciones moviéndose hacia los osciladores.

El primer problema no es tener un cronometraje en una computadora, sino lograr que el entorno en su conjunto esté de acuerdo con el cronometraje que usted tenga. ¿Qué cronometraje? Resulta que hay un par de formas de mantener el tiempo en una computadora actual. El que más vemos es la hora del sistema (como se muestra en una de las esquinas de la pantalla). Comencemos fingiendo que es así de simple y complicaremos las cosas un par de párrafos más abajo.

Queremos que la hora del sistema sea correcta y queremos que sea uniforme en todas nuestras computadoras. Necesitamos una forma de comunicarlo desde una fuente confiable a un nivel tan detallado que cumpla con nuestros requisitos, cualesquiera que sean.

Hagamos que nuestro requisito tenga un nivel de tolerancia de 1 ms, es decir, nuestro tiempo puede desviarse 1 ms dentro de nuestro entorno o perdemos un objetivo crítico. Seamos concretos y veamos lo que Microsoft puede hacer por nosotros.

Excluyendo obsoletos como NT, el cronometraje nativo de Windows se basa en ntp simplificado (computadoras unidas a un dominio que comienzan con XP/2003) o sntp simplificado (computadoras no unidas a un dominio que comienzan con Win2k); gracias a @Ryan por seleccionar este detalle .Microsoft se fijó dos objetivosal realizar la implementación del cronometraje, ninguno de los cuales incluye nuestro nivel deseado de precisión:

"No garantizamos ni respaldamos la precisión del servicio W32Time entre nodos de una red. El servicio W32Time no es una solución NTP con todas las funciones que satisface las necesidades de aplicaciones urgentes. El servicio W32Time está diseñado principalmente para hacer el siguiente:

Haga funcionar el protocolo de autenticación Kerberos versión 5.
Proporcionar tiempo de sincronización flexible para las computadoras cliente.

El servicio W32Time no puede mantener de manera confiable el tiempo de sincronización en el rango de uno a dos segundos. Estas tolerancias están fuera de las especificaciones de diseño del servicio W32Time."

DE ACUERDO. Suponiendo que estamos ejecutando su pila de servicios en más de una computadora y tenemos un nivel de tolerancia de cronometraje cercano a 1 ms para la correlación de eventos, eso es una gran decepción. Si la pila de servicios incluye dos computadoras, en realidad no podemos usar el cronometraje nativo de Windows. Pero mientras estamos en eso, subrayemos uno o dos puntos clave sobre el cronometraje nativo de Windows e incluyamos documentación detallada:

Si tiene un AD, observe que la hora en un dominio determinado se sincronizará desde la función del emulador de PDC, cualquiera que sea el DC que la tenga. Por lo tanto, es necesario introducir la hora correcta en el dominio a través del controlador de dominio que ejecuta la función del emulador de PDC. Si se encuentra en un bosque multidominio, esto se traduce en el emulador de PDC del dominio raíz del bosque. A partir de ahí, el tiempo se distribuye principalmente a los emuladores PDC de los subdominios y a cada miembro del dominio en forma de abanico (con algunas advertencias). Este proceso esdocumentado aquí. Información aún más detalladaaquí

DE ACUERDO. ¿Qué podemos hacer?

Para empezar, necesitamosunoootroforma más precisa de sincronizar el tiempo en todo el entorno. Suponiendo que no podemos ejecutar Linux ntpd ontpd para Windowspodrías echar un vistazo a un cliente shareware llamadoTardis, pero es probable que haya muchos más para probar.

Ejecutamos Tardis en un servidor Win2k3 que se ejecutaba como un emulador PDC que tenía un reloj CMOS con una desviación realmente grande, por razones históricas inexplicables no tuvimos más remedio que sincronizar toda la red desde él. Ahora ha sido reemplazado con gran alegría por un ntpd de Linux dedicado que trae el tiempo de los relojes atómicos en el exterior, pero Tardis nos salvó admirablemente en ese momento.Sin embargo, no sé si podría ayudarle a lograr una precisión mayor que la nativa de Windows.

Pero supongamos a partir de este momento que hemos descubierto cómo implementar una sincronización horaria de red sustituta perfecta. Gracias a su astucia inherente, tiene una capacidad para niveles de tolerancia inferiores a un milisegundo. Lo hemos implementado para hacer cumplir cómo nuestro AD espera que el tiempo se propague a través de la red.

¿Significa esto que podemos obtener diagnósticos precisos de los sistemas operativos y microservicios con una granularidad cercana a los milisegundos?

Veamos cómo los sistemas operativos en la arquitectura x86/x64 programan el tiempo del procesador.

Utilizan interrupciones, que sonbestias multifacéticas ricas en sustancia arqueológica. Sin embargo, el sistema operativo no es el único que desea interrumpir. ¡El hardware también desea interrumpir y tiene los medios para hacerlo! (Hola teclado) Y los sistemas operativos siguen el juego.

Aquí es donde se complica y lo resolveré simplificando demasiado. ¿Preguntas? Me agacho, me cubro y te señalo hacia unabsolutamente excelente tratado sobre el tema. (Si está buscando milisegundos en una plataforma Windows, realmente debería leerlo...) Una versión actualizada para Win8.1/Win2012r2 essupuestamente en las obraspero aún no ha surgido ninguna fecha de lanzamiento.

Está bien, interrumpe. Siempre que algo sucede en un sistema operativo, una interrupción desencadena la acción siguiente. La acción es un conjunto de instrucciones obtenidas del kernel, que se pueden ejecutar en unlote enterodediferentes modales. La conclusión es que, a pesar de que la interrupción ocurre en un momento que se puede determinar con mayor o menor precisión dependiendo de la arquitectura del hardware y el manejo de interrupciones del kernel, el momento exacto en el que ocurren las partes posteriores de la ejecución generalmente no se puede determinar. Un conjunto específico de instrucciones puede ejecutarse temprano después de la interrupción o más tarde, puede ejecutarse en una secuencia predecible o no, puede ser víctima de hardware defectuoso o controladores mal escritos que afectan latencias difíciles de reconocer. La mayoría de las veces uno simplemente no lo sabe. La marca de tiempo de nivel de milisegundos que se muestra en el archivo de registro posterior:Es muy preciso, pero ¿es exacto en cuanto a cuándo ocurrió el evento?

Detengámonos brevemente en la interrupción del cronometraje. Una interrupción viene con un nivel de prioridad; el nivel más bajo es donde las aplicaciones de usuario (como un servicio estándar) obtienen su tiempo de procesador. Los otros niveles (superiores) están reservados para el hardware y el trabajo del kernel. Si llega una interrupción en un nivel superior al más bajo, el sistema simulará que las interrupciones de menor prioridad que también están en la cola no existen (hasta que se hayan atendido las interrupciones de mayor prioridad). De esta manera, las aplicaciones y servicios ordinarios que se ejecutan serán los últimos en la fila de tiempo de procesador. Por el contrario, a la interrupción del ciclo se le da casi la máxima prioridad. La actualización del tiempo casi siempre se realizará en un sistema. Esta es una simplificación excesiva casi criminal de cómo funciona todo, pero cumple el propósito de esta respuesta.

El tiempo de actualización en realidad consta de dos tareas:

Actualización de la hora del sistema / También conocido como el reloj de pared / También conocido como lo que digo cuando alguien me pregunta qué hora es / También conocido como el ntp juguetea un poco hacia adelante y hacia atrás en relación con los sistemas cercanos.
Actualización del recuento de ticks, que se utiliza, por ejemplo, al medir las duraciones en la ejecución del código.

Pero ya sea el tiempo de pared o el conteo de ticks, ¿de dónde obtiene el sistema el tiempo? Depende en gran medida de la arquitectura del hardware. En algún lugar del hardware uno o varios osciladores están haciendo tictac, y ese tictac se produce a través deunodevariosposiblecaminosen una interfaz para el contacto con el kernel mientras éste con mayor o menor precisión y exactitud actualiza su tiempo de pared y conteo de ticks.

Existen varios modelos de diseño para la colocación de osciladores en un sistema multinúcleo; el principal diferenciador parece ser la colocación sincrónica versus asincrónica. Estos, junto con sus respectivos desafíos para un cronometraje preciso, se describenaquípor ejemplo.

En resumen, el cronometraje síncrono tiene un reloj de referencia por multinúcleo, que distribuye su señal a todos los núcleos. El cronometraje asincrónico tiene un oscilador por núcleo. Vale la pena señalar que los últimos procesadores Intel multinúcleo (Haswell) utilizan alguna forma de diseño síncrono utilizando un bus serie llamado "QuickPath Interconnect" con "Forwarded Clocking", ref.ficha de datos. El marcado reenviado se describe en términos tales que un profano (yo) puede comprenderlo rápidamente y de forma superficial.aquí.

Bien, dejando de lado todo ese nerderismo (que sirvió para demostrar que el cronometraje es una tarea práctica compleja con mucha historia viva al respecto), veamos aún más de cerca el manejo de interrupciones.

Los sistemas operativos controlan las interrupciones utilizando una de dos estrategias distintas: con tictac o sin tictac. Sus sistemas utilizan uno u otro, pero ¿qué significan los términos?

granos haciendo tictacenviar interrupciones a intervalos fijos. El sistema operativo no puede medir el tiempo con una resolución más fina que el intervalo de tick. Incluso entonces, el procesamiento real involucrado en la realización de una o varias acciones puede contener un retraso mayor que el intervalo de tic. Consideremos, por ejemplo, los sistemas distribuidos (como los microservicios) donde los retrasos inherentes a las llamadas entre servicios podrían consumir relativamente mucho tiempo. Sin embargo, cada conjunto de instrucciones estará asociado con una o varias interrupciones medidas por el sistema operativo con una resolución no mayor que el tiempo de funcionamiento del núcleo. El tiempo de tic tiene un valor base, pero al menos en Windows puede reducirse según demanda mediante una aplicación individual. Esta es una acción asociadano sólo con beneficios sino también con costos, y llevabastante letra pequeñacon eso.

llamado asígranos sin cosquillas(que tienen un nombre muy poco descriptivo) son un invento relativamente nuevo. Un kernel sin ticks establece el tiempo de tick en intervalos variables (la mayor duración posible en el futuro). La razón es que el sistema operativo permite dinámicamente que los núcleos del procesador entren en varios niveles de suspensión durante el mayor tiempo posible, con el simple propósito de conservar energía. "Varios niveles" incluyen el procesamiento de instrucciones a máxima velocidad, el procesamiento a velocidades reducidas (es decir, una velocidad de procesador más lenta) o no procesar en absoluto. A diferentes núcleos se les permite operar a diferentes velocidades y el núcleo sin ticks intenta dejar que los procesadores estén lo más inactivos posible, incluso en casos que incluyen poner en cola instrucciones para activarlos en lotes de interrupción. En resumen, a los diferentes núcleos de un sistema multiprocesador se les permite desviarse en el tiempo entre sí. Por supuesto, esto causa estragos en la buena sincronización y es hasta ahora un problema sin resolver con las nuevas arquitecturas de procesadores de ahorro de energía y los kernels que les permiten realizar un ahorro de energía eficiente. Compare esto con un núcleo que hace tictac (intervalo de tictac estático) que activa continuamente todos los núcleos del procesador, independientemente de si reciben trabajo real o no, y donde el cronometraje conlleva un grado de inexactitud pero en un grado relativamente confiable en comparación con los núcleos sin tictac.

El estandarEl tiempo de tic de Windows, que es la resolución del sistema, es de 15,6 ms.hasta Windows 8/2012, donde el comportamiento predeterminado es sin ticks (pero se puede revertir al kernel de ticks). Creo que el tiempo de tick predeterminado de Linux depende de la compilación del kernel, peroeste nichoesbien fuera de mi experiencia(yÉstetambién) por lo que es posible que desees volver a verificar si dependes de él. Creo que los kernels de Linux se compilan sin ticks desde 2.6.21 y pueden compilarse con varios indicadores que optimizan el comportamiento sin ticks (y de los cuales solo recuerdo algunas variantes de no_hz).

Hasta aquí los sistemas de metal desnudo. En los sistemas virtuales, la situación empeora, ya que la contención entre las máquinas virtuales y el hipervisor hace que el cronometraje sea extremadamente difícil. Aquí estáuna descripción general de VMwareyaquí hay uno para RHEL KVM. Lo mismo ocurre con los sistemas distribuidos. Los sistemas en la nube sonaún más difícilya que ni siquiera nos acercamos a ver hipervisores y hardware reales.

Para concluir, obtener la hora exacta de un sistema es un problema de múltiples niveles. Yendo ahora de abajo hacia arriba desde un punto de vista de alto nivel, tenemos que solucionar: Sincronización horaria interna entre el hardware y el kernel, interrupciones en el procesamiento y retrasos en la ejecución de las instrucciones que deseamos, en caso de imprecisiones en un entorno virtual. gracias a la encapsulación de una segunda capa del sistema operativo, la sincronización del tiempo entre sistemas distribuidos.

Por lo tanto, en este punto de la historia de la informática no obtendremos una precisión de nivel de milisegundos con una arquitectura x86/x64, al menos sin utilizar ninguno de los sistemas operativos comunes y corrientes.

¿Pero qué tan cerca podemos llegar? No lo sé y debería variar mucho entre diferentes sistemas. Controlar la inexactitud de los propios sistemas específicos es una tarea de enormes proporciones. Sólo hay que mirarcómo Intel sugiere que se debe realizar la evaluación comparativa del códigover que los sistemas ordinarios, como los que yo administro, están muy fuera de control desde esta perspectiva.

Ni siquiera me planteo lograr"Se desactivaron todas las funciones de optimización de energía, tecnología Intel Hyper-Threading, escalado de frecuencia y modo turbo"en sistemas críticos, y mucho menos jugar con envoltorios de código en C y ejecutar pruebas a largo plazo para obtener respuestas posteriores. Sólo trato de mantenerlos vivos y aprender todo lo que puedo sobre ellos sin molestarlos demasiado. Gracias marca de tiempo, sé que no puedo confiar plenamente en ti, pero sí sé que no faltan muchos segundos. Cuando la precisión real de milisegundos se vuelve importante, una medida no es suficiente, sino que se necesita una mayor cantidad de mediciones para verificar el patrón. qué más podemos hacer?

Por último, es interesante observarCómo piensan los sistemas operativos en tiempo real interrumpir la latencia. También hay unaalternativa de sincronización de tiempo muy emocionanteen proceso, donde hay bastantes cosas interesantesEstadísticas,metodologíaylibros blancosse hacen públicos. Si a eso le sumamos futuros desarrollos de arquitectura de hardware y kernel, en unos años esta cuestión de la precisión del cronometraje puede que ya no sea un problema. Uno puede tener esperanza.

Answer