ROJAS SANTIAGO CESAR

ROBERTO

Docente: Eduardo Lpez de los
Santos
Actividad : ENSAYO
Unidad 2
Instituto Tecnolgico Superior de
Coatzacoalcos
Sincronizacin en Sistemas Distribuidos

Ya hemos visto la forma en que los procesos se comunican entre si en un sistema distribuido. Los
mtodos que analizamos fueron los protocolos con capas, transferencia de mensajes
solicitud/respuesta (RPC incluida) y comunicacin en grupo. Aunque la comunicacin 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 crticas o asignar recursos en un sistema distribuido. En los sistemas con un CPU, los
problemas relativos a las regiones crticas, la exclusin mutua y la sincronizacin se resuelven en
general mediante mtodos tales como los semforos y los monitores. Estos mtodos no son
adecuados para su uso en los sistemas distribuidos, puesto que siempre se basan (de manera
implcita) en la existencia de la memoria compartida. Por ejemplo, dos procesos que interactan
mediante un semforo deben tener acceso a ste. Si se ejecutan en la misma mquina, pueden
compartir el semforo al guardarlo en el ncleo y realizar llamadas al sistema para tener acceso a
l. Sin embargo, si se ejecutan en mquinas distintas, este mtodo ya no funciona, por lo que se
necesitan otras tcnicas. Incluso las cuestiones ms sencillas, como el hecho de determinar si el
evento A ocurri antes o despus del evento B requiere una reflexin cuidadosa. Comenzaremos
con el tiempo y la forma de medirlo, puesto que ste juega un papel fundamental en algunos
modelos de sincronizacin.

