lunes, 12 de mayo de 2014

Sincronización de los Sistemas Distribuidos

Sincronización de los Sistemas Distribuidos

Ya hemos visto la forma en que los procesos se comunican entre si en un sistema distribuido. Los métodos que analizamos fueron los protocolos con capas, transferencia de mensajes solicitud/respuesta (RPC incluida) y comunicación en grupo. Aunque la comunicación es importante, no es todo lo que hay que considerar. Intirnamente relacionada con esto está la forma en que los procesos cooperan y se sincronizan entre sí. Por ejemplo, la forma dc implantar tas regiones críticas o asignar recursos en un sistema distribuido. En los sistemas con un CPU, los problemas relativos a las regiones críticas, la exclusión mutua y la sincronización se resuelven en general mediante métodos tales como los semáforos y los monitores. Estos métodos no son adecuados para su uso en los sistemas distribuidos, puesto que siempre se basan (de manera implícita) en la existencia de la memoria compartida. Por ejemplo, dos procesos que interactúan mediante un semáforo deben tener acceso a éste. Si se ejecutan en la misma máquina, pueden compartir el semáforo al guardarlo en el núcleo y realizar llamadas al sistema para tener acceso a él. Sin embargo, si se ejecutan en máquinas distintas, este método ya no funciona, por lo que se necesitan otras técnicas. Incluso las cuestiones más sencillas, como el hecho de determinar si el evento A ocurrió antes o después del evento B requiere una reflexión cuidadosa. Comenzaremos con el tiempo y la forma de medirlo, puesto que éste juega un papel fundamental en algunos modelos de sincronización. 



Sincronización de Relojes

La sincronización es más compleja en los sistemas distribuidos que en los centralizados, puesto que los primeros deben utilizar algoritmos distribuidos. Por lo general, no es posible (o recomendable) reunir toda la información relativa al sistema en un lugar y después dejar que cierto proceso la examine y tome una decisión, como se hace en el caso centralizado. En general, los algoritmos distribuidos tienen las siguientes propiedades:

1. La información relevante se distribuye entre varias máquinas. 
2. Los procesos toman las decisiones sólo con base en la información disponible en forma local. 
3. Debe evitarse un punto de fallo en el sistema. 
4. No existe un reloj común o alguna otra fuente precisa del ~iempo global.

        Los primeros tres puntos indican que es inaceptable reunir toda la información en un lugar para su procesamiento. Por ejemplo, para llevar a cabo la asignación de recursos (asignar los dispositivos de E/S en una forma libre de bloqueos), por lo general no es aceptable enviar todas las solicitudes aun administrador de procesos, el cual examina a todos y otorga o niega las solicitudes con base en la información de sus tablas. En un sistema de gran tamaño, tal solución pone en predicamentos a dicho proceso. 
  
        Además, el hecho de que sólo exista un punto de fallo como éste hace que el sistema no sea confiable. Lo ideal es que un sistema distribuido debería ser más confiable que las máquinas individuales. Si alguna de ellas falla, el resto puede continuar su funcionamiento. Lo último que quisiéramos es una situación donde una máquina falle (por ejemplo, el asignador de recursos) y con ello detenga a un gran número de máquinas diversas. Para lograr la sincronización sin centralización necesitamos algo distinto al caso de los sistemas operativos tradicionales.

        El último punto de la lista también es crucial. En un sistema centralizado, el tiempo no tiene ambigüedades  Cuando un proceso desea conocer la hora, llama al sistema y el núcleo se la dice. Si el proceso A pide a hora y un poco después, el proceso B también la pide, el valor obtenido por B es mayor o igual que el valor obtenido por A. Ciertamente, no debe ser menor. En un sistema distribuido, no es trivial poner de acuerdo a todas las máquinas en la hora. Por ejemplo, pensemos por un momento las implicaciones de la carencia de un tiempo global en el programa make de UNIX. En UNIX los programas de gran tamaño se dividen por lo general en varios archivos fuentes, de modo que un cambio al archivo fuente sólo necesite una nueva compilación de un archivo y no de todos. Si un programa consta de 100 archivos y no hay que volverlo a compilar por la modificación de un archivo, la velocidad de trabajo de los programadores aumenta en gran medida.

        La forma de funcionamiento de make es muy sencilla. Cuando el programador termina de modificar todos los archivos fuentes, inicia make, el cual examina las horas en que todos tos archivos fuentes y objetos fueron modificados por última vez. Si el archivo fuente input.c tiene la hora 5456 y el correspondiente archivo objeto input.o tiene la hora 5455, make sabe que ínput.c tiene modificaciones desde la creación de input.o, por lo que entonces hay que volver a compilar input.c. Por otro lado, si output.c tiene la hora 2 144 y output.o tiene la hora 2 145, entonces no es necesario volverá compilar. Así, make revisa todos los archivos fuentes para determinar aquellos que deban volverse a compilar y llama al compilador para que realice esta tarea. Puesto que el tiempo es fundamental para la forma de pensar de la gente y el efecto de carecer de sincronización en los relojes puede sermuy drástico, como hemos visto, podemos iniciar nuestro estudio de la sincronización con la siguiente sencilla pregunta: "¿Es posible sincronizar todos los relojes en un sistema distribuido?