SINCRONIZACIN DE RELOJES
La sincronizacin es ms 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 informacin relativa al sistema en un lugar y despus dejar que
cierto proceso la examine y tome una decisin, como se hace en el caso centralizado. En general,
los algoritmos distribuidos tienen las siguientes propiedades:
1. La informacin relevante se distribuye entre varias mquinas.
2. Los procesos toman las decisiones slo con base en la informacin disponible en forma local.
3. Debe evitarse un punto de fallo en el sistema.
4. No existe un reloj comn o alguna otra fuente precisa del ~iempo global.
Los primeros tres puntos indican que es inaceptable reunir toda la informacin en un lugar
para su procesamiento. Por ejemplo, para llevar a cabo la asignacin de recursos (asignar los
dispositivos de E/S en una forma libre dc 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 informacin de sus tablas. En un sistema de gran tamao, tal solucin pone en
predicamentos a dicho proceso.

Adems, el hecho de que slo exista un punto de fallo como ste hace que el sistema no sea
confiable. Lo ideal es que un sistema distribuido debera ser ms confiable que las mquinas
individuales. Si alguna de ellas falla, el resto puede continuar su funcionamiento. Lo ltimo que
quisiramos es una situacin donde una mquina falle (por ejemplo, el asignador de recursos) y
con ello detenga a un gran nmero de mquinas diversas. Para lograr la sincronizacin sin
centralizacin necesitamos algo distinto al caso dc los sistemas operativos tradicionales.
El ltimo punto de la lista tambin es crucial. En un sistema centralizado, el tiempo no tiene
ambiguedades. Cuando un proceso desea conocer la hora, llama al sistema y el ncleo se la dice. Si
el proceso A pide a hora y un poco despus, el proceso B tambin la pide, el valor obtenido por B
es mayor o igual que el valor obtenido porA. Ciertamente, no debe ser menor. En un sistema
distribuido, no es trivial poner de acuerdo a todas las mquinas 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 tamao se dividen por lo general en varios archivos fuentes,
de modo que un cambio al archivo fuente slo necesite una nueva compilacin de un archivo y no
de todos. Si un programa consta de 100 archivos y no hay que volverlo a compilar por la
modificacin 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 creacin 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 lahora2 145, entonces no es
necesario volvera 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
sincronizacin en los relojes puede sermuy drstico, como hemos visto, podemos iniciar nuestro
estudio de la sincronizacin con la siguiente sencilla pregunta: "Es posible sincronizar todos los
relojes en un sistema distribuido?
RELOJES LGICOS.
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., cronmetro sera una mejor palabra. Un cronmetro de computadora
es por lo general un cristal de cuarzo trabajado con precisin. Cuando se mantiene sujeto a
tensin, 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 tensin. A cada cristal se le asocian dos registros, un
contador y un registro mantenedor. Cada oscilacin del cristal disminuye en 1 a contador, cuando
el contador toma el valor 0, se genera una interrupcin y el contador se vuelve a cargar mediante
el registro mantenedor. De esta forma, es posible programar un cronmetro de modo que genere
una interrupcin 60 veces por cada segundo o con cualquier frecuencia que se desee. Cada
intenrupcin 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 nmero de mareas despus de cierta fecha conocida y
se guardan en la memoria. En cada marca de reloj, el procedimiento de servicio de interrupciones
aade 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 mquina utilizan el mismo reloj, tendrn 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 mquinas, cada una con su propio reloj, la situacin 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 prctica, cuando un
sistema tienen computadoras, los n cristales correspondientes oscilarn a tasas un poco distintas,
lo que provoca una prdida de sincrona en los relojes (de software) y que al leerlos tengan valores
distintos. La diferencia entre los valores del tiempo se llama distorsin del reloj. Como
consecuencia de esta distorsin, podran 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 estndar de tiempo nico, sin ambignedades. En un artculo clsico, Lamport(l
978) demostr que la sincronizacin de relojes es posible y present un algoritmo para lograr esto.
Ampli su trabajo en (Lamport, 1990). Lamport seal que la sincronizacin de relojes no tiene
que ser absoluta. Si dos procesos no interactian, no es necesario que sus relojes estn
sincronizados, puesto que la carencia de sincronizacin no seria observable y por tanto no podra
provocar problemas. Adems, senal que lo que importa por lo general, no es que todos los
procesos concuerden dc 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 mayora de los fines, basta que todas las mquinas coincidan en la misma hora. No es
esencial que esta hora tambin coincida con la hora real, como se anuncia en la radio cada hora.
Por ejemplo, para ejecutar nake, es adecuado que todas las mquinas estn 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 cercana al tiempo real. Para
estos algoritmos, conviene hablar de los relojes como relojes lgicos. Cuando existe la restriccin
adicional de que los relojes no slo deben ser iguales, sino que adems no se desven del tiempo
real ms ah de cierta magnitud, los relojes reciben el nombre de relojes fsicos". A continuacion
analizaremos elalgoritmo de Lamport, el cual sincroniza los relojes lgicos.
Lamport defini una relacin llamada ocurre antes de. La expresin A B se lee: A ocurre
antes de B, e indicaque todos los procesos coinciden en que primero ocurre el evento A y despus
el evento B. La relacrn "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 envio de un mensaje por un proceso y B es el evento de la recepcin del
mensaje por otro, entonces A ~ B tambin es verdadero. Un mensaje no se puede recibir antes de
ser enviado o al mismo tiempo en que se enva, puesto que tarda en llegar una cantidad finita de
tiempo.
"Ocurre antes de" es una relacin transitiva, de modo que si A B y B C, entonces A C. Si
dos eventos, X y Y, estn 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 cul de ellos es el primero. Lo que necesitamos es una
forma de medir el tiempo tal que, acada evento A, le podamos asociar un valor del tiempo C(A) en
el que todos los procesos estn de acuerdo. Estos valores del tiempo deben tener la propiedad de
que si A B , entonces C(A) < C(B). En otros trminos, si A y B son dos procesos dentro del mismo
evento y A ocurre antes de B, entonces C(A) < C(B). De manera anloga, si Aa es el envo de un
mensaje por un proceso y B la recepcin de ese mensaje por otro proceso, entonces C(A) y C{B)
deben ser asignados de tal forma que todos estn de acuerdo en los valores de C(a) y C(b) con C(a)
<C(b). Adems, el tiempo del reloj, C, siempre debe ir hacia adelante (creciente), y nunca hacia
atrs (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 asignacin de tiempos a
eventos. Consideremos los tres procesos que se muestran en la sig. figura. Los procesos se
ejecutan en diferentes mquinas, 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 razn constante, slo que las razones son diferentes debido a las
diferencias en los cristales.

Al tiempo 6, el proceso 0 enva 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 anloga el mensaje D,
de 1 a 0, sale en 64 y llega en 54. Es claro que estos valores son imposibles. Esta situacin es la que
hay que evitar.
La solucin de Lamport es consecuencia directa de la relacin "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 envo, de acuerdo con el reloj del emisor. Cuando un mensaje llegay el reloj del
receptor muestra un valor anterior al tiempo en que seenvi el mensaje. rpidamente el receptor
adelanta su reloj para que tenga una unidad ms que el tiempo de envo- En la figura 3-2(b),
vemos que C llega ahora a 61 - En forma anloga, D llega en 70. Con una pequea adicin, este
algoritmo cumple nuestras necesidades para el tiempo global. La adicin es que entre
cualesquiera dos eventos, el reloj debe marcar al menos una vez. Si un proceso enva o recibe dos
mensajes en serie muy rpida, 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 nmero 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 mtodo, 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 envo y la recepcin de un mensaje, C(A) <C(B).
3. Para todos los eventos A y B, C(A ) es diferente a C(b).
RELOJES FISICOS.
Aunque el algoritmo de Lampon proporciona un orden de eventos sin ambiguedades, 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 fisicos externos. Por razones de eficiencia y
redundancia, por lo general son recomendables varios relojes fisicos, lo cual implicados
problemas: (1) Cmo los sincronizamos con los relojes del mundo real? y (2)Cmo 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 podra pensar, en particular CUANDO se
requiere alta precisin. Desde la invencin de los relojes mecnicos en el siglo XVII, el tiempo se ha
medido de manera astronmica. Cada da, el sol parece levantarse en el horizonte del este, sube
hasta una altura mxima en el cielo y desciende en el oeste. El evento en que el sol alcanza su
punto aparentemente ms alto en el cielo se llama trnsito del sol. Este evento ocurre
aproximadamente a las doce del da de cada da. El intervalo entre dos trnsitos consecutivos del
sol se llama el da solar. Puesto que existen 24 horas en un da, cada una de las cuales contiene 3
600 segundos, el segundo solar se define exactamente como 1186400 de un da solar. La
geometra del clculo del da medio solar es:

En la dcada de 1940, se estableci que el perodo de rotacin de la tierra no es constante. La
tierra est disminuyendo su velocidad, debido a la friccin tidal y el arrastre atmosfrico. Con base
en estudios de los patrones de crecimiento del coral antiguo, los gelogos piensan ahora que hace
300 millones de aos existan cerca de 400 das al ao. La duracin del ao, es decir, el tiempo que
tarda la tierra en dar una vuelta alrededor del sol, no ha cambiado; slo ocurre que los das se
hacen ms largos. Adems de esta tendencia a largo plazo, tambin ocurren pequeas variaciones
a corto plazo en la duracin del da, lo cual probablemente se deba a una turbulencia originada en
el centro de acero fundido de la Tierra.
Estas revelaciones han llevado a los astrnomos a calcular la longitud del da mediante la
medicin de un gran nmero de das y tomar su promedio antes dc dividir entre 86400. La
cantidad resultante se llama el segundo solar promedio. Con la invencin del reloj atmico en
1948, fue posible medir el tiempo de manera mucho ms exacta y en forma independiente de
todo el ir y venir de la Tierra, al contar las transiciones del tomo de cesio 133. Los fsicos
retomaron de los astrnomos la tarea de medir el tiempo y definieron el segundo como el tiempo
que tarda el tomo dc cesio 133 en hacer exactamente 9 192 631 770 transictones. La eleccin de
9 192631 770 fue hecha para que el segundo atmico fuera igual al segundo solar promedio en el
ao de su introduccin. Actualmente, cerca de 50 laboratorios en el mundo tienen relojes de cesio
133. En forma peridica, cada laboratorio le indica a la oficina internacional de la hora en Pars
(BlM) el nmero demarcas de su reloj. La oficina hace un promedio de estos nmeros para
producir el tiempo atmico 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.
Aunque TAl 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 da solar medio (puesto que este da solar promedio es cada vez ms grande).El uso
de TAl para el registro del tiempo significara que, con el paso de los aos, el medioda sera cada
vez ms temprano, hasta llegar al momento en que el medioda ocurrirta en la maana. Las
personas notaran esto y podran estar en el mismo tipo de situacin ocurrida en 1582, cuando el
Papa Gregorio XIII decret que se deberan omitir del calendario diez das. Este suceso provoc
revueltas en las calles, puesto que los terratenientes demandaron una renta de todo un mes y los
banqueros un inters de todo el mes, mientras que los patrones se rehusaron apagara los
trabajadores por los diez das que no trabajaron, por mencionar unos cuantos de los conflictos. Los
pases protestantes, por cuestiones de principio, rechazaron todo lo que tena que ver con los
decretos papales y no aceptaron el calendario Gregoriano durante 170 aos.
La BIH resolvi el problema mediante la introduccin 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 acontinuacion). Esta correccin 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 estndar anterior, el tiempo dcl meridiano de
Greenwich, que es tiempo astronmico. La mayora de las compaas que proporcionan la luz
elctrica basan sus relojes de 60 Hz o 50 Hz en el UTC, por lo que cuando BIH anuncia un segundo
de salto, las compaas elevan su frecuencia a 61 Hz 051 Hz durante 60050 segundos, para que
avancen todos sus relojes del rea de disfribucin. 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 aos debe tener un soflware especial para registrar los segundos de salto
conforme sean anunciados (a menos que utilicen la lnea de corriente elctrica para medir su
tiempo, lo cual es demasiado burdo). El nmero 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 Estndar (NIST) opera una estacin 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 precisin
del propio WWV es de cerca de ti milisegundo, pero debido a la fluctuacin atmosfrica aleatoria
que puede afectar la longitud de la trayectoria de la seal, en la prctica la precisin no es mejor
que 110 milisegundos.Varios satlites terrestres tambin ofrecen un servicio UTC. Ej Satlite de
Ambiente Operacional Geoestacionario (GEOS) puede proporcionar UTC con una precisin de
hasta 0.5 milisegundos y algunos otros satlites lo hacen incluso mejor. El uso del radio de onda
corta o los servicios de satlite requiere de un conocimiento preciso de la posicin relativa del
emisor y el receptor, para compensar el retraso de la propagacin de la seal. Se dispone en forma
comercial de radio receptores de WWV, GEOS y las otras fuentes UTC. El costo vara desde unos
cuantos cientos de dlares hasta decenas de cientos de dlares cada uno, donde se paga ms por
las mejores fuentes. UTC tambin se puede obtener de manera ms barata, pero menos exacta,
por va telefnica, desde NrST en Fort Collins, pero aqu tambin hay que hacer una correccin por
la ruta de la seal y la velocidad del mdern. Esta correccin introduce por lo general cierta
imprecisin, lo que dificulta la obtencin dcl tiempo con una precisin extremadamente alta
ALGORITMOS PARA LA SINCRONIZACIN DE RELOJES.
Si una mquina tiene un receptor WWV, entonces el objetivo es hacer que todas las mquinas se
sincronicen con ella. Si ninguna mquina tiene receptores WWV, entonces cada mquina lleva el
registro de su propio tiempo y el objetivo es mantener el tiempo de todas las mquinas tan
cercano como sea posible. Se han propuesto muchos algontmos para lograr esta sincronizacin
(porejemplo, Cristian, 1989; Dmmmondy Babaoglu, y Kopetzy Ochsenre&iexcl;ter, 987). Todos los
algoritmos tienen el mismo modelo subyacente del sistema. que describiremos a continuacin. Se
supone que cada mquina tiene un cronmetro. el cual provoca una interrupcin H veces por cada
segundo. Cuando este cronmetro se detiene, el controlador de interrupciones suma l aun reloj en
soflware, el cual mantiene el registro del nmero de marcas (interrupciones) a partir de cierta
fecha acordada en el pasado. Llamaremos al valor de este reloj C. Ms precisamente, cuando el
tiempo UTC es 1, el valor del reloj en la mquina p es C(p) en un mundo perfecto, tendramos C(p)
= t para toda p y toda t. En otras palabras, C(p)/dt debera ser 1.
Los cronmetros reales no realizan interrupciones exactamente H veces por cada segundo. En
teora, un cronmetro con H = 60 generara 216 000 marcas por hora. En la prctica, el error
relativo que se puede obtener con los circuitos de cronmetros modernos es de cerca de l0
-5
, lo
que significa que una mquina particular puede obtener un valor en el margen que vade 215 998 a
216002 marcas por hora. Ms precisamente, si existe una constante tal que
1-j < dC/dt < 1+j
se dice que el cronmetro trabaja dentro de su especificacin. La constante j es especificada por el
fabricante y se conoce como la tasa mxima de alejamiento. En la siguiente figura se muestra un
reloj lento, otro perfecto y otro rpido.

Sidos relojes se alejan de UTC en la direccin opuesta, en un instante D t despus de que fueron
sincronizados, podran estar tan alejados como 2*j *D t. Si los diseadores del sistema operativo
desean garantizar quedos relojes cualesquiera no dilieran ms 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 resincronizacin.
ALGORITMO DE CRISTIAN
Cometizaremos con un algoritmo adecuado para los sistemas en los que una mquina tiene un
receptor wwV y el objetivo es hacer que todas las mquinas se sincronicen con ella. Llamaremos a
la mquina con el receptor WWV un servidor del tiempo. Nuestro algoritmo se basa en el trabajo
de Cristian (1989) y trabajos anteriores. En forma peridica, en un tiempo que no debe ser mayor
que d /2j segundos, cada mquina enva un mensaje al servidor para solicitar el tiempo actual.
Como primera aproximaclon. cuando el emisor obtiene la respuesta, puede hacer que su tiempo
sea C
UTC
Sin embargo, este algoritmo tiene dos problemas, uno mayor y otro menor. El problema
mayores que el tiempo nunca debe correr hacia atrs. Si el reloj del emisor es rpido. CUT( ser
mcnor que el valor actual de C del emisor. El simple traslado de C
UTC
podra provocar serios
problemas, tales como tener un archivo objeto compilado justo despus 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
cronmetro se ajusta para que genere 100 interrupciones por segundo. Lo normal sera que cada
interrupcin aadiera lo milisegundos al tiempo. Al reducir la velocidad, la rutina de interrupcin
slo aade 9 milisegundos cada vez hasta que se haga la correccin. De manera similar, el reloj se
puede adelantar de manera gradual, sumando 11 milisegundos en cada interrupcin 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 tamao y vara con la carga de la red. La forma de
enfrentar este problema por parte de Cristianes intentar medirlo Es muy fcil para el emisor
registrar de manera precisa el intervalo entreo envo de la solicitud al servidor de tiempo y la
llegada de la respuesta Canto el tiempo dc inicio. T
0
, como el tiempo final, T
1
, 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 infonnacin, la mejor estimacin del tiempo de propagacin del mensajees de
(T
1
- T
0
)12. Al llegar la respuesta! el valoren el mensaje puede ser incrementado por esta cantidad
para dar Lina estimacin del tiempo actual del servidor. Si se conoce el tiempo mnimo de
propagacin terico se pueden calcular otras propiedades de la estimacin de tiempo. Esta
estimacin se puede mejorar si se conoce con cierta aproximacin el tiempo que tarda el servidor
dcl tiempo en manejar la interrupcin y procesar cl mensaje recibido. Llamaremos al tiempo para
el manejo de interrupcin]. Entonces la cantidad del tiempo desde fl basta T
1
dedicada a la
propagacin del mensaje es T
1
- T
0
-&iquest; por lo que una mejor estimacin del tiempo de
propagacin en un sentido es la mitad de esta cantidad. Existen sistemas en los que los mensajes
de A aB siguen de manera sistemtica diferentes rutas de B aj, por lo que tienen un tiempo de
propagacin distinto, pero aqu no consideraremos estos sistemas.
Para niejorar la precisin, Cristian sugiri hacer no una modicin, sitio varias. Cualquier medicin
en la que T
1
T
0
exceda cierto valor lmite se descarta, por ser considerada vctima 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 ms rpido se considere como el ms preciso, pues supuestamente
encontrara menos trfico y por lo tanto seria el ms representativo del tiempo de propagacin
puro.