RELOJES LÓGICOS.

Casi todas las computadoras tienen un circuito para el registro del tiempo. A pesar del uso generalizado de la palabra "reloj" para hacer referencia a dichos dispositivos, en realidad no son relojes en el sentido usual., cronómetro sería una mejor palabra. Un cronómetro de computadora es por lo general un cristal de cuarzo trabajado con precisión. Cuando se mantiene sujeto a tensión, un cristal de cuarzo oscila con frecuencia bien definida, que depende dei tipo de cristal, la foriina en que se corte y la magnitud de la tensión. A cada cristal se le asocian dos registros, un contador y un registro mantenedor. Cada oscilación del cristal disminuye en 1 a contador,  cuando el contador toma el valor 0, se genera una interrupción y el contador se vuelve a cargar mediante el registro mantenedor. De esta forma, es posible programar un cronómetro de modo que genere una interrupción 60 veces por cada segundo o con cualquier frecuencia que se desee. Cada interrupción recibe el nombre de marca de reloj.

       Cuando se arranca por vez primera el sistema, por lo general se pide al operador que escriba la fecha y la hora, las cuales se convierten al número de mareas después de cierta fecha conocida y se guardan en la memoria. En cada marca de reloj, el procedimiento de servicio de interrupciones añade 1 al tiempo guardado en memoria. De esta forma, el reloj (de software) se mantiene actualizado.

        En el caso de una computadora y un reloj, no importa si éste se desfasa un poco. Puesto que todos los procesos de la máquina utilizan el mismo reloj, tendrán consistencia interna. Por ejemplo, si el archivo input.c tiene la hora 251 y el archivo influj.o tiene la hora 250,  make vuelve a compilar el archivo fuente, aunque el reloj se desfase en 2 y los tiempos reales sean  253 y 252, respectivamente. Todo lo que importa son los tiempos relativos. Tan pronto se comienza a trabajar con varias máquinas, cada una con su propio reloj, la situación es distinta. Aunque la frecuencia de un oscilador de cristal es muy estable, es imposible garantizar que los cristales de computadoras distintas oscilen precisamente con lamisma frecuencia. En la práctica, cuando un sistema tienen computadoras, los n cristales correspondientes oscilarán a tasas un poco distintas, lo que provoca una pérdida de sincronía en los relojes (de software) y que al leerlos tengan valores distintos. La diferencia entre los valores del tiempo se llama distorsión del reloj. Como consecuencia de esta distorsión, podrían fallar los programas que esperan que el tiempo asociado a un archivo, objeto, proceso o mcnsaje sea correcto e independiente del sitio donde haya sido generado (es decir, del reloj utilizado), como hemos visto en el ejemplo anterior de make.

        Esto nos regresa a nuestra pregunta original, saber si es posible sincronizar todos los relojes para obtener un estándar de tiempo único, sin ambigüedades  En un artículo clásico, Lamport(l 978) demostró que la sincronización de relojes es posible y presentó un algoritmo para lograr esto. Amplió su trabajo en (Lamport, 1990). Lamport señaló que la sincronización de relojes no tiene que ser absoluta. Si dos procesos no interactian, no es necesario que sus relojes estén sincronizados, puesto que la carencia de sincronización no seria observable y por tanto no podría provocar problemas. Además, señaló que lo que importa por lo general, no es que todos los procesos concuerden de manera exacta en la hora, sino que coincidan en el orden en que ocurren los eventos. En el ejemplo anterior de make, lo que importa es si inpul.c es anterior o posterior a input.o y no la hora exacta en que fueron creados.

       Para la mayoría de los fines, basta que todas las máquinas coincidan en la misma hora. No es esencial que esta hora también coincida con la hora real, como se anuncia en la radio cada hora. Por ejemplo, para ejecutar nake, es adecuado que todas las máquinas estén de acuerdo en quesean las 10:00, aunque en realidad sean las 10:02. Así, para una cierta clase de algoritmos, lo que importa es la consistencia interna de los relojes, no su panicular cercanía al tiempo real. Para estos algoritmos, conviene hablar de los relojes como relojes lógicos. Cuando existe la restricción adicional de que los relojes no sólo deben ser iguales, sino que además no se desvíen del tiempo real más ahá de cierta magnitud, los relojes reciben el nombre de relojes físicos". A continuación analizaremos elalgoritmo de Lamport, el cual sincroniza los relojes lógicos.

        Lamport definió una relación llamada ocurre antes de. La expresión A ® B se lee: A ocurre antes de B, e indica que todos los procesos coinciden en que primero ocurre el evento A y después el evento B.  La relación "ocurre antes de" se puede observar de manera directa en dos situaciones:

Si A y B son eventos en el mismo proceso y A ocurre antes de B, entonces A ~ B es verdadero.

2. Si A es el evento del envió de un mensaje por un proceso y B es el evento de la recepción del mensaje por otro,  entonces A ~ B también es verdadero. Un mensaje no se puede recibir antes de ser enviado o al mismo tiempo en que se envía, puesto que tarda en llegar una cantidad finita de tiempo.

        "Ocurre antes de" es una relación transitiva, de modo que si A ® B  y B® C, entonces A® C.  Si dos eventos, X  y Y, están en procesos diferentes que no intercambian mensajes (ni siquiera en forma indirecta por medio de un tercero), X® Y no es verdadero, ni tampoco lo es Y® X. Se dice que estos eventos son concurrentes, lo que significa que nada se puede decir (o se necesita decir) acerca del momento en el que ocurren o cuál de ellos es el primero. Lo que necesitamos es una forma de medir el tiempo tal que, a cada evento A, le podamos asociar un valor del tiempo C(A) en el que todos los procesos estén de acuerdo. Estos valores del tiempo deben tener la propiedad de que si A® B , entonces C(A) < C(B). En otros términos, si A y B son dos procesos dentro del mismo evento y A ocurre antes de B, entonces C(A) < C(B). De manera análoga, si A a es el envío de un mensaje por un proceso y B  la recepción de ese mensaje por otro proceso, entonces C(A) y C{B) deben ser asignados de tal forma que todos estén de acuerdo en los valores de C(a) y C(b) con C(a) <C(b). Además, el tiempo del reloj, C, siempre debe ir hacia adelante (creciente), y nunca hacia atrás (decreciente). Se pueden hacer correcciones al tiempo al sumar un valor positivo al reloj, pero nunca se le debe restar un valor positivo.

       Analizaremos ahora el algoritmo propuesto por Lamport para la asignación de tiempos a eventos. Consideremos los tres procesos que se muestran en la sig.  figura. Los procesos se ejecutan en diferentes máquinas, cada una con su propio reloj y velocidad. Como se puede ver en la figura, cuando el reloj marca 6 en el proceso 0, ha marcado 8 en el proceso 1 y 10 en el proceso 2. Cada reloj corre a una razón constante, sólo que las razones son diferentes debido a las diferencias en los cristales.



        Al tiempo 6, el proceso 0 envía el mensaje A al proceso 1. El tiempo que tarda este mensaje en llegar depende del reloj elegido. En cualquier caso, el reloj del proceso 1 lee 6 cuando el mensaje llega. Si el mensaje transporta el tiempo de inicio 6, entonces el proceso 1 concluirá que tardó 10 marcas de reloj en hacer el viaje. Este valor es posible. De acuerdo con este razonamiento, el mensaje B de 1 a 2 ocupa 16 marcas, que de nuevo es un valor plausible. Ahora viene lo divertido. El mensaje C, de 2 a 1, sale en 60 y llega en 56. En forma análoga el mensaje D, de 1 a 0, sale en 64 y llega en 54. Es claro que estos valores son imposibles. Esta situación es la que hay que evitar.

      La solución de Lamport es consecuencia directa de la relación "ocurre antes de". Puesto que C sale en 60, debe llegar en 61 o en un tiempo postenor. Por lo tanto, cada mensaje trae consigo el tiempo de envío, de acuerdo con el reloj del emisor. Cuando un mensaje llega y el reloj del receptor muestra un valor anterior al tiempo en que se envió el mensaje. rápidamente el receptor adelanta su reloj para que tenga una unidad más que el tiempo de envío- En la figura 3-2(b), vemos que C llega ahora a 61 - En forma análoga, D llega en 70. Con una pequeña adición, este algoritmo cumple nuestras necesidades para el tiempo global. La adición es que entre cualesquiera dos eventos, el reloj debe marcar al menos una vez. Si un proceso envía o recibe dos mensajes en serie muy rápida, avanza su reloj en (al menos) una marca entre ellos. En ciertas situaciones, existe un requisito adicional: dos eventos no ocurren exactamente al mismo tiempo. Para lograr esto, podemos asociar el número del proceso en que ocurre el evento y el extremo inferior del tiempo, separados por un punto decimal. Así, si ocurren eventos en los procesos 1 y 2, ambos en el tiempo 40, entonces el primero se convierte en 40. y el segundo en 40.2.

        Por medio de este método, tenemos ahora una forma de asignar un tiempo a todos los eventos en un sistema distribuido, con las siguientes condiciones:

1. Si A ocurre antes de B en el mismo proceso, C(A) <C(B).

2. Si A y B  son el envío y la recepción de un mensaje, C(A) <C(B).

3. Para todos los eventos A y B, C(A ) es diferente a C(b).

RELOJES FÍSICOS

Aunque el algoritmo de Lampon proporciona un orden de eventos sin ambigüedades  los valores de tiempo asignados a los eventos no tienen que ser cercanos a los tiempos reales en los que ocurren. En ciertos sistemas (por ejemplo, los sistemas de tiempo real), es importante la hora real del reloj. Para estos sistemas se necesitan relojes físicos externos. Por razones de eficiencia y redundancia, por lo general son recomendables varios relojes físicos  lo cual implicados problemas: (1) Cómo los sincronizamos con los relojes del mundo real? y (2)Cómo sincronizamos los relojes entre sí?

        Antes de responder estas preguntas, vamos a detenemos un poco para verla forma en que se mide en realidad el tiempo. No es tan sencillo como uno podría pensar, en particular CUANDO se requiere alta precisión. Desde la invención de los relojes mecánicos en el siglo XVII, el tiempo se ha medido de manera astronómica. Cada día, el sol parece levantarse en el horizonte del este, sube hasta una altura máxima en el cielo y desciende en el oeste. El evento en que el sol alcanza su punto aparentemente más alto en el cielo se llama tránsito del sol. Este evento ocurre aproximadamente a las doce del día de cada día. El intervalo entre dos tránsitos consecutivos del sol se llama el día solar. Puesto que existen 24 horas en un día, cada una de las cuales contiene 3 600 segundos, el segundo solar se define exactamente como 1186400 de un día solar. La geometría del cálculo del día medio solar es: 



        En la década de 1940, se estableció que el período de rotación de la tierra no es constante. La tierra está disminuyendo su velocidad, debido a la fricción tidal y el arrastre atmosférico. Con base en estudios de los patrones de crecimiento del coral antiguo, los geólogos piensan ahora que hace 300 millones de años existían cerca de 400 días al año. La duración del año, es decir, el tiempo que tarda la tierra en dar una vuelta alrededor del sol, no ha cambiado; sólo ocurre que los días se hacen más largos. Además de esta tendencia a largo plazo, también ocurren pequeñas variaciones a corto plazo en la duración del día, lo cual probablemente se deba a una turbulencia originada en el centro de acero fundido de la Tierra.

        Estas revelaciones han llevado a los astrónomos a calcular la longitud del día mediante la medición de un gran número de días y tomar su promedio antes de dividir entre 86400. La cantidad resultante se llama el segundo solar promedio. Con la invención del reloj atómico en 1948, fue posible medir el tiempo de manera mucho más exacta y en forma independiente de todo el ir y venir de la Tierra, al contar las transiciones del átomo de cesio 133. Los físicos retomaron de los astrónomos la tarea de medir el tiempo y definieron el segundo como el tiempo que tarda el átomo de cesio 133 en hacer exactamente 9 192 631 770 transictones. La elección de 9 192631 770 fue hecha para que el segundo atómico fuera igual al segundo solar promedio en el año de su introducción. Actualmente, cerca de 50 laboratorios en el mundo tienen relojes de cesio 133. En forma periódica, cada laboratorio le indica a la oficina internacional de la hora en París (BlM) el número demarcas de su reloj. La oficina hace un promedio de estos números para producir el tiempo atómico internacional, que se abrevia TAI. Así,TAI es el promedio de las marcas de los relojes de cesio 133 a partir de la medianoche del primero de enero de 1958 (principio del tiempo), dividido entre 9 192 631 770.

         Es muy estable y disponible para todos los que quieran comprarse un reloj de cesio, existe un serio problema con él; 86 400 segundos TAl son ahora cerca de 3 milisegundos menos que un día solar medio (puesto que este día solar promedio es cada vez más grande).El uso de TAl para el registro del tiempo significaría que, con el paso de los años, el mediodía sería cada vez más temprano, hasta llegar al momento en que el mediodía ocurrirta en la mañana. Las personas notarían esto y podrían estar en el mismo tipo de situación ocurrida en 1582, cuando el Papa Gregorio XIII decretó que se deberían omitir del calendario diez días. Este suceso provocó revueltas en las calles, puesto que los terratenientes demandaron una renta de todo un mes y los banqueros un interés de todo el mes, mientras que los patrones se rehusaron apagara los trabajadores por los diez días que no trabajaron, por mencionar unos cuantos de los conflictos. Los países protestantes, por cuestiones de principio, rechazaron todo lo que tenía que ver con los decretos papales y no aceptaron el calendario Gregoriano durante 170 años.

        La BIH resolvió el problema mediante la introducción de segundos de salto, siempre que la discrepancia etitre TAl y el tiempo solar creciera hasta 800 milseg. El uso de los segundos de salto (como se ilustra a continuación . Esta corrección da lugar a un sistema de tiempo basado en los segundos constantes TAl, pero que permanece en fase con el movimiento aparente del Sol. Se le llama tiempo coordenado universal, UTC, el cual es la base de todo el sistema de mantenimiento moderno de la hora. En lo esencial, ha remplazado al estándar anterior, el tiempo dcl meridiano de Greenwich, que es  tiempo astronómico.  La mayoría de las compañías que proporcionan la luz eléctrica basan sus relojes de 60 Hz  o 50 Hz en el UTC, por lo que cuando BIH anuncia un segundo de salto, las compañías elevan su frecuencia a 61 Hz 051 Hz durante 60050 segundos, para que avancen todos sus relojes del área de disfribución. Puesto que un segundo es un intervalo notable para una computadora, un sistema operativo que necesite mantener un tiempo exacto durante un periodo de algunos años debe tener un soflware especial para registrar los segundos de salto conforme sean anunciados (a menos que utilicen la línea de corriente eléctrica para medir su tiempo, lo cual es demasiado burdo). El número total de segundos de salto introducidos en UTC basta ahora es cercano a 30.

        Para proporcionar UTC a las personas que necesitan un tiempo preciso, el Instituto Nacional del Tiempo Estándar (NIST) opera una estación de radio de onda corta con las siglas WWV desde Fort Collins, Colorado. WWV transmite un pulso corto al inicio de cada segundo UTC. La precisión del propio WWV es de cerca de ti milisegundo, pero debido a la fluctuación atmosférica aleatoria que puede afectar la longitud de la trayectoria de la señal, en la práctica la precisión no es mejor que 110 milisegundos.Varios satélites terrestres también ofrecen un servicio UTC. Ej Satélite de Ambiente Operacional Geoestacionario (GEOS) puede proporcionar UTC con una precisión de hasta 0.5 milisegundos y algunos otros satélites lo hacen incluso mejor.  El uso del radio de onda corta o los servicios de satélite requiere de un conocimiento preciso de la posición relativa del emisor y el receptor, para compensar el retraso de la propagación de la señal. Se dispone en forma comercial de radio receptores de WWV, GEOS y las otras fuentes UTC. El costo varía desde unos cuantos cientos de dólares hasta decenas de cientos de dólares cada uno, donde se paga más por las mejores fuentes. UTC también se puede obtener de manera más barata, pero menos exacta, por vía telefónica, desde NrST en Fort Collins, pero aquí también hay que hacer una corrección por la ruta de la señal y la velocidad del módern. Esta corrección introduce por lo general cierta imprecisión, lo que dificulta la obtención dcl tiempo con una precisión extremadamente alta

ALGORITMOS PARA LA SINCRONIZACIÓN DE RELOJES

Si una máquina tiene un receptor WWV, entonces el objetivo es hacer que todas las máquinas se sincronicen con ella. Si ninguna máquina tiene receptores WWV, entonces cada máquina lleva el registro de su propio tiempo y el objetivo es mantener el tiempo de todas las máquinas tan cercano como sea posible. Se han propuesto muchos algontmos para lograr esta sincronización (porejemplo, Cristian, 1989; Dmmmondy Babaoglu, y Kopetzy Ochsenre&iexcl;ter, 987). Todos los algoritmos tienen el mismo modelo subyacente del sistema. que describiremos a continuación. Se supone que cada máquina tiene un cronómetro. el cual provoca una interrupción H veces por cada segundo. Cuando este cronómetro se detiene, el controlador de interrupciones suma l aun reloj en soflware, el cual mantiene el registro del número de marcas (interrupciones) a partir de cierta fecha acordada en el pasado. Llamaremos al valor de este reloj C. Más precisamente, cuando el tiempo UTC es 1, el valor del reloj en la máquina p es C(p) en un mundo perfecto, tendríamos C(p) = t para toda p y toda t. En otras palabras, C(p)/dt debería ser 1.

         Los cronómetros reales no realizan interrupciones exactamente H veces por cada segundo. En teoría, un cronómetro con H = 60 generaría 216 000 marcas por hora. En la práctica, el error relativo que se puede obtener con los circuitos de cronómetros modernos es de cerca de l0-5, lo que significa que una máquina particular puede obtener un valor en el margen que vade 215 998 a 216002 marcas por hora. Más precisamente, si existe una constante tal que

1-j < dC/dt < 1+j

se dice que el cronómetro trabaja dentro de su especificación. La constante j es especificada por el fabricante y se conoce como la tasa máxima de alejamiento. En la siguiente  figura se muestra un reloj lento, otro perfecto y otro rápido.


                                                               

Sidos relojes se alejan de UTC en la dirección opuesta, en un instante D t después de que fueron sincronizados, podrían estar tan alejados como 2*j *D t. Si los diseñadores del sistema operativo desean garantizar quedos relojes cualesquiera no dilieran más de j , entonces los relojes deben volverse a sincronizar (en software) al menos cada d /(2*j ) segundos. Los distintos algoritmos ditieren en la forma precisa en que se realiza esta resincronización.

  ALGORITMO DE CRISTIAN

Cometizaremos con un algoritmo adecuado para los sistemas en los que una máquina tiene un receptor wwV y el objetivo es hacer que todas las máquinas se sincronicen con ella. Llamaremos a la máquina con el receptor WWV un servidor del tiempo. Nuestro algoritmo se basa en el trabajo de Cristian (1989) y trabajos anteriores. En forma periódica, en un tiempo que no debe ser mayor que d /2j segundos, cada máquina envía un mensaje al servidor para solicitar el tiempo actual. Como primera aproximaclon. cuando el emisor obtiene la respuesta, puede hacer que su tiempo sea CUTC Sin embargo, este algoritmo tiene dos problemas, uno mayor y otro menor. El problema mayores que el tiempo nunca debe correr hacia atrás. Si el reloj del emisor es rápido. CUT( será mcnor que el valor actual de C del emisor. El simple traslado de CUTC podría provocar serios problemas, tales como tener un archivo objeto compilado justo después del cambio de reloj y que tenga un tiempo anterior al del archivo fuente, modificadojusto antes del cambio del reloj.

Tal cambio se debe introducir de manera gradual. Una forma es la siguiente. Supon-gamos que el cronómetro se ajusta para que genere 100 interrupciones por segundo. Lo normal sería que cada interrupción añadiera lo milisegundos al tiempo. Al reducir la velocidad, la rutina de interrupción sólo añade 9 milisegundos cada vez hasta que se haga la corrección. De manera similar, el reloj se puede adelantar de manera gradual, sumando 11 milisegundos en cada interrupción en vez de saltar hacia adelante de una vez.

El problema menor es que el tiempo que tarda el servidor en responder al emisor es distinto de cero. Peor aun, este retraso puede ser de gran tamaño y varía con la carga de la red. La forma de enfrentar este problema por parte de Cristianes intentar medirlo Es muy fácil para el emisor registrar de manera precisa el intervalo entreoí envío de la solicitud al servidor de tiempo y la llegada de la respuesta Canto el tiempo dc inicio. T0, como el tiempo final, T1, se miden con el mismo reloj, por lo que el intervalo será relativamente preciso aunque el reloj del emisor esté alejado de UTC por una magnitud sustancial.

En ausencia de otra infonnación, la mejor estimación del tiempo de propagación del mensajees de (T1 - T0)12. Al llegar la respuesta! el valoren el mensaje puede ser incrementado por esta cantidad para dar Lina estimación del tiempo actual del servidor. Si se conoce el tiempo mínimo de propagación teórico se pueden calcular otras propiedades de la estimación de tiempo. Esta estimación se puede mejorar si se conoce con cierta aproximación el tiempo que tarda el servidor dcl tiempo en manejar la interrupción y procesar cl mensaje recibido. Llamaremos al tiempo para el manejo de interrupción]. Entonces la cantidad del tiempo desde fl basta T1 dedicada a la propagación del mensaje es T1- T0-&iquest; por lo que una mejor estimación del tiempo de propagación en un sentido es la mitad de esta cantidad. Existen sistemas en los que los mensajes de A aB siguen de manera sistemática diferentes rutas de B aj, por lo que tienen un tiempo de propagación distinto, pero aquí no consideraremos estos sistemas.

Para niejorar la precisión, Cristian sugirió hacer no una modición, sitio varias. Cualquier medición en la que T1 – T0 exceda cierto valor límite se descarta, por ser considerada víctima del congestionarniento en la red y por tanto no confiable, Las stimaciones obtenidas de las de las demas pruebas se puedenm promediar para obtener el mejor valor. Otra alternativa es que el mensaje que regrese más rápido se considere como el más preciso, pues supuestamente encontraría menos tráfico y por lo tanto seria el más representativo del tiempo de propagación puro.


Libros Relacionados
books.google.co.ve/books?isbn=8484680630
books.google.co.ve/books?isbn=8436265491

No hay comentarios:

Publicar un comentario