UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA POLITÉCNICA SUPERIOR

INGENERÍA
EN INFORMÁTICA

PROYECTO DE FIN DE CARRERA

Sincronización de una red de datos usando el Protocolo IEEE
1588.

Javier Andrés Hernández Cárdenas

Julio,2008
 UNIVERSIDAD DE CASTILLA - LA MANCHA
ESCUELA POLITÉCNICA SUPERIOR
Departamento de Informática

PROYECTO DE FIN DE CARRERA

Autor

Javier Hernández C.

Director

Luis Orozco-Barbosa

Julio,2008
 Reunido en la fecha el tribunal evaluador, que más abajo se cita, del Proyecto Fin de Carrera
titulado :
Sincronización de una Red de Datos usando el Protocolo IEEE 1588.
presentado por :
Javier Andrés Hernández Cárdenas
y siendo sus tutor(es) :
Luis Orozco-Barbosa

Trabajo de ejecución
(Hasta 4 puntos)
Según Informe de su/s Tutor/es .................................................
PRESIDENTE SECRETARIO VOCAL
Presentacion Escrita
(Hasta 2 puntos) : .............. .............. ..............

Presentacion/Defensa Oral
(Hasta 2 puntos) : .............. .............. ..............

Calidad Cientı́fico-Técnica
(Hasta 2 puntos) : .............. .............. ..............

Calificación (0-10)
(Suma de Items) : .............. .............. ..............

y en consecuencia se otorga la calificación de . . . . . . . . . . . . . .

Y para que ası́ conste, se firma la presente acta en Albacete a . . . . . de . . . . . de 20 . . . . .

PRESIDENTE : .....................................................
SECRETARIO : .....................................................
VOCAL : .....................................................

SECRETARIO PRESIDENTE VOCAL

Resumen

Ethernet ha demostrado ser un medio útil y barato para conectividad, pero no ha sido bien
aprovechado por aplicaciones que requieren una sincronización precisa. Por naturaleza es no deter-
minı́stico, lo que crea problemas para aplicaciones de tiempo real o sensibles al tiempo que requieren
sincronización. Sin embargo, el protocolo de precisión de tiempo (PTP) IEEE 1588 se sobrepone a
la latencia Ethernet y Jitter enviando a través de la red marcas de tiempo a la capa fı́sica de una
red.
PTP ofrece una mejor relación costo rendimiento que el estándar NTP usando redes ethernet
existentes, y sobrepasa la exactitud del protocolo NTP a través del uso de soluciones para realizar
marcas de tiempo basadas en hardware. PTP puede coexistir con tráfico normal de redes y redes
estándares usando para ello Boundary Clocks.
En este Proyecto de Fin de Carrera se demuestra las razones necesarias para alcanzar mayor
exactitud en una red de sincronización. A través de una serie de pruebas se exponen las ventajas
de la utilización de marcas de tiempo realizadas por Hardware en comparación de las hechas con
Software. También se demuestra cuales son las ventajas de usar hardware especializado para eliminar
el Jitter de la red y del protocolo, para esto se compara un Switch estándar versus un Boundary
Clock.

7
Agradecimientos

Este proyecto de Fin de Carrera cierra un ciclo de mi vida muy importante. Por eso quiero
agradecer a mi familia: Vicente, Gloria y mi hermana Jimena, que siempre han estado para darme
su aliento aún cuando hubo momentos de dificultad. A mis amigos de Punta Arenas que siempre
han estado para darme ánimo y no por conocerlos menos me puedo olvidar de la gente que he
conocido en Albacete que durante este corto periodo ha pasado ser mi Familia.
Agradezco a cada uno de mis profesores de la Universidad de Magallanes y particularmente la
gestión de Pedro Alberti, sin la cual no podrı́a haber sido posible mi estadı́a en la UCLM.
A mi director de Proyecto, Luis Orozco-Barbosa por permitirme trabajar junto a él. A Enrique
Arias por toda su ayuda entregada durante mi paso por Albacete.
Y finalmente agradezco a Dios por darme la fuerza y la salud para llegar a donde estoy hoy.

Javier Andres Hernandez Cardenas , Albacete, Julio 2008

8
Índice general

Resumen 6

Agradecimientos 7

Índice general 9

Índice de figuras 13

Índice de tablas 16

1. Introducción 17
1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.1.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.1.2. Objetivo Especı́fico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2. Organización del Proyecto de Fin de Carrera . . . . . . . . . . . . . . . . . . . . . . 18

2. Marco Teórico 19
2.1. Redes de Sincronización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.1. Redes Plesiócronas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.2. Redes Sincrónicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2. Protocolos de Sincronización de Relojes . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.1. Network Time Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.2. IRIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.3. Diferencias entre Protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3. Protocolo IEEE 1588 29

3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

9
ÍNDICE GENERAL 10

3.2. Descripción Detallada del Protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3. Jerarquı́a de Sincronización PTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4. Tipos de Relojes PTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.1. Grandmaster Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.2. Boundary y Transparent Clocks . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.3. Ordinary Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.5. Topologı́a de Comunicación PTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.6. Dominios PTP (PTP Domains) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.7. Estratos de un Reloj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.8. Reloj Master Favorecido (Preferred Master Clock) . . . . . . . . . . . . . . . . . . . 39
3.9. Identificador de Reloj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.10. Varianza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.11. Latencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.12. Intervalo de Sincronización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.13. Tipos de Mensajes PTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.13.1. Mensajes de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.13.2. Mensajes Generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.14. Puntos para Efectuar Marcas de Tiempo . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.15. Supuestos sobre el Protocolo PTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.16. Algoritmo Best Master Clock (BMC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.16.1. Visión General del algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.16.2. Conjunto de datos (Data Sets) . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.17. Usando el protocolo PTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.17.1. Capa Fı́sica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.17.2. Capa Lógica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.17.3. Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.17.4. Implementación Local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.18. Implementación Ethernet de IEEE 1588 . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.18.1. Direccionamiento Ethernet para PTP . . . . . . . . . . . . . . . . . . . . . . 53
3.18.2. Lógica de Direccionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4. Implementación de una Red de Sincronización 57

4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2. Implementación de la Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
ÍNDICE GENERAL 11

4.2.1. Hardware de Red Utilizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.2.2. Software Utilizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.2.3. Condiciones de Medición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.2.4. Métricas a Considerar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.3. Consideraciones Previas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.4. Resultados Experimentales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.4.1. Comparación de Relojes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.4.2. Sincronización con un Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.4.3. Sincronización con un Boundary Clock . . . . . . . . . . . . . . . . . . . . . . 82
4.4.4. Switch Versus Boundary Clock . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.4.5. PTPd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.5. Discusión Final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5. Conclusiones 95
5.1. Aspectos Relevantes y Aportes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.2. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Bibliografı́a 97
Índice de figuras

2.1. Clasificación de redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2. Red centralizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3. Red descentralizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4. Jerarquı́a NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5. Petición y respuesta NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1. Cálculo del offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2. Cálculo del delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3. Frecuencia de intercambio de mensajes PTP . . . . . . . . . . . . . . . . . . . . . . . 32
3.4. Jerarquı́a PTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5. Topologı́a prohibida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.6. Sistema tı́pico de relojes sincronizados . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.7. Puntos posibles para realizar marcas de tiempo . . . . . . . . . . . . . . . . . . . . . 43
3.8. Retardo de red y de la pila del protocolo . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.1. Servidor de tiempo GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.2. Configuración Grandmaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3. Tarjeta Ethernet IEEE 1588 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.4. Arquitectura tarjeta Ethernet IEEE 1588 . . . . . . . . . . . . . . . . . . . . . . . . 60
4.5. Tarjeta de desarrollo Imsys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.6. Arquitectura tarjeta Imsys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.7. Captura pantalla Developer Imsys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.8. Syncbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.9. Configuración Syncbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.10. Configuración Switch Boundary Clock . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.11. Switch Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
13
ÍNDICE DE FIGURAS 14

4.12. Generador de tráfico Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.13. Captura pantalla interfaz Generador de tráfico Ethernet . . . . . . . . . . . . . . . . 67
4.14. Configuración de paquetes en el generador de tráfico Ethernet . . . . . . . . . . . . . 68
4.15. Configuracion de tráfico en el generador de tráfico Ethernet . . . . . . . . . . . . . . 68
4.16. Captura de pantalla PTP Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.17. Vista jerarquı́a de red en PTP Manager . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.18. Arquitectura PTPd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.19. Esquema de sincronización usando un Boundary Clock . . . . . . . . . . . . . . . . . 73
4.20. Sincronización con tarjeta Imsys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.21. Sincronización con tarjeta PCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.22. Sincronización con SyncBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.23. Asimetrı́a en el retardo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.24. Boundary Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.25. Esquema de sincronización usando un Switch . . . . . . . . . . . . . . . . . . . . . . 77
4.26. Esquema de sincronización usando un Switch y aplicando carga . . . . . . . . . . . . 78
4.27. Switch sin carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.28. Switch utilizando 5 % de ancho de banda y carga continua . . . . . . . . . . . . . . . 79
4.29. Switch utilizando 25 % de ancho de banda y carga continua . . . . . . . . . . . . . . 79
4.30. Switch utilizando 60 % de ancho de banda y carga continua . . . . . . . . . . . . . . 80
4.31. Switch utilizando 5 % de ancho de banda y carga a ráfagas . . . . . . . . . . . . . . . 80
4.32. Switch utilizando 25 % de ancho de banda y carga a ráfagas . . . . . . . . . . . . . . 81
4.33. Switch utilizando 60 % de ancho de banda y carga a ráfagas . . . . . . . . . . . . . . 81
4.34. Diagrama de envı́o de mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.35. Esquema de sincronización usando un Boundary Clock . . . . . . . . . . . . . . . . . 82
4.36. Esquema de sincronización usando un Boundary Clock y aplicando carga . . . . . . 83
4.37. Boundary Clock sin carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.38. Boundary Clock utilizando 5 % de ancho de banda y carga continua . . . . . . . . . 84
4.39. Boundary Clock utilizando 25 % de ancho de banda y carga continua . . . . . . . . . 85
4.40. Boundary Clock utilizando 60 % de ancho de banda y carga continua . . . . . . . . . 85
4.41. Boundary Clock utilizando 5 % de ancho de banda y carga a ráfagas . . . . . . . . . 86
4.42. Boundary Clock utilizando 25 % de ancho de banda y carga a ráfagas . . . . . . . . . 86
4.43. Boundary Clock utilizando 60 % de ancho de banda y carga a ráfagas . . . . . . . . . 87
4.44. Switch versus Boundary Clock, sin carga . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.45. Switch versus Boundary Clock, utilizando 5 % de ancho de banda y carga continua . 88
ÍNDICE DE FIGURAS 15

4.46. Switch versus Boundary Clock, sin carga (Histogramas) . . . . . . . . . . . . . . . . 89

4.47. Esquema de sincronización para PTPd . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.48. Gráfico de sincronización usando PTPd . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.49. Gráfico de sincronización usando PTPd luego de perı́odo de estabilización . . . . . . 91
Índice de tablas

2.1. Tabla comparativa de protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1. Definiciones de números de estratos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2. Identificadores de reloj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3. Puertos usados en implementación Ethernet de PTP. . . . . . . . . . . . . . . . . . . 53
3.4. Puertos usados en implementación Ethernet de PTP. . . . . . . . . . . . . . . . . . . 53
3.5. Cardinalidad de paso de mensajes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.1. Tabla Comparativa Switch versus Boundary Clock sin carga . . . . . . . . . . . . . . 91

4.2. Tabla comparativa de relojes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.3. Tabla comparativa para el Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.4. Tabla comparativa para el Boundary Clock . . . . . . . . . . . . . . . . . . . . . . . 93

16
Capı́tulo 1

Introducción

La medición del tiempo se remonta hace muchos años atrás cuando se utilizaban relojes de sol,
de arena, o de agua como referencia, hasta llegar en la actualidad a los modernos relojes atómicos,
que se basan en la frecuencia de vibración atómica del Cesium 133 para determinar la hora.
Conocer la hora es importante debido a que usualmente se quiere saber en que momento ocurre
un evento. La precisión y exactitud dependerá de la aplicación. Para una persona que espera tren,
un retardo de este de algunos segundos no causará problemas, pero para un atleta cuya finalidad
es romper una marca, un microsegundo puede ser la diferencia entre ganar o perder. Esta misma
analogı́a se puede llevar al terreno de los ordenadores donde según la aplicación será la precisión
y exactitud requerida. En los ordenadores comúnes y corrientes que hay en nuestros hogares un
segundo de más o de menos no tendrá mayor significancia, pero en el caso de una transacción
bancaria registrar la hora exacta es muy importante.
Pero no solamente basta con conocer la hora, la sincronı́a es tan importante como determinar
con exactitud la hora. Necesitamos sincronı́a cotidianamente. Para llegar a tiempo al trabajo, a la
universidad, a una cita, etcétera. Nuestra sociedad actual está determinada por la sincronización.
Y lo mismo suceden en los sistemas de comunicación actuales, la sincronı́a de emisor y receptor
es muy importante, donde cada fracción de segundo podrı́a significar mucho dinero, por ejemplo:
pensemos en un sistema de facturación telefónica, donde se cobra por cada segundo de comunicación,
si ocurriese algún fallo en la sincronización podrı́a significar millonarias pérdidas.

17
1.1. OBJETIVOS 18

1.1. Objetivos

1.1.1. Objetivo General

Este Proyecto de Fin de Carrera tiene como principal objetivo alcanzar la sincronización con
mayor exactitud y precisión posible de una red de datos, para ello se utilizará el protocolo IEEE
1588. Se busca la mejor configuración posible que reduzca los tiempos de latencia de la red.

1.1.2. Objetivo Especı́fico

Implementar una red de sincronización utilizando el protocolo IEEE 1588.

Medir y comparar distintas configuraciones.

Analizar los resultados obtenidos en las diferentes implementaciones.

De los resultados obtenidos indicar cual es la implementación que presenta los mejores resul-
tados.

1.2. Organización del Proyecto de Fin de Carrera

Este Proyecto de Fin de Carrera está organizado en 5 capı́tulos :

En el Capı́tulo 1, se introduce el tema comprendido en esta memoria.

En el Capı́tulo 2, se expone lo más importante de la redes de sincronización de datos.

En el Capı́tulo 3, se profundiza acerca del Protocolo IEEE 1588, dando a conocer sus princi-
pales caracterı́sticas.

En el Capı́tulo 4, se presenta el desarrollo de la implementación de la red de sincronización.

En el Capı́tulo 5, se presentan resultados de las pruebas realizadas y las conclusiones finales.

Capı́tulo 2

Marco Teórico

2.1. Redes de Sincronización

Las redes de sincronización tienen como finalidad distribuir información de tiempo y frecuencia
sobre una red de relojes, los cuales están en diferentes ubicaciones y normalmente están interconec-
tados. La intensión es sincronizar en tiempo y frecuencia las escalas de todos los relojes a lo largo de
la red . En algunas aplicaciones el interés es establecer, distribuir y mantener una referencia de tiem-
po como por ejemplo el GMT (Greenwich Mean Time). La hora local puede ser obtenida sumando
el offset de tiempo apropiado. Estas son algunas de las aplicaciones de las redes de sincronización:

Sistema de distribución de tiempos de alcance mundial.

Sincronización de relojes localizados en puntos de multiplexado en una red digital de comu-

nicaciones.

Sistema GPS de posicionamiento global, que determinan latitud, longitud y altura, de uso en
navegación aérea, marı́tima, para mediciones entre nodos de una red, etc.

Establecimiento de sistema de supercomputadores interconectando computadores en paralelo

en una red sincronizada.

Según la naturaleza de las señales de control empleadas para conseguir la sincronización, las
redes de distribución de tiempo y frecuencia pueden ser divididas en dos categorı́as: plesiócronas
(plesio = casi) y sincrónicas.
En las redes sincrónicas, todos los relojes están coordinados ya sea en fase como en frecuencia,
en las redes plesiócronas, la red consiste en un conjunto de relojes muy precisos con offset y deriva
de frecuencia sumamente bajos.
19
2.1. REDES DE SINCRONIZACIÓN 20

Figura 2.1: Clasificación de redes

2.1. REDES DE SINCRONIZACIÓN 21

2.1.1. Redes Plesiócronas

En una red plesiócrona cada nodo tiene su propio reloj de muy alta precisión y no existen señales
de control que coordinen los relojes.
Inicialmente los relojes son sincronizados. Esta calibración puede hacerse en forma centralizada
antes de transportar los relojes a su posición definitiva o puede hacerse mediante un reloj viaje-
ro. Como los relojes en una red plesiócrona son independientes, sus frecuencias al correr libres,
son ligeramente diferentes unas de otras. Esta diferencia de frecuencia lleva a un error de tiempo
linealmente creciente entre los relojes de la red.
Otros factores, como la deriva de frecuencia y el ruido de fase, también contribuyen a la acumu-
lación de errores de tiempo en nodos de la red. Este error de tiempo puede eventualmente exceder
un valor establecido al cual la operación de la red debe ser detenida y el reloj reinicializado. El
perı́odo entre actualizaciones es una función de la calidad de relojes y diferencia de tiempo tolerable
entre relojes de la red.
La ventaja de las redes plesiócronas es su facilidad de implementación y su robustez a la fallos,
debido a que una falla en un determinado reloj no afecta a ningún otro reloj en la red debido a su
independencia. La mayor desventaja, es su alto costo de compra y mantenimiento de los relojes de
alta precisión. El sistema GPS es de tipo plesiócrono con actualización de los relojes cada 24 horas
mediante un reloj atómico de Cesium 133.

2.1.2. Redes Sincrónicas

Los relojes en las redes sincrónicas están enganchados en fase y frecuencia a una red común de
sincronización.

Redes centralizadas: utilizan la técnica de sincronización Master - Slave en la cual todos los
relojes de la red están directa o indirectamente esclavizados a un reloj master. El reloj master
distribuye las escalas de tiempo y frecuencia de red (Ver Figura 2.2).

Redes descentralizadas: están basadas en el principio de sincronización mutua. Este tipo de

redes no tienen un reloj master, en lugar de eso, todos los relojes contribuyen igualmente a la
determinación de la escala de tiempo y frecuencia de la red (Ver Figura 2.2).
2.1. REDES DE SINCRONIZACIÓN 22

Figura 2.2: Red centralizada

Figura 2.3: Red descentralizada

2.2. PROTOCOLOS DE SINCRONIZACIÓN DE RELOJES 23

2.2. Protocolos de Sincronización de Relojes

Actualmente, la distribución de tiempo es lograda a través del uso de redes inalámbricas, lı́neas
telefónicas, o redes de datos como Internet. Los protocolos basados en radio señales son costosos
debido a la gran cantidad de hardware que requieren. A pesar de esto, sigue siendo ampliamente
utilizado debido a su fiabilidad.
Gran parte de las comunicaciones estan basadas en el protocolo TCP/IP, lo que hace que tenga
sentido usar este medio de comunicación para la sincronización. El tiempo mantenido en Internet
ha llegado a ser un servicio popular que se extiende a cientos de miles de servidores públicos
en muchos paı́ses distintos. Muchos protocolos distintos fueron desarrollados : Time Protocol[1],
Daytime Protocol[2], Network Time Protocol (NTP) [3], Simple Network Time Protocol (SNTP)
[4], y el más reciente, Precision Time Protocol (PTP).
A continuación se describe algunos de los protocolos más importantes :

2.2.1. Network Time Protocol

NTP es uno de los protocolos más populares usado para la sincronización de tiempo en Internet.
La version 3 del protocolo fue desarrollada por David Mills en 1992 .

Figura 2.4: Jerarquı́a NTP

2.2. PROTOCOLOS DE SINCRONIZACIÓN DE RELOJES 24

El protocolo NTP es usado para lograr sincronización entre un servidor de tiempo confiable y
sus clientes, puede lograr una precision de decenas de milisegundos.
La arquitectura de sincronización usa el concepto de estrato (modelo jerárquico de árbol, con
cada servidor sobre un nivel (estrato) sirviendo a los niveles más bajos). Los servidores primarios
son la raı́z de árbol como estrato 1 y están sincronizados a un reloj externo fuente de referencia
como por ejemplo un reloj atómico (estrato 0) .Cada siguiente nivel, tiene un estrato más arriba
que precede al nivel y el valor máximo permitido de estratos es 15 (Figura 2.4).

Implementación del Protocolo NTP.

El principio de sincronización básico es que cada cliente envı́an periódicamente peticiones a el

conjunto de servidores de tiempo que responden con marca de tiempo local. La lista de servidores
adecuados es mantenida por cada cliente y es actualizada periódicamente. Los algoritmos internos
evalúan las marcas de tiempo de todos los servidores para seleccionar el mejor sevidor. El mejor es
uno con el el más bajo estrato y distancia de sincronización , el cual es usado para configurar la
actualización del reloj.
El tiempo es calculado desde una colección de cuatro marcas de tiempo (dos de un servidor y
dos de si mı́smo) (Figura 2.5). Un cliente envı́a un mensaje NTP request que contiene la marca
original de tiempo CT1( marca de tiempo del cliente). Una vez recibido el NTP request, el servidor
genera la marca de tiempo de recepción ST1 (marca de tiempo del slave).
Después de procesar la petición , el servidor envı́a de regreso al cliente el NTP reponse con el
tiempo original ST2.
El cliente recibe el NTP response y genera la marca de tiempo de recepción CT2 Los siguientes
cálculos son realizados a nivel del cliente y slave.

ST1 = CT1 + Dcs + Ocs (2.1)

Donde Dcs es el retardo de la red entre cliente y servidor y Ocs es el offset del reloj entre el
cliente y la referencia al servidor.

ST1 = CT1 + Dcs + Ocs (2.2)

Donde Dcs es el retardo de red entre el servidor y el cliente y Osc es el offset del reloj entre el
servidor en referencia al cliente.
Sumando (2.1) y (2.2) , y debido a que Ocs = −Ocs , el viaje redondo es :
2.2. PROTOCOLOS DE SINCRONIZACIÓN DE RELOJES 25

Figura 2.5: Petición y respuesta NTP

Dsc + Dcs = (ST1 − CT1 ) + (CT2 − ST2 ) (2.3)

Restando (2.2) de (2.1) y asumiendo el mismo retardo , Dcs = Dsc , el offset es :

(ST1 − CT1 ) + (CT2 + ST2 )

Ocs = (2.4)
2
NTP está basado en el protocolo UDP/IP y es una implementación de software que no considera
la utilizacion de hardware especializado, en el caso que las marcas de tiempo fueran tomadas en la
capa de aplicación.

Posibles Fuentes de Error en NTP

Muchos factores podrı́an afectar la calidad de la coordinación y el cálculo de offset y delay. Entre
ellos:

Propagación asimétrica entre cliente y servidor.

Fluctuaciones en la pila del protocolo entre la capa de aplicación y la conexión fı́sica.

Medición errónea de marcas de tiempo.

Estabilidad del reloj oscilador.

2.2. PROTOCOLOS DE SINCRONIZACIÓN DE RELOJES 26

Cada servidor NTP mantiene su offset del reloj local y el tiempo de ida y vuelta relativo a la
fuente primaria, localizada en la raı́z del árbol de sincronización. Por lo tanto, cuando un cliente
envı́a un NTP request antes de enviar una respuesta con marcas de tiempo, el servidor suma su
error acumulado desde que su reloj fue actualizado. De esta manera el offset del reloj y el tiempo
de retardo ida y vuelta aumentan a medida que el nivel de estrato desde la fuente de referencia
primaria.

2.2.2. IRIG

El Telecommunications Working Group of the Inter-Range Instrumentation Group, y el stan-

dards body of the Range Commanders Council, crearon los códigos de tiempo Inter-Range Instru-
mentation Group, comúnmente conocidos como códigos de tiempo IRIG.
La estandarización de códigos de tiempo IRIG permite a equipos estar sincronizados a una
referencia de tiempo conocida. Esto también entrega facilidades para ser sincronizadas a localidades
separadas geográficamente. En la práctica, muchos laboratorios están equipados con dispositivos
que crean códigos de tiempo IRIG a partir de tiempo GPS satelital y lo distribuye en códigos de
tiempo a otros dispositivos.
El estándar IRIG consiste de una familia de códigos de tiempo seriales conteniendo hasta 3
expresiones codificadas o palabras. La primera palabra del marco de código de tiempo es el año en
BCD (Binary Code Decimal) con notación en dias, horas, segundos, y fracciones de segundos. La
segunda palabra es un conjunto de bits reservados para codificación de varias funciones de control,
identificación, y otros propósitos especiales. La tercera palabra corresponde a los segundos del dia
ponderados segun notación SBS (Straight Binary Seconds).
La version más común de IRIG es IRIG-B. El código de pulso IRIG-B contiene un frame de 100
elementos por segundo para el tiempo de un año y estado del receptor GPS. IRIG-B codifica datos
de dı́a del año, hora, minuto, y segundo en una frecuencia portadora de 1 kHz, con una actualización
una vez por segundo.
Los sistemas electrónicos modernos de hoy dı́a como los sistemas de comunicación, sistemas de
manejo de datos, rastreo de aeronavaes y satélites, y sistemas de telemetrı́a requieren información
de tiempo para correclación de datos.

2.2.3. Diferencias entre Protocolos

IRIG es tan bien conocido como el protocolo NTP. IRIG se usa para sincronización de una
red. PTP ofrece ventajas claves sobre otras tecnologı́as de sincronización como IRIG y NTP. Por
2.2. PROTOCOLOS DE SINCRONIZACIÓN DE RELOJES 27

ejemplo, IRIG emplea una conexión análoga dedicada entre el reloj y cada slave. PTP no requiere
tal conexión punto a punto. PTP también puede alcanzar exactitud por debajo del rango de los
microsegundos, lo que IRIG no logra hacer.
Como PTP, NTP también usa marcas de tiempo en paquetes para realizar la sincronización
de la red. Sin embargo las marcas de tiempo están hechas con software y no con hardware, lo
que causa un procesamiento asimétrico del retardo, que reduce la exactitud de la transferencia de
tiempo. También, la falta de Switches especiales como los llamados Boundary Clocks y Transparent
Clocks para mitigar el efecto de las colas, más allá de contribuir a retardos asimétricos y errores
de trasferencia de tiempo. PTP habilita a los dispositivos para que puedan descubir otros para
formar redes de sincronización optimizadas, una caracterı́stica de la cual carece NTP. NTP habilita
el autodescubrimiento de servidores NTP, pero no asegura que las fuentes o caminos sean óptimos.
A pesar de todas estas ventajas, existen ocasiones en que es más conveniente IRIG o NTP, que
PTP. Por ejemplo, el despliegue de IRIG puede ser más simple o requerir menos tiempo, especiale-
mente si una exactitud de 10 microsegundos es suficiente y hay pocos elementos que sincronizar. Si
el slave está demasiado apartado. Entonces puede ser más simple conectar una fuente IRIG a cada
ubicación y hacer algo con él. Las redes PTP deben ser testeadas para asegurarse que funcionan
dentro de rangos desables, y las redes pueden necesitar ser reconfiguradas si el funcionamiento no
es el deseado.
NTP es generalmente incompatible para la siguiente generación de aplicaciones de instrumentos
de medida. El funcionamiento a nivel de microsegundos puede ser inadecuado y el funcionamiento
de PTP puede variar ampliamente. Las cuales son las principales razones por las que PTP fue
inventada para instrumentos de sincronización.
En la tabla 2.1 se presenta en resumen las diferencias entre los protocolos.
2.2. PROTOCOLOS DE SINCRONIZACIÓN DE RELOJES 28

IEEE1588 IRIG NTP

Error máximo 100 ns - 100 us 10 us 1 - 100 ms
Tipo de Red Ethernet Coaxial dedicado Ethernet
Extencion Tı́pica Pocas subredes 1 milla por coaxial LAN - WAN
Estilo Master - Slave Master - Slave Cliente - Servidor
Protocolos UDP-IP multicast UDP-IP unicast
Corrección de Latencia Si Usuario ingresa largo Si
de cable para el slave
Administracion de red Autoorganizada Configurada Configurada
Hardware para cliente de tiempo Requerido para alta Requerido No
exactitud
Intervalo de Actualización 2 Segundos aprox. 1 pulso por segundo Varios minutos

Tabla 2.1: Tabla comparativa de protocolos

Capı́tulo 3

Protocolo IEEE 1588

3.1. Introducción
En este capı́tulo se presenta en forma detallada las caracterı́sticas más importantes del protocolo
IEEE 1588.
El protocolo IEEE 1588 fue desarrollado originalmente por Agilent Technologies para instru-
mentación distribuida y tareas de control. La técnica está basada en el trabajo de John Eidson,
quien como jefe del comité de estandarización del IEEE es responsable de la aprobación del estándar
en noviembre de 2002.
Haciendo uso del protocolo IEEE 1588, es posible por primera vez sincronizar, en el rango menor
a microsegundos, el reloj local de sensores, actuadores, y otros dispositivos terminales usando la
misma red Ethernet que se usan para tranportar datos.
Sin tal protocolo de sincronización , el cual está definido para usar cualquier protocolo, no sólo
Ethernet, serı́a imposible sincronizar relojes en dispositivos terminales de distintos fabricantes con
esta precisión.
Los protocoles exitentes anteriormente no alcanzaban la exactitud requerida o la velocidad de
convergencia.

3.2. Descripción Detallada del Protocolo

Cada nodo PTP slave se sincroniza al reloj del master mediante el intercambio de mensajes. El
proceso de sincronización esta dividido en dos fases. Primero es corregida la diferencia de tiempo
29
3.2. DESCRIPCIÓN DETALLADA DEL PROTOCOLO 30

entre el master y cada uno de los nodos denominados slave ; esta diferencia de tiempo se conocida
como offset.

Figura 3.1: Cálculo del offset

Durante la corrección del offset, el master cı́clicamente transmite mensajes de sincronización al

nodo slave a intervalos definidos (por defecto cada 2 segundos). Estos mensajes de sincronización
contienen un valor estimado para el tiempo exacto en que el mensaje ha sido transmitido.
Para una sincronización de muy alta exactitud, un mecanismo determina el tiempo de trasmisión
y recepción de mensajes PTP tan precisamente y cerca a la capa fı́sica como sea posible.
El reloj master mide el tiempo exacto de transmisión TM1 y el reloj slave mide el tiempo exacto
de recepción TS1. Entonces, luego el master envı́a en un segundo mensaje, el mensaje Folow Up,
conteniendo el tiempo exacto de transmisión TM1 del correspondiente mensaje Sync al reloj slave.
Luego de la recepción de un mensaje Sync y, a fin de incrementar exactitud, en la recepción
3.2. DESCRIPCIÓN DETALLADA DEL PROTOCOLO 31

del correspondiente mensaje Follow Up, el reloj slave realiza el cálculo del offset en relación al reloj
master tomando en cuenta la marca de tiempo del mensaje Sync. El reloj slave Ts debe entonces
ser corregido con este offset.
Si no existiese demora sobre el camino de transmisión, ambos relojes ahora serı́an sı́ncronos.
La segunda fase del proceso de sincronización, la medición del delay, determina el delay o latencia
entre el master y el slave. Para este propósito el reloj slave envı́a un paquete Delay request al master
y durante este proceso determina el tiempo exacto de transmisión del mensaje TS3. El master genera
una marca de tiempo en la recepción del paquete y envı́a el tiempo de recepción TM3 de regreso al
slave en el paquete Delay Response .

Figura 3.2: Cálculo del delay

De la marca de tiempo local para la transmisión TS3 y la marca de tiempo para recepción
3.3. JERARQUÍA DE SINCRONIZACIÓN PTP 32

entregada por el master TM3, el slave calcula el delay entre master y slave.
La medición del delay (retardo de lı́nea) es realizado irregularmente y a mayores intervalos (entre
4 y 60 segundos) que la medición del Offset ( Ver Figura 3.3). De este modo, la red, y particularmente
los dispositivos terminales, no se sobrecargaran con excesivo tráfico. Sin embargo, un retardo de
lı́nea (delay) simétrico es crucial para la medición del retardo y su precisión, es decir, el mismo valor
en ambas direcciones.
Usando este proceso de sincronización, las fluctuaciones de tiempo en los elementos PTP espe-
cialmente en la pila del protocolo y la latencia entre master y slave son eliminadas.

Figura 3.3: Frecuencia de intercambio de mensajes PTP

3.3. Jerarquı́a de Sincronización PTP

Los dispositivos PTP funcionan autónomamente descubriendo otros dispositivos en la red y
configurándose por sı́ solos en una jerarquı́a de árbol optimizada. Lo que resulta en una red de
3.4. TIPOS DE RELOJES PTP 33

sincronización robusta y flexible que elimina la configuración de dispositivos individuales, reduciendo

la carga de trabajo durante la configuración del sistema.
Cada puerto de red con capacidad PTP en un dispositivo usa el algoritmo Best Master Clock
(BMC) para evaluar los otros dispositivos en la red y determinar su papel como Master (M), Slave
(S), y Pasivo (P), como se muestra en la figura 3.4.

Figura 3.4: Jerarquı́a PTP

En la parte superior de la jerarquı́a se encuentra el reloj Grandmaster. El reloj gandmaster

está equipado habitualmente con una fuente de referencia como un reloj GPS. Sistemas de alta
disponibilidad pueden ser equipados con Grandmaster redundantes. Si uno de los Grandmaster
falla, la jerarquı́a de sincronización se reorganiza alrededor del Grandmaster restante.

3.4. Tipos de Relojes PTP

3.4.1. Grandmaster Clock

La exactitud del reloj es la función mas importante del master clock PTP (también llamado
Grandmaster) la cual es fuente principal de tiempo para toda la red. Los GrandMaster por lo general
están referenciados a otros relojes, por ejemplo GPS que poseen más exactitud y estabilidad. Los
3.4. TIPOS DE RELOJES PTP 34

Relojes Grandmaster necesitan ser capaces de soportar cientos o miles de clientes PTP.
Un Reloj GrandMaster necesita tomar en cuenta aquellos elementos de infraestructura de la red
tales como enrutadores y switches que tienen un efecto en la exactitud de tiempo y transferencia
cuando se usa PTP. Los Switches y en particular los enrutadores agregan latencias no determinı́sticas
y “jitter” a paquetes de tiempo en tránsito desde el master al slave. Como resultado, la exactitud
de la sincronización del slave se degrada con respecto a la del master. Un Hub interviene el mı́nimo
mientras que un Switch Ethernet puede fácilmente agregar cientos de nanosegundos de retardo no
determinı́stico a los paquetes que transitan por la red. El retardo de los enrutadores no hace mejor
al protocolo IEEE 1588 que NTP, en términos de exactitud de sincronización.

3.4.2. Boundary y Transparent Clocks

El protocolo PTP tambien agrega nuevos elementos especializados como Boundary Clocks y
Transparent Clocks que agregan funcionalidades para conservar la exactitud del reloj a través de
la red. El Boundary Clock es un switch multipuertos que contiene un puerto que es slave al reloj
master, mientras que los otros puertos son masters de los slaves en cascada. El Boundary Clock
entrega un método adecuado para regularizar la sincronización de un número de subredes.
Sin embargo, usar muchos Boundary Clocks en cascada acumulan offset de tiempo no lineal
en los servo loops, resultando en una degradación inaceptable de la exactitud. A fin de evitar este
problema, una opción serı́a tener un reloj Grandmaster sirviendo como slave en la red. Esto es
extremadamente útil para medir con exactitud la transferencia de tiempo de la red suponiendo un
slave PTP separado del Grandmaster por los elementos de red o topologı́a
El Transparent Clock es otra posible solución en redes basadas en PTP. Eso supone un switch
PTP mejorado el cual modifica las marcas de tiempo precisas dentro de los mensajes Delay Resp
y Follow Up para contar el retardo recibido y transmitdo dentro del mismo switch. Esto permite
mejorar la sincronización entre los relojes master y slave. Sin embargo, el Transparent Clock puede
crear problemas de seguridad cuando el cheksum del paquete original no corresponde con el paquete
final que llega al slave.

3.4.3. Ordinary Clocks

Un Ordinary Clock PTP es lo que comúnmente se conoce como un cliente PTP. Es un reloj con
un único puerto PTP y tı́picamente esta al final del sistema. Puede adoptar el estado de master o
slave segun lo determine el algoritmo BMC.
3.5. TOPOLOGÍA DE COMUNICACIÓN PTP 35

3.5. Topologı́a de Comunicación PTP

La operación del protocolo PTP genera una topologı́a de caminos de comunicación PTP forman-
do una estructura de grafos acı́clicos. Es decir, no serán caminos alternados de comunicación PTP
entre ningún par de relojes PTP. Un ejemplo de un camino prohibido de la topologı́a es el camino
acı́clico que forman los nodos 13,14 y 15 en la figura 3.5. Los rectángulos representan nodos conte-
niendo un reloj, los rectángulos redondeados representan nodos los cuales contienen un Boundary
Clock.

Figura 3.5: Topologı́a prohibida

El protocolo PTP detecta tales caminos cı́clicos en los caminos de comunicación PTP. El proto-
colo cambia grafos cı́clicos en grafos acı́clicos cambiando el estado de los puertos en los Boundary
Clocks involucrados. En este ejemplo el protocolo ha deshabilitado la comunicación entre nodos 14
y 15, o más precisamente, los ha puesto en modo pasivo. El estado de los puertos depende de los
detalles sobre la configuración de la red y las propiedades del reloj. Los cambios hacen que la comu-
nicación sea sobre una topologı́a acı́clica a pesar de que la conexión fı́sica es sobre una topologia
cı́clica.
No hay requerimientos de que todos los caminos del protocolo PTP usen los mismos medios
de comunicación subyacente. Sin embargo, si diferentes medios de comunicación están presentes
debieran separarse diferenciando por Boundary Clock.
Los Boundary Clocks separan subdominios PTP en distintos caminos de comunicación PTP. La
comunicación involucrando Boundary Clocks debiera ser restringida como sigue :

Mensajes PTP del tipo Sync, Delay Req, Follow UP, y Delay Resp debieran no ser propagados
3.6. DOMINIOS PTP (PTP DOMAINS) 36

entre caminos de comunicación PTP separados por un Boundary Clock. Esta restricción se
aplica los Boundary Clock y a cualquier componente especı́fico de comunicación habilitando
comunicación común entre dispositivos sobre caminos separados.

Mensajes administrativos PTP debieran ser comunicados entre caminos de comunicación PTP
separados por un Boundary Clock. Estos mensajes PTP debieran ser comunicados por un
Boundary Clock pero no debieran ser comunicados por algún componente especı́fico de comu-
nicación habilitando comunicación común entre dispositivos sobre caminos de comunicación
PTP separados.

3.6. Dominios PTP (PTP Domains)

Un dominio PTP es un conjunto de uno o más subdominios PTP (PTP subdomains). Un
subdominio PTP consiste de uno o más relojes comunicándose con otro, como se define en el
protocolo PTP, para ser sincronizados. Excepto para ciertos tipos de mensajes PTP, los nodos
en un subdominio no debieran comunicarse con los nodos de otros subdominios para propósitos
relacionados a PTP.
Subdominios múltiples pueden ser usados para crear conjuntos independientes de relojes sincro-
nizados compartiendo caminos de comunicación PTP comúnes. Los relojes dentro de un subdominio
se sincronizarán con otros, pero no hay requerimientos sobre que los relojes en un subdominio sean
sincronizados con los relojes en otro subdominio. El propósito de los subdominios es permitir a
los usuarios crear conjuntos localizados de relojes, usualmente compartiendo un único camino de
comunicación, que mantiene un tiempo base independiente del resto del dominio.
Hay cuatro subdominios definidos por el estándar:

DefaultPTPdomain: Este debiera ser el dominio por defecto si consiste de solamente un único
subdominio. Puede ser un subdominio en un dominio, consistiendo de uno o más subdominios

AlternatePTPdomain1: Este puede ser uno o más subdominio dentro de en un dominio.

AlternatePTPdomain2: Este puede ser uno o más subdominio dentro de en un dominio.

AlternatePTPdomain3: Este puede ser uno o más subdominio dentro de en un dominio.

Un dominio puede contener subdominios, subdominios en términos opcionales, otros que los
detallados arriba. Tales subdominios opcionales debieran implementar todos los requerimientos del
estándar.
3.6. DOMINIOS PTP (PTP DOMAINS) 37

Figura 3.6: Sistema tı́pico de relojes sincronizados

Ejemplos:

En la figura 3.6, si el Boundary Clock 14 y sus conecciones son removidas, hay dos dominios
PTP. Uno consiste del conjunto de nodos 9, 10, 11 y 12 mientras los otros consisten del
conjunto de nodos 1, 2, 3, 4, 5, 6, 7, 8, 13 y 15.

Si los nodos 14 y 15 son presentados como los mostrados entonces hay un dominio PTP único
consistente de todos los nodos.

Si los nodos 14 y 15 estan presentes y los nodos 1, 2 son designados como pertenecientes a
AlternatePTPdomain1 mientras los nodos restantes pertenencen a DefaultPTPdomain. En-
tonces el sistema consiste de dos subdominios.

No hay requerimientos que un subdominio sea implementado en un único medio de comunicación.

Sin embargo, si más que un único medio de comunicación existe dentro de un subdominio, los relojes
en el subdominio deben consistir de dos o más conjuntos disjuntos, cada cual con su propio camino
de comunicación PTP, comunicando uno o más Boundary Clocks.
Los Boundary Clocks debieran ser capaces de implementar todos los aspectos del protocolo PTP
para el DefaultPTPdomain. Los Boundary Clocks además deben tener la capacidad de implementar
el protocolo PTP en subdominios PTP adicionales.
Dentro de un subdominio un reloj master además de enviar un mensaje de sincronización (Sync)
puede enviar una señal de sincronización externa a alguno o todos los relojes dentro del subdominio
que tengan puertos en el estado slave. Esta señal externa debe ser transmitida sobre un medio
3.7. ESTRATOS DE UN RELOJ 38

distinto del medio de comunicación de mensajes de sincronización (Sync). Esta señal externa debe
ser emitida en segundos de transición del reloj local. El reloj slave recibiendo la señal externa
pueden usar esta información para sincronizarse con el reloj master. Se recomienda que el reloj
slave esté configurado para solamente aceptar señales de tiempo externo desde el reloj master
compartiendo el camino de comunicación PTP con el reloj slave .

3.7. Estratos de un Reloj

El número de estrato, describe una medida de la calidad de un reloj. Cada reloj debe ser
caraterizado por un número de estrato para ser usado por el algoritmo Best Master Clock (BMC)
como un parámetro de la calidad del reloj.
La interpretación y valores permitidos de números de estratos en la tabla 3.1

Nro. de Especificación
Estrato
0 Puede ser usado temporalmente para propósitos especiales por implementaciones
PTP para forzar al reloj a ser mejor considerado respecto a otros relojes del sistema
1 Designa el reloj como referencia estándar primaria de tiempo. Un reloj de estrato 1
puede ser un Boundary Clock o un Ordinary Clock (Relojes GPS ,relojes atómicos
calibrados ). Un reloj de estrato 1 no debiera ser sincronizado usando el protocolo
PTP a otro reloj en un sistema PTP
2 Designa el reloj como referencia estándar secundaria: El reloj deberı́a ser directamen-
te sincronizado al estrato 1 u otra fuente considerada para ser una fuente correcta de
tiempo para el subdominio PTP o previamente sincronizado a un reloj del estrato
1 u otra fuente de tiempo considerada como referencia correcta para el subdominio
PTP y seguir proporcionando información de tiempo consistente con este reloj o
fuente especifica el indentificador del reloj asociado
3 El valor de estrato más bajo posible si no es 1 o 2 para un reloj que tiene la capacidad
de enviar señales externas de tiempo
4 El valor de estrato más bajo posible si no es 1 y 2 para un reloj que no tiene la
capacidad de enviar señales de sincronización externa
5-254 Reservado
255 Valor por defecto. Un reloj con este estrato jamás será el Best Master Clock

Tabla 3.1: Definiciones de números de estratos

3.8. RELOJ MASTER FAVORECIDO (PREFERRED MASTER CLOCK) 39

A menos que un reloj este especı́ficamente diseñado para mantener la exactitud frente a la
pérdida de energı́a, el reloj excluirá la asignación de números de estratos inferiores a 3 durante el
encendido.
Para un Boundary Clock tendra el mismo estrato en cada uno de sus puertos.

3.8. Reloj Master Favorecido (Preferred Master Clock)

Un reloj puede ser designado administrativamente como perteneciente a un conjunto de relojes
favorecidos (Preferred master clocks). Esto crea un conjunto de relojes que serán favorecidos con
respecto a otros para ser elegidos como reloj master dentro de un subdominio. El propósito de esta
designación es permitir al los usuarios especificar un reloj que permanecerá como master aún ante
la conexión y desconexión de otros relojes.

3.9. Identificador de Reloj

El identificador del reloj indica la naturaleza y exactitud esperada y época (referencia que define
el origen de tiempo base) de un reloj dado. El identificador será usado para establecer cual de muchos
relojes con idénticos número de estratos es seleccionado como Best Master Clock (BMC).
El orden de los identificadores de reloj usados en la selección del Best Master Clock se resume
en la tabla 3.2 .
Para Boundary Clocks, el identificador del reloj deberá ser el mismo para cada puerto.

3.10. Varianza
En un sistema PTP posee dos varianzas estimadas :

Cada reloj mantiene un valor de sus propiedades de estabilidad, esta estabilidad está referida
a cuando el reloj no está sincronizado a otro reloj usando el protocolo PTP.

Si un reloj esta sincronizado a otro usando el protocolo PTP, puede mantener un valor estimado
de las propiedades del reloj al cual es sincronizado.
3.11. LATENCIA 40

Identif. Aplicable Especificación

de Reloj a Estrato
ATOM 1 El tiempo es derivado de un reloj atómico calibrado, manteniendo un tiem-
po base UTC con una exactitud mejor a 25 ns.
GPS 1 El tiempo es derivado de receptor GPS manteniedo un tiempo base UTC
con una exactitud mejor que 100 ns.
ATOM 2 La estabilidad del reloj es tal que su exactitud está dentro de 100 ns con
respecto al tiempo base UTC establecido la última vez que fue sincronizado
directamente con el reloj de estrato 1 con identificador de reloj ATOM.
GPS 2 La estabilidad del reloj es tal que su exactitud está dentro de 100 ns con
respecto al tiempo base UTC establecido la última vez que fue sincronizado
directamente con el reloj de estrato 1 con identificador de reloj GPS.
NTP 2 El reloj está activa y correctamente participando de un conjunto de relojes
usando el protocolo NTP para mantener la exactitud mejor a 15 ms,o la
establidad del reloj es tal que su consistencia está dentro de 50 ms del
tiempo base establecido la última vez que estuvo activamente y correcta-
mente participando de un conjunto de relojes usando NTP (o equivalente)
para mantener el tiempo consistente con UTC.
HAND 2 o mayor El tiempo ha sido correctamente puesto al tiempo UTC para exactitud me-
jor que 10 segundos por una procedimiento administrativo, y es consistente
con el tiempo excepto para el desplazamiento normal del reloj.
INIT 2 o mayor El reloj ha sido puesto con una exactitud no especificada para un tiempo
arbitrario o definido por el usaurio por un procedimiento administrativo
y es consistente con el tiempo excpeto para el desplazamiento normal del
reloj.
DFLT 3 o mayor Aplicable si ninguno de los ootros identificadores de reloj se aplican.

Tabla 3.2: Identificadores de reloj

3.11. Latencia
Cada puerto PTP está caracterizado por dos constantes conocidas como inbound latency y
outbound latency, usadas en la correción del retardo. En un reloj los mensajes Sync y el Delay Req
serán asignados con una marca de tiempo de envı́o y recepción.
3.12. INTERVALO DE SINCRONIZACIÓN 41

La constante outbound latency será el tiempo de propagación entre el punto en que se realiza la
marca de tiempo y el medio de comunicación para los mensajes del tipo Sync y Delay Req salientes.
La constante inbound latency será el tiempo de propagación entre el medio de comunicación y el
punto donde se realiza la marca de tiempo para los mensajes Syn y Delay Req entrantes.
En general los valores de las constantes inbound lantency y outbound latency no serán idénticos.
Para mensajes del tipo Sync y Delay Req, las marcas de tiempo son generadas en el instante que el
punto donde se efectúan las marcas de tiempo del mensaje pasa el correspondiente punto de marca
de tiempo del reloj.

3.12. Intervalo de Sincronización

Es el intervalo en segundos entre el envio de mensajes Sync sucesivos por el reloj master. De-
berá ser el mismo valor para todos todos los relojes del subdominio.
El valor del intervalo de sincronización es una relación entre la estabilidad inherente de los relojes,
la respuesta a cambiar de los relojes en un subdominio, y la carga de comunicación impuesta por
PTP.
Los valores de sincronización deberán ser tomados del conjunto {1,2,8,16 y 64 segundos}.

3.13. Tipos de Mensajes PTP

Dentro del estándar PTP se encuentran definidos dos tipos de mensajes : Los mensajes de
eventos y los mensajes generales.

3.13.1. Mensajes de Eventos

El conjunto de mensajes de eventos esta compuesto de :

Mensajes Sync : La aparición de mensajes Sync (mensajes de sincronización) en el punto

donde se efectuan las marcas de tiempo, es un evento en el cual el reloj local debe asignar una
marca de tiempo del evento de sincronización, basado en el reloj local.

Mensajes Delay Req : La aparición de Delay Req en el punto donde se efectuan las marcas de
tiempo, es un evento como el anterior, donde el reloj local debe asignar una marca de tiempo
de retardo, basado en el valor del reloj local.
3.14. PUNTOS PARA EFECTUAR MARCAS DE TIEMPO 42

3.13.2. Mensajes Generales

El conjunto de mensajes esta compuesto de :

Follow Up : mensaje que comunica el valor local de una marca de tiempo de un evento de
sincronización para un mensaje Sync en particular a otro reloj en el sistema PTP.

Delay Resp :comunica la marca de tiempo de un retardo marcando el recibido por un reloj
master de un mensaje Delay Req de un reloj slave.

Managament messages : Los managament messages (Mensajes administrativos) comunican

información usada para administrar un reloj individual y un sistema de relojes.

3.14. Puntos para Efectuar Marcas de Tiempo

El entorno PTP ofrece diferentes puntos donde pueden ser efectuadas las marcas de tiempo
(ver figura 3.7). En el enfoque de asistencia por hardware, las marcas de tiempo son ocupadas en
la interfaz independiente del medio (Medium Independent interface, MII) entre la capa de nivel
de enlace de datos y la capa fı́sica. Para capturar los frames directamente del cable 100Base-
TX, funciones tales como recuperación de reloj, decodificación de lı́nea, decodificiación, entre otras
funciones que son propias del capa fı́sica que son requeridas.
El software PTP en la capa de aplicación requiere una interfaz que lo comunique con la unidad
encargada de realizar las marcas de tiempo.
Soluciones basadas únicamente en software toman las marcas de tiempo en la driver de la interfaz
de tarjeta de red o en la capa de aplicación.
Las marcas de tiempo a nivel de la capa de aplicación tienen la ventaja de ser independientes
de la plataforma. Una desventaja es el Jitter, que no es más que el retardo del mensaje al transitar
por las diferentes capas de la pila del protocolo. El Jitter depende del tipo de sistema operativo, las
aplicaciones ejecutándose, el hardware del sistema, el sistema de interrupciones y otros factores.
Las marcas de tiempo a nivel del driver son una solución óptima pero requiere un driver de red
modificado.

3.15. Supuestos sobre el Protocolo PTP

El estándar PTP hace muchos supuestos sobre el ambiente en el cual debe operar el protocolo.
Los siguientes supuestos debes ser logrados para asegurar la correcta operación del protocolo:
3.15. SUPUESTOS SOBRE EL PROTOCOLO PTP 43

Figura 3.7: Puntos posibles para realizar marcas de tiempo

La red debe soportar comunicación multicast.

Debe ser posible prevenir que los mensajes multicast se propaguen más allá de la subred.

Las propiedades de estado de un reloj, incluyendo su estrato e identificador, deben describir

exactamente al reloj.

Para alcanzar un óptimo funcionamiento de la sincronización del reloj deben lograrse los siguien-
tes supuestos :

El retardo de lı́nea (delay) entre entre el reloj master y slave debe ser simétrico.

Un reloj puede contener retardo asimétrico en su mecanismo de marcas de tiempo o camino

del protocolo. Si estas simetrı́as no son insignificantes, deben ser corregidas.

El retardo de red entre master y slave en una subred debe ser constante sobre el intervalo de
tiempo de envı́os de mensajes Delay Req.

Los Boundary Clocks deben ser usados para sincronizar entre subredes.
3.16. ALGORITMO BEST MASTER CLOCK (BMC) 44

Las fluctuaciones de retardo debido a los componentes de la red y debido a la pila del protocolo
deben ser reducidas por dos técnicas:

1. Las marcas de tiempo usadas en PTP deben ser generadas tan cerca a la capa fı́sica como
sea posible para una implementación de reloj dada. En casos donde las marcas de tiempo
más exactas pueden ser generadas solamente después que un mensaje ha sido enviado en
efecto, el valor actual es comunicado en el mensaje Follow Up del reloj master.
2. La fluctuación de retardo constantes introducidas por la pila del protocolo y los compo-
nentes de la red no aislados por un Boundary Clock puede ser reducida promediando el
retardo de lı́nea en ambos sentidos.

La potencia de cómputo de los relojes de la aplicación del protocolo deben ser lo suficiente-
mente grandes, y el número de relojes por subred debe ser lo suficientemente pequeño

La estabilidad inherente del oscilador del reloj debe ser adecuada.

3.16. Algoritmo Best Master Clock (BMC)

El algoritmo del Best Master Clock funciona independientemente en todos los puertos de cada
reloj del subdominio. El propósito del algoritmo es determinar el estado de cada puerto del sistema.
Los relojes no se encargan de negociar cual será el master o el slave, en lugar de esto calcúlan su
propio estado. El algoritmo usa autoconfiguración basada en las caracterı́sticas de los relojes y la
topologı́a de la red.
La determinación del estado de cada puerto se basa en en la información de los mensajes Sync
recibidos en los puertos de un reloj y en el valor del conjunto de datos por defecto del reloj dado,
tales como:

Preferred : designa un conjunto de relojes desde el cual el Grandmaster es seleccionado.

Stratum : indica la jerarquı́a dentro del protocolo PTP.

Identifier : exactitud del tiempo base del reloj.

Variance : Estabilidad y ruido del reloj.

Closest : Algoritmo del árbol Cobertor mı́nimo (minimun spanning tree)

UUID : identificador del puerto

3.16. ALGORITMO BEST MASTER CLOCK (BMC) 45

3.16.1. Visión General del algoritmo

1. El reloj master A puede recibir mensajes de sincronización (mensajes Sync) desde otros po-
tenciales relojes masters : B , C , ...

2. . El reloj A decide :

a. Cual de los relojes es el “mejor” reloj

b. Si reloj A es mejor que el mejor de B ,C , ...

3. . Usando el algoritmo Best Master Clock (BMC) , lo que hace este un par correcto de com-
paraciones de conjuntos de datos describiendo cada uno de los relojes.

4. Basados en los resultados de esta comparación el algoritmo BMC devuelve un estado de reloj
recomendable : en situación simple cualquiera master o slave.

5. Todos los relojes operan la misma información y por lo tanto llegan a resultados consistentes.

6. Los datos para estas comparaciones lógicamente estan contenidas por cada reloj en uno de
mujos conjunto de datos.

El algoritmo BMC consiste en dos sub algoritmos:

1. Algoritmo de estados de decisión : usando los resultados de comparaciones de todas las parejas
de conjuntos de datos lo que produce un estado recomendado

2. Algoritmo de comparasión de conjunto de datos : una relación usando información especı́fica

del conjunto de datos de los puertos de dos relojes siendo comparados :

a. Selecciona un reloj que derive su tiempo de otro mejor Grandmaster

b. Si los Grandmaster son equivalentes elige el Grandmaster “más cercano”
c. Si lo arriba falla para indicar una decisión se usa tie- breaking (UUID).

3.16.2. Conjunto de datos (Data Sets)

Los siguientes son los conjuntos de datos (Data Set) por reloj :

Default data set : Propiedades de un reloj local que determina su comportamiento y funcio-
namiento cuando es un reloj Grandmaster.
3.17. USANDO EL PROTOCOLO PTP 46

Global time properties data sets : propiedades del tiempo base.

Current data set : sincronización actual y propiedades de topologı́a operacional.

Y el conjunto de datos por puerto de cada reloj:

Parent data set : Propiedades del padre y Grandmaster

Port configuration data set : Propiedades del puerto del reloj

Foreign master data set : Identificacion de los mensajes Sync de potenciales relojes master.
Parte de un esquema de clasificación para reducir datos no deseados.

3.17. Usando el protocolo PTP

PTP entrega una metodologı́a simple para sincronizar exactamente relojes en un sistema distri-
buido. Cuando se diseña tal sistema las siguientes consideraciones deben ser hechas :
Capa fı́sica

Dispersión de los relojes.

Tecnologı́a de red utilizada.

Lógica

El sistema es una simple colección de relojes, que están divididos en agrupamientos lógicos
los cuales tienes su propio sentido de tiempo.

Componentes

Cual es la exactitud con la que se necesita sincronizar los relojes.

Cual es la fuente primaria de tiempo del sistema.

Implementación Local

Como son los requerimientos de sincronización

Como afecta a PTP otras aplicaciones que comparten la red de comunicaciones.

Como afecta a la implementación los requisitos de exactitud.

Cuales son las caracterı́sticas de diseño del oscilador local.

3.17. USANDO EL PROTOCOLO PTP 47

3.17.1. Capa Fı́sica

Los relojes PTP se comunican sobre una red. Habitualmente, la selección de la tecnologı́a de
red se hará basándose en la aplicación primaria. PTP trabajará en cualquier sistema basado en
paquetes. PTP esta diseñado para trabajar en un ambiente multicast aunque es posible diseñar
componentes y sistemas PTP unicast. Ethernet es un sistema ideal para implementar PTP.
Todas las redes tienen limitaciones en distancia, número de nodos permitidos, y tráfico. Si los
relojes que se van a sincronizar estan dispersos más allá de cierto rango de la tecnologı́a de red,
entonces el sistema debe ser diseñado por separado como “islas de red ” con conexión externa de
PTP para sincronizar las islas.
Por ejemplo , si un sistema consiste en dos sitios compactos separados por mucha distancia,
PTP puede ser usado dentro de cada sitio como sincronización entre los sitios provista por otra
tecnologı́a distinta, como por ejemplo GPS.
Dentro de un sitio distante, el tráfico, y el número de nodos distribuidos son direccionados por
componentes de red especiales. Para Ethernet los nodos localizados se comunican usualmente vı́a
sencillos repetidores. Para aplicaciones más complejas, cada grupo de nodos usa un repetidor o
aún nodos individuales pueden estar conectados switches o hubs. Para sistemas más grandes y más
complicados, enrutadores son usados para separar el sistema en subgrupos, que a su vez utilizan
switches o repetidores. En general, cada nivel de separación usando estos dispositivos introduce un
retardo estadı́stico adicional y una fluctuación de retardo en la transmisión de mensajes de tiempo
entre nodos.
PTP esta diseñado para minimizar los efectos del retardo y las fluctuaciones de retardo. Para
lograr el mejor funcionamiento de PTP, la topologı́a de la red debiera tener como una restricción
la minimización de tales dispositivos separadores entre relojes con requerimientos más crı́ticos de
sincronización.
Para Ethernet ,algunas cosas útiles:

El menor retardo y fluctuación de retardo será observada entre relojes comunicados con re-
petidores. Los repetidores Ethernet no usan ningún almacenamiento o técnica de reenvı́o ni
hace que implique ningún análisis del contenido de los mensajes. El retardo del repetidor y
la fluctuación del retardo puede ser corregida bastante bien por algoritmos de sincronización
local.

Los Switches introducen un considerable retardo e incrementan la fluctuación de retardo

comparado con los repetidores. Sin embargo dependiendo de la exactitud deseada, un sistema
3.17. USANDO EL PROTOCOLO PTP 48

PTP conteniendo switches producirá resultados satisfactorios. El incremento del retardo y la

fluctuación de retardo resulta del análisis que el switch hace a una porción del encabezado
del mensaje y posiblemente a mensajes encolándose desde cada conexión de red al switch que
está en un dominio de colisión ethernet separado

Los enrutadores usualmente en el nivel más alto de componentes en una red Ethernet. Los
enrutadores hacen un análisis sobre un mensaje e involucra almacenamiento extensivo y re-
envı́o resultando en un considerable retardo y fluctuación del retardo. Sin técnicas especiales,
los relojes sincronizados vı́a enrutadores serán limitados en la exactitud de la sincronización,
generalmente en el orden de los milisegundos.

Los Boundary Clocks pueden ser usados para mejorar el funcionamiento a través de separaciones
en la red definidas por los enrutadores.

3.17.2. Capa Lógica

La mayorı́a de las aplicaciones consiste en un simple conjunto de relojes para ser sincronizados.
Para este caso, todos los relojes pueden ser usados en un simple subdominio. Si el DefaultPTPdomain
es usado, entonces la configuración de relojes no es necesaria.
Si la aplicación requiere muchos grupos de relojes, los cuales mantenienen un tiempo base con-
sistente diferente, entonces una de dos soluciones pueden ser usadas :

Si el resto de la aplicación esta segmentada en los mismos grupos, puede ser posible usar redes
separadas no comunicadas. En cuyo caso cada grupo puede utilizar el DefaultPTPdomain.
Los enrutadores son usados a menudo para este propósito.

Si los grupos deben compartir una red común, entonces cada grupo puede ser asignado a
un diferente nombre de subdominio. Esto lógicamente dividirá el reloj PTP como se desea.
En función del mapeo al direccionamiento fı́sico subyacente de la red, el procesamiento de
carga sobre cada reloj puede o no ser afectado. En el caso de ethernet, PTP tiene reservado
cuatro direcciones multicast para dominios PTP, dependiendo del hardware de cada nodo,
estas direcciones pueden ser selecionadas por el hardware de red reduciendo de este modo la
sobrecarga no buscada del procesador del nodo.

Con la excepción de la asignación de nodos PTP a un subdominio, PTP define un sistema de

administración libre. Dentro de un subdominio, los nodos PTP pueden ser agregados o eliminados
sin ningún requerimiento para modificar tabla de direcciones, etc. Los componentes usan el modelo
3.17. USANDO EL PROTOCOLO PTP 49

de comunicación multicast recomendado. Agregar o quitar nodos PTP puede causar que un reloj
PTP diferente llegue a ser el reloj Grandmaster en el sistema. Esto podrı́a causar una transiente
en el tiempo base debido a que el sistema automáticamente se recalibra para el nuevo patrón de
retardo al nuevo reloj Grandmaster.

3.17.3. Componentes

La primera cuestión en la selección de componentes de sistemas PTP es la exactitud de sincro-

nización requerida :

Los relojes PTP deben elegirse teniendo en cuenta que están destinados a apoyar las carac-
terı́sticas requeridas del protocolo para una exactitud dada. Los relojes PTP con una exactitud
inherente alta debieran soportar el uso de mensajes Follow Up.

Los componentes de red y decisiones de diseño fı́sico también afectan la exactitud como se
explicó en secciones previas.

Sistemas PTP correctamente diseñados pueden alcanzar fácilmente exactitudes por debajo del
rango de los microsegundos.
Una segunda cuestión es la técnica para establecer la época del sistema PTP. En cada subdominio
PTP, la época o tiempo de referencia que define un origen de una escala de tiempo es decidido por
el reloj Grandmaster que es elegido de acuerdo al algoritmo Best Master Clock.
Si el tiempo UTC es un requerimiento, entonces el reloj Grandmaster debe mantener tiempo
base UTC.
Si un subdominio PTP contiene un reloj de estrato 1 el tiempo base será UTC. Tales sistemas
pueden o no mantener la época después de un corte de energı́a.
Si un subdominio PTP contiene un reloj de estrato 2 o superior, el tiempo base será UTC o un
tiempo base definido por el usuario. Tales sistemas pueden o no mantener la época después de un
corte de energı́a.
Además para introducir relojes de estrato 1 o 2 en el sistema, el control sobre la selección del
reloj Grandmaster puede ser logrado designando uno o más relojes PTP como pertenecientes a un
conjunto de relojes preferred master, es decir que serán favorecidos por el algoritmo Best Master
Clock para ser elegido como master. Si el reloj ası́ designado está seleccionado para ser reloj que
mantendrá su tiempo en caso que la energı́a se vaya se obtendrá un sistema más robusto.
3.17. USANDO EL PROTOCOLO PTP 50

3.17.4. Implementación Local

Alguna directrices para no degradar la exactitud del sistema PTP al implementar Ordinary
Clocks y Boundary Clocks :

Sincronización

La implementación debe asegurar que se cuenta con recursos adecuados de cómputo y recursos
de memoria disponibles. También debe asegurarse que los recursos necesitados por las implementa-
ciones PTP tienen la adecuada prioridad sobre otras aplicaciones compartiendo estos recursos. Es
recomendado que las tareas PTP sean asignadas con una prioridad alta en una implementación,
similar a prioridades asignadas a la pila del protocolo y otros recursos del sistema operativo.
Las implementaciones PTP normalmente requieren recursos por un corto perı́odo de tiempo en
cada intervalo de sincronización. La selección de este intervalo debe ser consistente con los recursos
de los cuales dispone el sistema.

Exactitud

La exactitud conseguible de un sistema PTP está limitada por lo siguiente:

a) La fluctuación de retardo en la pila del protocolo de relojes PTP.

b) La fluctuación de retardo en los componentes de red.

c) Exactitud en las marcas de tiempo

d) Estabilidad

a) Fluctuación del retardo en la pila del protocolo Las implementaciones más simples de
PTP operan como una aplicación ordinaria al comienzo de la pila del protocolo de red. Las marcas
de tiempo son generadas en la capa de aplicación. La fluctuación de retardo de la pila del protocolo
provocará errores en estas marcas de tiempo. Estos errores están tı́picamente dentro del rango de
cientos de microsegundos a milisegundos dependiendo del sistema operativo.
Las implementaciones puede generar marcas de tiempo al nivel de interrupciones mejor que al
nivel de aplicación. En este caso la fluctuación de retardo tı́picamente será reducida a decenas de
microsegundos dependiendo del uso de las interrupciones por otras aplicaciones.
La mayor reducción de errores debido a fluctuaciones de retardo en la pila del protocolo son
conseguibles con técnicas de asistencia de hardware que generan marcas de tiempo en la capa fı́sica
3.17. USANDO EL PROTOCOLO PTP 51

de la pila del protocolo. En este punto la fluctuación de retardo es tı́picamente en el rango de los
nanosegundos.

Figura 3.8: Retardo de red y de la pila del protocolo

b) Fluctuación de retardo de los dispositivos de red Los componentes de red introducen

una variación en la propagación de los mensajes de tiempo. Esto directamente afecta la exactitud
de los valores de offset y delay.
Los enrutadores tı́picamente almacenan y analizan parcialmente cada mensaje y lo retransmiten
cuando otras subredes lo permiten. Esta variación del retardo es habitualmente de alrededor de
muchos milisegundos. Protocolos como NTP están diseñados para administrar grandes sistemas
conteniendo enrutadores y componentes de transmisión de un área amplia. PTP está propuesto para
sistemas más locales y por lo tanto usa comunicaciones multicast, las cuales no son transmitidas
por enrutadores. Los Boundary Clocks puestos en lugar de los enrutadores permiten a PTP cruzar
a través de las limitaciones del enrutador y reemplazar la fluctuación de retardo del enrutador con
la variación de retardo mucho menor de un reloj PTP normal.
Los switches de red encontrados comúnmente en grandes subredes Ethernet están sujetos a
almacenar y reenviar variación de retardo. El tı́pico switch Ethernet tiene buffers de entrada y salida
comunicados sobre una columna vertebral de alta velocidad. Cada puerto se conecta directamente
a un dispositivo final o a un repetidor soportando muchos dispositivos finales. La contribución
más significativa a la variación de retardo surge desde la salida del buffer. Si la subred de salida
3.17. USANDO EL PROTOCOLO PTP 52

esta siempre disponible esta fluctuación de retardo será tı́picamente en el rango de nanosegundos
y reducible por técnicas de promedio. El tráfico intensivo dirigido a un nodo conteniendo un reloj
PTP puede causar aumento de la variación de retardo debido a la salida con buffer. Esta variación
de retardo es mucho más difı́cil de reducir. El correcto diseño de sistemas de medición y control
debe reconocer este efecto y tomar medidas para reducir el impacto. Por ejemplo, mensajes cortos
producen menos fluctuación generalmente que los mensajes largos. También la tranferencia de datos
másivos a un nodo en particular puede romperse o bien ejecutar la aplicación cuando la exactitud
de la sincronización del reloj es aceptable.

c) Exactitud de las marcas de tiempo La resolución del reloj generando las marcas de tiempo
requeridas por PTP deben ser consistentes con la exactitud deseada. La resolución está incluı́da en
la caraterización de varianza e identificador del reloj.

d) Estabilidad La fluctuación de retardo introducida en el cálculo de las variables offset y delay

puede ser reducidas por el diseño conveniente de servo algoritmos del reloj local. Se debe privilegiar
entre el promedio del tiempo (número de muestras) y la sensibilidad a los otros efectos como la
variación de retardo de lı́nea, y la estabilidad del oscilador. También se debe privilegiar entre la
tasa de muestreo (intervalo de sincronización), la sensibilidad a cambios en la topologı́a (seleccion
de reloj máster), la cantidad de cómputo requerida y el ancho de banda.
La estabilidad fundamental del tiempo del reloj debe ser consistente con el intervalo de sincroni-
zación requerido (syn interval) y especificaciones de exactitud. Los algoritmos usados para reducir
la fluctuación de retardo no corregirán el desplazamiento del reloj local durante intervalos de tiempo
pequeños comparados con el promedio de intervalos de los algoritmos. Los servos no pueden corregir
desplazamientos aleatorios del reloj dentro del intervalo de sincronización.
El alto nivel de exactitud la especificación en la estabilidad de los osciladores del manejo del
reloj local puede ser bastante difı́cil de cumplir. Se deberá sacrificar será entre costo y estabilidad.
Los osciladores locales comúnmente son cristales de cuarzo. Los cristales de cuarzo habitualmente
varı́an según efectos térmicos, mecánicos y de envejecimiento. De los cuales el efecto térmico es el
más complicado en la mayorı́a de las aplicaciones.
3.18. IMPLEMENTACIÓN ETHERNET DE IEEE 1588 53

3.18. Implementación Ethernet de IEEE 1588

3.18.1. Direccionamiento Ethernet para PTP

En el Protocolo se especifican dos puertos y un conjunto de direcciones Multicast para establecer

comunicación dentro del protocolo PTP. En una implementación Ethernet, los puertos PTP y las
direcciones multicast PTP son mapeadas sobre puertos UDP y direcciones multicast IP.
En una implementacion Ethernet, todos los mensajes PTP corresponderan a mensajes UDP.
Dos números de puertos son usados en el protocolo PTP. Estos nombres de puertos están defi-
nidos en la tabla 3.4.

Categorı́a Propósito Valor

Eventos Comunica los mensajes PTP Sync o De- 319
lay Req
General Comunica los mensajes PTP Follow up, 320
Delay Resp o mensajes administrativos

Tabla 3.3: Puertos usados en implementación Ethernet de PTP.

Cuatro direcciones Multicast son especificadas en el protocolo PTP. Estas cuatros direcciones
para la implementación PTP están definidas en al tabla 3.4. El valor “time to leave” o “lı́mite de
saltos” para todos los mensajes PTP será 0. Esto significa que los mensajes no serán tranferidos
por enrutadores.

Nombre dirección Propósito Valor

DefaultPTPdomain Define el subdominio de sincronización [Link]
por defecto para un sistema PTP
AlternatePTPdomain1 Define un subdominio de sincronización [Link]
alternativo
AlternatePTPdomain2 Define un subdominio de sincronización [Link]
alternativo
AlternatePTPdomain3 Define un subdominio de sincronización [Link]
alternativo

Tabla 3.4: Puertos usados en implementación Ethernet de PTP.

3.18. IMPLEMENTACIÓN ETHERNET DE IEEE 1588 54

3.18.2. Lógica de Direccionamiento

Cinco caminos de comunicación lógica ocurren en sistema PTP :

Reloj master a reloj slave.

Reloj master a reloj master.

Reloj Slave a Reloj Slave.

Herramienta de administración a cualquier reloj master o slave.

Reloj master o slave a la Herramienta de administración.

Cuatro tipos de mensajes son llevados sobre estos enlaces lógicos :

Mensajes Sync o Delay Req que son eventos marcados con tiempo por los relojes.

Mensajes Follow Up que reportan el tiempo de transmisión de un mensaje Sync.

Mensajes Delay Resp usados en la medición de delay, y

Mensajes administrativos usados para monitorear y configurar los relojes PTP del sistema.

Las combinaciones útiles de caminos de comunicación y tipos de mensajes son indicados en

la tabla 3.5. Combinaciones no usadas son indicadas por “N/E”. Para combinaciones útiles, el
despliegue de proporciones, que es la cardinalidad, de la comunicación está dada. La frecuencia de
ocurrencia para cada tipo de mensaje durante una operación normal de estado estacionario con el
valor por defecto del intervalo de sincronización está también dado.
Durante transientes, tales como el comienzo o cambio del reloj master, el tráfico se incrementará.
3.18. IMPLEMENTACIÓN ETHERNET DE IEEE 1588 55

Camino o Sync o Follow Up Delay Resp Administrativo

Tipo Mensaje Delay Req (1/sec) (1/min/slave) (ocasionalmente)
(1/sec
+1/min/slave)
Master a slave 1:N 1:N 1:1 N/E
Master a master N:1 N/E N/E N/E
Slave a master 1:1 N/E N/E N/E
Administrador a N/E N/E N/E 1:1 o 1:N
master o slave
Master o slave a N/E N/E N/E 1:1
administrador

Tabla 3.5: Cardinalidad de paso de mensajes.

La semántica de los mensajes Follow Up, Delay Resp y de administración está contenido ente-
ramente en los datos del mensaje. La semántica de los mensajes Sync o Delay Req están contenidos
en los datos del mensaje y en el tiempo de transmisión y recepción del mensaje. PTP está basado en
la medición precisa de estos tiempos para los mensajes Sync o Delay Req y es sin embargo necesario
distinguir fácilmente mensajes Syn o Delay Req de todo el tráfico de la red. Es también deseable
distinguir entre mensajes Follow Up, generales y administrativos a tan bajo nivel como sea práctico
para eliminar el uso de ciclos innecesarios dedicados a PTP.
En los protocolos Ethernet basados en IP hay dos mecanismos de bajo nivel para decodificar
mensajes, la dirección IP de destino y el número de puerto. En las pilas tı́picas de protocolo IP, la
dirección de destino están resueltas por hardware y los puertos son resueltos en los niveles más bajos
del software IP sin involucrar niveles de la aplicación de sofware (exceptuando para configuración).
En principio, cada dirección de destino o número de puerto puede ser usado individualmente o en
combinación para satisfacer los requerimientos antes mencionados.
De la tabla 3.5, el único caso significativo de comunicación uno a uno es slave a master para
mensajes Delay Req y master a slaver para mensajes Delay Resp. La comunicación uno a uno puede
ser implementada mediante direcciones unicast , lo cual es más eficiente en términos de carga del
procesador. Sin embargo las direcciones multicast han sido especificadas debido a que requieren
menos administración.
La comunicación uno a uno entre slave y master podrı́a ser implementada con una dirección
unicast del master. Esto requerirı́a todos los relojes escuchar sobre las direcciones multicast mensajes
3.18. IMPLEMENTACIÓN ETHERNET DE IEEE 1588 56

desde un master a su propia dirección unicast si es un master. Adicionalmente , el slave necesitarı́a

ser capaz de cambiar la dirección de destino de los mensajes Delay Req que emita si el master
cambia. La ventaja es que solamente el master necesita analizar mensajes de un slave en particular.
La desventaja es que el slave debe ser capaz de reconfigurar un puerto unicast y un master debe
escuchar dos direcciones. Ningúno requiere alguna acción por las facilidades de administración del
protocolo. En estado estacionario, estos mensajes enviados por el slave son infrecuentes. El número
de tales mensajes escala linearmente con el número de slaves. En dominios de sincronización de
menos de 50 relojes aproximadamente, el tráfico PTP es todavı́a del orden de dos mensajes por
segundo para el valor por defecto para el intervalo de envı́o de mensajes Sync.
El caso de comunicación master a slave uno a uno de Delay Resp parece ser ligeramente diferente.
El tráfico aumentando con el número de slaves es idéntico con la comunicación uno a uno de slave
y master. El uso de comunicación uno a uno en este caso requerirı́a al master mantener y usar la
dirección unicast de todos los slaves, lo que no parece merecer la pena.
En principio todas las comunicaciones 1:N debieran ser manejadas por una secuencia de mensajes
unicast. Sin embargo, el costo de mantener tablas de direcciones y el tráfico de red aumentando de
los actuales dos mensajes por segundo linealmente con el número de relojes no vale la pena.
Un esquema baso en unicast tambien requerirı́a administración o grandes complicaciones al
protocolo.
Capı́tulo 4

Implementación de una Red de

Sincronización

4.1. Introducción
En este capı́tulo se presentan diferentes configuraciones de una red de sincronización. Se com-
paran las distintas prestaciones de un Switch y un Boundary Clock , bajo distintos escenarios de
carga. Y se comparan la exactitud de distintos tipos de relojes, todos sincronizados a un Grand-
master GPS. También se presentan pruebas realizadas utilizando una implementación del protocolo
de software llamada PTPd.

4.2. Implementación de la Red

4.2.1. Hardware de Red Utilizado

a) Servidor de Tiempo de Red con GPS

Caracterı́sticas : El servidor de tiempo de red LAN entrega un tiempo base para una red TCP/IP
(Servidor de estrato 1).
Un reloj satelital radio controlado es usado como referencia de tiempo base. El reloj ha sido
diseñado para entregar tiempo extremadamente preciso y para satisfacer los requerimientos de
precisión que los relojes radio controlados no cumplen. La alta precisión disponibles las 24 horas
del dı́a a través de todo el mundo es la principal caracterı́stica del sistema que recibe información
desde los satélites de posicionamiento global (GPS, por su sigla en inglés).

57
4.2. IMPLEMENTACIÓN DE LA RED 58

El sistema de posicionamiento global está basado en la exactitud de medición de la propagación

de señales transmitidas al receptor del usuario. Una constelación nominal de 21 satélites, con 3 de
reserva activos, en 6 órbitas a 20.000Km de la tierra entregan un mı́nimo de 4 satélites para ser
vistos en cualquier momento y en cualquier punto de la tierra. Se necesitan recibir la señal 4 satélites
en forma simultánea para calcular tanto como la posición como el offset de reloj del sistema GPS.
Todos los satélites son monitoreados por estaciones de control las cuales determinan los parámetros
de órbita exactos como también el offset de los relojes atómicos de los satélites. Estos parámetros son
subidos a los satélites y llegan a ser parte de los mensajes de navegación lo cuales son retransmitidos
a otros satélites para pasar la información al usuario .
Después de encendido, el módulo acepta la información del tiempo absoluto (segundos PTP) de
una referencia de tiempo (Reloj GPS controlado) una vez solamente y los nanosegundos son puestos
en cero. Si la frequencia del oscilador de la referencia de tiempo, ha alcanzado el valor nominal, la
reinicialización de los nanosegundos es repetida.

Figura 4.1: Servidor de tiempo GPS

La finalidad principal dada a este reloj por sus caraterı́sticas de precisión será de funcionar
como Grandmaster dentro de la red que se implementará, es decir, será el master para los Ordinary
Clocks.

Configuración : En la figura 4.2 se puede apreciar la interfaz web de configuración del reloj
Grandmaster. Los parámetros de configuración usados fueron :

Estrato : 1

Intervalo de Sincronizacion : 2

Modo PTP : Master

SubDominio : 0

Bandera Preferred Master : Falso

4.2. IMPLEMENTACIÓN DE LA RED 59

Figura 4.2: Configuración Grandmaster

b) Tarjeta Ethernet IEEE 1588

Caracterı́sticas : Esta tarjeta ha sido desarrollada por Zurich University of Applied Sciences y
tiene básicamente dos funcionalidades :

Interfaz de Red : La tarjeta actúa como una interfaz de red 10/100 MBit completamente
funcional.

Hardware IEEE 1588 : El FPGA [9] en la tarjeta entrega una unidad para realizar las marcas
de tiempo y un reloj ajustable de acuerdo al estándar IEEE 1588.

La función principal de red está a cargo de un controlador PCI MAC Ethernet de 32 Bit.
Está conectado a un chip fı́sico (PHY) externo de 10/100 Mbit. Esto permite a la lógica imple-
mentada sobre el FPGA escuchar el tráfico entrante y saliente de la interfaz MII (Media Indepent
Interface). Las marcas de tiempo son llevadas por datagramas Ethernet los cuales necesitan ser
marcados de acuerdo al estándar.
4.2. IMPLEMENTACIÓN DE LA RED 60

El FPGA también posee un reloj ajustable con correción de offset y desplazamiento (velocidad
del reloj). Este reloj es el objetivo sincronización del protocolo IEEE 1588 y entrega el tiempo a la
unidad de marcas de tiempo.
La interfaz MDIO se usa para comunicarse con el FPGA también. Entonces el FPGA se puede
comunicar a través de la interfaz PCI. La configuración del FPGA es hecha sobre el bus PCI. Esto
es posible gracias al dispositivo CPLD.

Figura 4.3: Tarjeta Ethernet IEEE 1588

Figura 4.4: Arquitectura tarjeta Ethernet IEEE 1588

Configuración : El funcionamiento de la Tarjeta PCI IEEE 1588 se hace a través de un live CD

basado en Kubuntu , el cual instala los controladores para la tarjeta. Una vez iniciado el sistema
operativo se puede iniciar la aplicación PTP que iniciará el proceso de sincronización de la tarjeta
4.2. IMPLEMENTACIÓN DE LA RED 61

de red.

c) Tarjeta de Desarrollo Imsys

Caracterı́sticas : Esta tarjeta de desarrollo ha sido creada por la empresa Sueca Imsys Technolo-
gies, entre sus caracterı́sticas más importantes posee un microcontrolador con la implementación del
protocolo IEEE 1588. En la implementación de la red de sincronización se utilizará como Ordinary
Clock, es decir será esclava del Grandmaster.

Figura 4.5: Tarjeta de desarrollo Imsys

La tarjeta cuenta con un motor de tiempo de precisión (PTE, Precision Time Engine), que
consiste en temporizadores configurables y hardware MAC con capacidades de realizar marcas de
tiempo.
El hardware MAC procesa las marcas de tiempo para todo el tráfico Ethernet entrante y sa-
liente. Las marcas de tiempo procesadas poseen tiempo expresado en unidades que están derivadas
directamente desde la fuente de tiempo del hardware MAC, y comienzan de cero cuando se enciende
el sistema.
El Driver MAC inspecciona el payload de todos los datagramas Ethernet entrantes y salientes
para detectar datagramas PTP. Cuando lo hace, convierte las marcas de tiempo de estos datagramas
en tiempo real y lo almacena en una lista de marcas de tiempo.
El motor del protocolo PTP recibe y envı́a mensajes PTP a través de la pila TCP/IP usando
una interfaz de socket. Accede a la lista de marcas de tiempo de estos mensajes. Y también envı́a
peticiones de ajuste de reloj al Driver MAC.
4.2. IMPLEMENTACIÓN DE LA RED 62

Figura 4.6: Arquitectura tarjeta Imsys

Configuración : En funcionamiento de la tarjeta Imsys se hace conectándola a un ordenador

mediante un puerto serial. En el ordenador a través de un interfaz de desarrollo (4.7) propia de la
tarjeta Imsys permite inicializar mediante una interfaz de comandos el motor del protocolo.

Figura 4.7: Captura pantalla Developer Imsys

4.2. IMPLEMENTACIÓN DE LA RED 63

d) Syncbox

Caracterı́sticas : El Syncbox actúa como un slave PTP con un oscilador de alta precision para
producir diferentes tiempos y frecuencias de salida. Syncbox es un equipo compuesto de una tarjeta
con una tarjeta de red integrada, una unidad de marcas de tiempo (TSU) y una fuente de poder.
Su función principal dentro de la red ha sido actuar como Ordinary Clock

Figura 4.8: Syncbox

Configuración : La configuración utilizada, a la que se ingresa mediante una interfaz web (Figura
4.9), ha sido la siguiente :

Estrato : 255

Modo PTP : Esclavo

Phy Delay : -1500 ns

Subdominio : 0

El valor de estrato afecta al algoritmo BMC (Best Master Clock), es decir cual master en la red
llegará a ser Grandmaster. SyncBox no tiene un reloj de referencia integrado y será usado por esa
razón con el valor estrato de 255.
El valor Phy Delay compensará el retardo actual del chip fı́sico (PHY) en la Syncbox y depende
del hardware.
4.2. IMPLEMENTACIÓN DE LA RED 64

Figura 4.9: Configuración Syncbox

e) Switch Boundary Clock

Caracterı́sticas : El protocolo IEEE 1588 elimina la inexactitud causada por delay y jitter defi-
niendo un Boundary Clock. Los Boundary Clocks son relojes integrados en los dispositivos. Estos
relojes están sincronizados por un lado a una fuente de referencia de tiempo y por otra sincronizan
a relojes del tipo Ordinary Clocks.

Configuración : Se realiza a través de una interfaz web como demuestra en la figura 4.10. Los
parámetros que se han configurado son los siguientes :

Modo reloj :ptp-mode-boundary-clock

Intervalo de Sincronizacion : 2 segundos

Sync Lower Bound : 30 ns

Sync Upper Bound : 5000 ns

Nombre Subdominio : DFLT

Master favorecido : Falso

4.2. IMPLEMENTACIÓN DE LA RED 65

Donde Sync Lower Bound, y Sync Lower Bound determinan un rango de valores para el cual la
hora local u hora de referencia será considerada sı́ncronona o no.

Figura 4.10: Configuración Switch Boundary Clock

f ) Switch Ethernet

Para realizar las pruebas se ha usado un Switch Ethernet 10/100 Mbps Connection N&C modelo
LS8. Su función dentro de la red será la de interconectar los distintos nodos PTP.
4.2. IMPLEMENTACIÓN DE LA RED 66

Figura 4.11: Switch Ethernet

g) Generador de Tráfico Ethernet N2X Agilent Technologies

Caracterı́sticas : Esta herramienta de hardware permite generar tráfico de distintas caracterı́sti-

cas deseadas. Para el caso de las pruebas realizadas en este Proyecto de Fin de Carrera ha sido
utilizado para simular carga continua y carga a ráfagas, ya sea en los Switch Ethernet como en
los Boundary Clocks. Para ambos casos se generarán tramas Ethernet con payload UDP del tipo
MPEG-2 [8].

Figura 4.12: Generador de tráfico Ethernet

4.2. IMPLEMENTACIÓN DE LA RED 67

Figura 4.13: Captura pantalla interfaz Generador de tráfico Ethernet

Funcionamiento : En primer lugar se configuran dos interfaces de red que se encargarán de

generar el tráfico, una enviará datos (Tx) y otra los recepcionará (Rx). Posteriormente se debe
configurar el tipo de tráfico que será enviado (Ver figura 4.14), en el caso de los experimentos
realizados se han generado tramas Ethernet con payload UDP del tipo MPG2. Y finalmente se
configuran las caracterı́sticas que tendra el tráfico, es decir, si corresponderá a tráfico continuo o
ráfagas, y la cantidad de ancho de banda que ocupará (Ver figura 4.15).
4.2. IMPLEMENTACIÓN DE LA RED 68

Figura 4.14: Configuración de paquetes en el generador de tráfico Ethernet

Figura 4.15: Configuracion de tráfico en el generador de tráfico Ethernet

4.2.2. Software Utilizado

a) PTP Manager

Caracterı́sticas : Es una aplicación de Software desarrollada por la la Universidad de Zurich ,

permite observar y administrar el tráfico los nodos PTP conectados a uan red Ethernet [10].
4.2. IMPLEMENTACIÓN DE LA RED 69

La comunicación entre la aplicación PTP Manager y el el reloj PTP usa los mensajes adminis-
trativos como se especifı́ca en el estandar IEEE 1588.
Entre sus caracterı́sticas principales estan:

Independencia de la plataforma debido a que está escrito en Java.

Visualización gráfica y edición de conjunto de datos definidos en el estándar

Representación gráfica de jerarquı́a de sincronización PTP ( Figura 4.17 ).

Visualización gráfica de datos del reloj como offset actual.

Recolección y registro de datos del reloj PTP.

Figura 4.16: Captura de pantalla PTP Manager

4.2. IMPLEMENTACIÓN DE LA RED 70

Figura 4.17: Vista jerarquı́a de red en PTP Manager

b) PTP Daemon (PTPd)

Caracterı́sticas : El demonio PTP (PTPd) es una implementación del protocolo PTP tal como se
define en el estándar IEEE 1588. Fue desarrollada por dos estudiantes de ingenierı́a en la universidad
Case Western Reserve [17].
PTPd es un sistema de software, que no considera hardware especializado. Entre sus principales
caracterı́sticas están :

PTPd usa marcas de tiempo por software. Registra el tiempo del mensaje enviado y recibido
en las capas de software de la pila de red más que en al capa fı́sica del hardware de red.

PTPd usa un reloj de software. Se ajusta la magnitud del incremento periódico de la cantidad
de tiempo almacenado en memoria .

PTPd esta orientado a plataformas embebidas con mı́nimos recursos. Esto incluye CPU’s por
debajo de los 100 Mhz.

Actualmente PTPd puede correr en Linux, uClinux, FreeBSD, and NetBSD. Y también podrı́a
ser portada a otras plataformas fácilmente .

En la figura 4.18 se muestra un diagrama de bloques de los componentes de PTPd más impor-
tantes.
4.3. CONSIDERACIONES PREVIAS 71

Figura 4.18: Arquitectura PTPd

Funcionamiento : La puesta en funcionamiento del software es hecha a través de la interfaz de

comandos del sistema operativo Linux. Para prevenir que la aplicación corra en segundo plano se
debe aplicar la opcion “c”. Una vez iniciado el software comenzará el ajuste del reloj del ordenador
.

4.2.3. Condiciones de Medición

Las condicones para las mediciones obtenidas han sido :

Temperatura: constante

Intervalo de sincronización: 2 segundos

Simetrı́a de los cables de red ideal

4.2.4. Métricas a Considerar

Para poder evaluar la exactitud de la red de sincronización se usará como métrica el valor
del offset del slave con respecto al master. Este valor de acuerdo al intervalo de sincronización es
calculado cada 2 segundos. Por lo tanto se entenderá que una configuración es más exacta que otra
cuando su valor de offset sea menor.

4.3. Consideraciones Previas

El principio de operación PTP es el intercambio de mensajes con regularidad para determinar
el offset entre master y slave pero también para conocer el delay a través de la red. La precisión
4.3. CONSIDERACIONES PREVIAS 72

del resultado depende de la precisión de las marcas de tiempo. Ellas reflejarán el tiempo de envı́o y
recepción de mensajes tan precisos como sea posible.
El cálculo del offset y del delay del slave está basado en la diferencia de las marcas de tiempo
tomadas en dos diferentes lugares. Sin embargo los dos relojes debieran usar la misma escala. Esto es
logrado compensando el desplazamiento del reloj, es decir, el reloj slave es acelerado o desacelerado.
En la definición del protocolo IEEE 1588 se asume que el delay de un mensaje es el mismo
en ambas direcciones. A primera vista este es el caso de una conexión Ethernet, pero entrando
en detalles, existen situaciones que no son totalmente ideales: Los cables usados tienen una menor
asimetrı́a por diseño, para reducir el efecto far end cross talk (FEXT), que es cuando uno de los pares
genera un campo electromágnetico que es radiado a otro de los pares disminuyendo su simetrı́a. Los
tranceivers Ethernets tienen caminos de emisión y recepción asimétricos. Si sus caracterı́sticas de
asimetrı́a estan claramente especificadas dentro de cierto rango, la asimetrı́a puede ser tomada en
cuenta por lo cálculos modificando las constantes de correción inbound latency y outbound latency
.
Durante un perı́odo de tiempo grande, las condiciones pueden cambiar debido a reconfiguración
o a condiciones del entorno como por ejemplo: la temperatura que puede afectar a los osciladores.
La rapidez con la cual puede reaccionar el reloj depende de la frecuencia de de la medida de las
marcas de tiempo de los mensajes de sincronización y el comportamiento dinámico de los servos
que controlan el reloj slave.
Para resumir ,el funcionamiento del protocolo IEEE 1588 depende de :

La simetrı́a del canal de comunicación (es decir, el mismo delay en ambas direcciones y cons-
tante sobre un perı́odo de tiempo).

Relojes con desplazamiento compensado (es decir,tiempo base ajustado en master y slave).

Exactitud de las marcas de tiempo.

Resolución de las marcas de tiempo.

Intervalo de mensajes de sincronización

Estabilidad del reloj.

Caracteristicas del lazo de control del reloj.

4.4. RESULTADOS EXPERIMENTALES 73

4.4. Resultados Experimentales

4.4.1. Comparación de Relojes

Para realizar la comparación de los relojes se ha usado la configuración de la figura 4.19. Dicha
configuración consiste de un reloj Grandmaster, el cual se usará como referencia para los demás
relojes del sistema implementado. Además existirán 3 relojes del tipo Ordinary Clock los cuales
tienen distintas caracterı́sticas. La selección del master y slave del sistema es hecha automáticamente
por el algoritmo BMC, que dadas las caracterı́sticas de cada reloj, como número de estrato e
identificador de reloj, escoge cual será la referencia del sistema. La interconexión de los distintos
nodos PTP se ha efectuado mediante un Switch Boundary Clock. El tráfico de la red sólo corresponde
a mensajes PTP, no existiendo algún otro tipo de tráfico en la red que pueda distorsionar los
resultados que permitan conocer cual de los relojes es más exacto.

Figura 4.19: Esquema de sincronización usando un Boundary Clock

Los gráficos obtenidos corresponden a la variación del offset del slave con respecto al master. El
master envı́a periodicamente un mensaje de sincronización (Sync), seguido de un mensaje Follow Up
con las marcas de tiempo. El proceso de cálculo se realiza cada dos segundos y se obtiene un valor
de offset que se ve reflejado en el gráfico.
A continuación se presentan los gráficos obtenidos al sincronizar la red. En primer lugar se
4.4. RESULTADOS EXPERIMENTALES 74

obtiene el gráfico para la sincronización de la tarjeta de desarrollo Imsys :

Figura 4.20: Sincronización con tarjeta Imsys

Gráfico obtenido para la sincronizacion de la tarjeta PCI (Figura 4.21 )

Figura 4.21: Sincronización con tarjeta PCI

Gráfico obtenido para la sincronización del Syncbox (Figura 4.22 )

4.4. RESULTADOS EXPERIMENTALES 75

Figura 4.22: Sincronización con SyncBox

En los histogramas obtenidos se pueden apreciar asimetrı́as las que se deben a las caracterı́sticas
del Chip fı́sico (PHY) donde se realizan las marcas de tiempo en el dispositivos, que aún siendo del
mismo tipo no aseguran la simetrı́a. La explicación en detalle se puede apreciar en la figura 4.23

Figura 4.23: Asimetrı́a en el retardo

Si el retardo del trasmisor y receptor del master y slave fueran iguales el sistema entonces serı́a
simétrico. Desafortunadamente los diferentes dispositivos chips fı́sicos (PHY) no tienen los mismos
4.4. RESULTADOS EXPERIMENTALES 76

retardos, lo que explica la asimetrı́a de los histogramas.

Para el caso de la sincronización con el Syncbox la configuración permite variar un parámetro
llamado “Phy Delay” que compensa el retardo introducido por el chip fı́sico (PHY) . El valor
introducido ha sido de -1500 ns y según se puede apreciar en la figura 4.22 converge hacia dicho
valor. Para explicar de mejor manera como afecta el valor introducido, se explicará a través de las
siguientes ecuaciones :

Of f set = Ts1 − Tm1 − Delay (4.1)

Donde Ts1 mide el tiempo exacto de recepción de mensaje Sync, Tm1 corresponde al tiempo
exacto de transmisión del mensaje Sync y Delay corresponde al retardo de lı́nea. Reemplazando el
la ecuacion 4.2 se tiene que :

Of f set = Ts1 − Tm1 − 1500ns (4.2)

Por lo tanto la función Offset del master con respecto al slave tendrá un factor constante de
1500ns.

Figura 4.24: Boundary Clock

El switch con Boundary Clock posee la particularidad que sus puertos se sincronizan a los los
nodos PTP que están conectados a ellos, por lo tanto para el caso de la configuración mostrada
en la figura 4.19 un puerto actuará como slave del Grandmaster y el resto de los puertos servirán
de master para los restantes nodos PTP. La sincronizacion del reloj Grandmaster con respecto al
pueto configurado como slave del Switch con Boundary Clock se puede apreciar en la figura 4.24
4.4. RESULTADOS EXPERIMENTALES 77

4.4.2. Sincronización con un Switch

Para esta segunda prueba se ha utilizado el Swich Ethernet 10/100 Mbps estándar para conocer
como se comporta cuando es utilizado para interconectar nodos PTP. En primer lugar se ha realizado
la sincronización sin utilizar carga , tal como lo muestra la figura 4.25 y posteriormente se aplicaron
distintos niveles y tipos de carga, usando un generador de tráfico como se muestra en la figura 4.47
para conocer como es afectada la sincronización. Se pretende estudiar mediante la aplicación de
carga, como se ve afectado el envı́o y recepción de mensajes PTP.
El switch tiene como caracterı́stica principales operar en la capa de enlace de datos del modelo
OSI, lo que significa que pasa datos de un segmento a otro, según la dirección MAC de los datagramas
en la red. Por lo tanto cada datagrama que pasa por el switch debe ser analizado para conocer su
destino, lo que aumenta el jitter de la red. Adicionalmente el switch utilizado no cuenta con QoS
(Quality of Service) que priorice ancho de banda para algún fin especı́fico, por lo que no reserva
ancho de banda para el protocolo PTP.

Figura 4.25: Esquema de sincronización usando un Switch

4.4. RESULTADOS EXPERIMENTALES 78

Figura 4.26: Esquema de sincronización usando un Switch y aplicando carga

A continuación se presentan los gráficos obtenidos al sincronizar dos nodos PTP usando un
switch :

Figura 4.27: Switch sin carga

Los gráficos de la figura 4.27 muestran el comportamiento del offset cuando se efectúa la sincro-
nización de los nodos PTP usando como medio de interconexión a un switch ethernet estándar. No
existen grandes fluctuaciones en los valores de offset obtenidos. Existe una simetrı́a con respecto al
4.4. RESULTADOS EXPERIMENTALES 79

cero, lo que indica que la sincronización no ha sido afectada mayormente.

Teniendo como referencia los valores obtenidos en la figura 4.27. Los resultados obtenidos apli-
cando niveles de carga continuo se detallan a continuación:

Figura 4.28: Switch utilizando 5 % de ancho de banda y carga continua

Figura 4.29: Switch utilizando 25 % de ancho de banda y carga continua

4.4. RESULTADOS EXPERIMENTALES 80

Figura 4.30: Switch utilizando 60 % de ancho de banda y carga continua

Del gráfico 4.28 se puede apreciar que con solamente 5 % de uso de ancho de banda con tráfico
continuo equivalente a aproximadamente a 4 Mbps el offset del slave varı́a en más de 30000 nanose-
gundos. Cuando se aplica mayor cantidad de carga se incrementa notoriamente la frecuencia de las
variaciones de offset, pero en magnitud no aumentan tal como lo demuestran las figuras 4.29 y 4.30
Los resultados obtenidos aplicando niveles de carga a ráfagas se detallan a continuación:

Figura 4.31: Switch utilizando 5 % de ancho de banda y carga a ráfagas

4.4. RESULTADOS EXPERIMENTALES 81

Figura 4.32: Switch utilizando 25 % de ancho de banda y carga a ráfagas

Figura 4.33: Switch utilizando 60 % de ancho de banda y carga a ráfagas

De los resultados obtenidos se puede inferir que cuando la carga es continua afecta simétrica-
mente el envı́o de mensajes de master a slave, debido a que los mensajes Sync y Follow Up ocurre
a intervalos constantes (Cada 2 segundos por defecto). En cambio el envı́o de mensajes Delay Req
y Delay Resp ocurren a intervalos aleatorios y según el tipo de carga dependerá como es afectada
la sincronización . Por lo tanto observando la figura 4.34 se puede decir que cuando la carga es
continua afecta simetricamente los mensajes PTP, en cambio cuando se envia una ráfaga podrı́a no
coincidir con el momento en que se está enviando un mensaje Delay Req y Delay Resp.
4.4. RESULTADOS EXPERIMENTALES 82

Figura 4.34: Diagrama de envı́o de mensajes

4.4.3. Sincronización con un Boundary Clock

Ahora sustituyendo el Switch estándar por uno con Boundary Clock, y siguiendo el mismo
procedimiento usado para el switch. En primer lugar se ha sincronizado el reloj Grandmaster con
la tarjeta PCI IEEE 1588, sin la aplicación de carga, tal como se aprecia en el esquema de la figura
4.35, y luego se han aplicado distintos niveles de carga como se indica en la figura 4.36.

Figura 4.35: Esquema de sincronización usando un Boundary Clock

4.4. RESULTADOS EXPERIMENTALES 83

Tal como se dijo en capı́tulos anteriores el Boundary Clocks es un reloj integrado en un swtich.
Este reloj está sincronizado a una fuente de referencia por un lado, y por el otro está sincronizado
con relojes del tipo Ordinary Clocks. En el caso que se presenta en esta sección se ha sincronizado
un reloj GrandMaster con una tarjeta PCI IEEE 1588.
Posteriormente la sincronización se realizó usando la configuración de la figura 4.36.

Figura 4.36: Esquema de sincronización usando un Boundary Clock y aplicando carga

En la figura 4.37 se aprecia los resultados obtenidos al sincronizar usando un Boundary Clock
sin aplicar carga.
4.4. RESULTADOS EXPERIMENTALES 84

Figura 4.37: Boundary Clock sin carga

Si bien al igual que gráficos anteriores, el histograma de la figura 4.37 presenta leves asimetrı́a,
que se explican de igual forma que en casos presentados anteriormente, es decir, por diferencias del
chip fı́sico (PHY) donde se efectúan las marcas de tiempo.
A continuación se presentan los resultados obtenidos al aplicar distintos niveles de carga continua
:

Figura 4.38: Boundary Clock utilizando 5 % de ancho de banda y carga continua

4.4. RESULTADOS EXPERIMENTALES 85

Figura 4.39: Boundary Clock utilizando 25 % de ancho de banda y carga continua

Figura 4.40: Boundary Clock utilizando 60 % de ancho de banda y carga continua

Observando las figura 4.37 y comparándola con las figuras 4.38, 4.39 y 4.40 se puede notar que no
existe una variación significativa en la sincronización entre el Grandmaster y la tarjeta PCI Ethernet
con protocolo IEEE 1588. Esto se debe a que el switch con Boundary Clock ayuda a eliminar los
retardos de red.
A continuación se presentan los resultados obtenidos al aplicar distintos niveles de carga a
4.4. RESULTADOS EXPERIMENTALES 86

ráfagas:

Figura 4.41: Boundary Clock utilizando 5 % de ancho de banda y carga a ráfagas

Figura 4.42: Boundary Clock utilizando 25 % de ancho de banda y carga a ráfagas

4.4. RESULTADOS EXPERIMENTALES 87

Figura 4.43: Boundary Clock utilizando 60 % de ancho de banda y carga a ráfagas

Teniendo como base de comparación la figura 4.37 se puede observar que al igual que en el caso
de la carga continua, la carga a ráfagas no afecta el desempeño de la sincronización. La razón para
explicar esta situación es que los datagramas PTP son procesados por el Boundary Clock con el
fin de sincronizar el reloj interno y sincronizar otros relojes conectados a él. Esto demuestra que el
Boundary Clock es independiente de la carga de red.

4.4.4. Switch Versus Boundary Clock

En esta sección se presentan a modo de resumen las comparaciones entre un Switch Ethernet
estándar y uno con Boundary Clock.
En primer lugar para el caso sin carga, como se indica en la figura 4.44 se puede apreciar una
notoria diferencia entre los resultados obtenidos. En (a) el resultado usando el Boundary Clock y
en (b) el resultado para el switch.
4.4. RESULTADOS EXPERIMENTALES 88

(a) Boundary Clock (b) Switch

Figura 4.44: Switch versus Boundary Clock, sin carga

En la figura 4.45 se puede apreciar como tan sólo con 5 % de utilización de ancho de banda se
ve afectada la sincronización notoriamente.

(a) Boundary Clock (b) Switch

Figura 4.45: Switch versus Boundary Clock, utilizando 5 % de ancho de banda y carga continua

En la figura ?? se muestra como la distribución de frecuencia para el Boundary Clock (a) es

mucho menor que para el Switch (b)
4.4. RESULTADOS EXPERIMENTALES 89

(a) Boundary Clock (b) Switch

Figura 4.46: Switch versus Boundary Clock, sin carga (Histogramas)

De los gráficos anteriores se puede notar la necesidad de utilizar un Boundary Clock, a la

izquierda los gráficos del boundary clock ya la derecha los del switch.

4.4.5. PTPd

Debido a que PTPd es una herramienta de sofware libre, que está a libre disposición, para
las pruebas se ha utilizado hardware fácilmente accesible y de bajo costo. Se ha utilizado una
tarjeta de desarrollo Imsys como referencia de tiempo y un ordenador de escritorio equipado con
un procesador Pentium D de 3.40 gHz, con 1 Gb de RAM y con una tarjeta Ethernet 10/100
Mbps estándar, conectados mediante un Switch Ethernet corriendo sobre el sistema operativo Linux
Fedora 8 Kernel [Link]-42.fc8.
4.4. RESULTADOS EXPERIMENTALES 90

Figura 4.47: Esquema de sincronización para PTPd

En la figura 4.48 se muestra como se inicia la sincronización. Existe un perı́odo de aproximada-

mente de 400 segundos donde el ordenador debe estabilizar su oscilador interno.

PTPd PTPd
500
0

400
−500000

300
Frecuencia
Offset (ns)

−1000000

200
−1500000

100
0

0 200 400 600 800 1000

−2000000 −1500000 −1000000 −500000 0

Segundos Offset (ns)

Figura 4.48: Gráfico de sincronización usando PTPd

Posteriormente una vez que se ha estabilizado el oscilador del ordenador el rango de offset del
master con respecto al slave es de 150000 nanosegundos (Ver Figura 4.49).
4.5. DISCUSIÓN FINAL 91

PTPd PTPd

150000

60
100000

50
50000

40
Frecuencia
Offset (ns)

30
−50000

20
10
−150000

0
0 200 400 600 800 1000 −150000 −100000 −50000 0 50000 100000 150000

Segundos Offset (ns)

Figura 4.49: Gráfico de sincronización usando PTPd luego de perı́odo de estabilización

Los resultados distan muchos de los obtenidos anteriormente con otras configuraciones. La razón
para ello es debido a que en los dispositivos utilizados en la configuración, no existen unidades
especı́ficas para realizar marcas de tiempo por hardware. Lo que implica que cada uno de los
elementos de la red sumen Jitter y retardo a la red. Adicionalmente el software no corre como un
único proceso en el ordenador lo que implica al usarse marcas de tiempo por hardware se introduzca
retardo.

4.5. Discusión Final

En el presente capı́tulo se han presentado los resultados de implementaciones para redes de
sincronización. Una usando un Switch estándar y otro usando un Boundary Clock. Ası́ como también
se ha evaluado el uso de marcas de tiempo por software , en este caso usando el software libre PTPd.
El propósito de las redes de sincronización implementadas ha sido obtener el menor offset del slave
posible. Lo que ha sido conseguido haciendo uso del Boundary Clock.
Analizando los datos obtenidos de las mediciones realizadas se puede observar la razón por la
cual utilizar un boundary clock en lugar de un switch. La tabla 4.1 muestra que la desviación
estándar es mayor usa un switch ethernet, y menor cuando se usa un Boundary Clock cuando se
realiza la sincronización sin la aplicación de carga.

Media Desv. Std

Switch 0.1662708ns 159.5111ns
Boundary Clock -0.1353919ns 20.5224ns

Tabla 4.1: Tabla Comparativa Switch versus Boundary Clock sin carga
4.5. DISCUSIÓN FINAL 92

La tabla 4.2 hace una comparativa entre los distintos tipos de relojes que se han sincronizado
con el Grandmaster como reloj de referencia, como se indica en la figura 4.19 .Se han agragado 3
ordinary clocks : Tarjeta Imsys , Tarjeta Ethernet IEEE 1588 y SyncBox , además en la tabla se
ha agregado el Boundary clock. Los resultados muestran que el menor valor de desviación estándar
para los ordinary clocks es el obtenido para Tarjeta Ethernet IEEE 1588, pero que en relación al
Switch Hirshmann del tipo Boundary Clock resulta ser mayor, aunque no significativamente.

Tipo Media Desv. Std

Tarjeta Imsys Ordinary Clock -5.536817ns 93.45272ns
T. Ethernet IEEE1588 Ordinary Clock -1.016627ns 20.24239ns
SyncBox Ordinary Clock -1135.6770ns 277.6762ns
Switch Hisrchmann Boundary Clock -0.1995249ns 12.00786ns

Tabla 4.2: Tabla comparativa de relojes

La Tabla 4.3 muestra como se ve afectado un Switch estándar cuando es aplicada carga. Se
puede apreciar un gran incremento de la desviación estándar en relación a los valores obtenidos sin
carga, como se muestra en la tabla 4.1 para el Switch sin carga. Se aprecia también que cuando se
aplica carga continua los valores de desviación estándar son superiores a cuando se aplica carga en
ráfagas.

Media Desv. Std

5 % Ancho de Banda - Tráf. continuo 506.0594ns 5708.410ns
25 % Ancho de Banda - Tráf. continuo 578.5107ns 12560.570ns
60 % Ancho de Banda - Tráf. continuo -301.3397ns 10693.140ns
5 % Ancho de Banda - Tráf. ráfagas 45.9858ns 1487.116ns
25 % Ancho de Banda - Tráf. ráfagas 66.3848ns 4179.598ns
60 % Ancho de Banda - Tráf. ráfagas 88.99525ns 5495.153ns

Tabla 4.3: Tabla comparativa para el Switch

En la Tabla 4.4 se muestran los resultados obtenidos para el caso de la sincronización usando un
Boundary Clock. Se aprecia que en comparación con los valores de la tabla 4.1 para sincronizacion
sin carga que los valores para distintos tipos de carga,ya sea carga continua como carga en ráfagas
no varia significativamente, lo que implica que el offset del slave con respecto al master no sufre
mayores alteraciones.
4.5. DISCUSIÓN FINAL 93

Media Desv. Std

5 % Ancho de Banda - Tráf. continuo -0.5083135ns 19.58262nss
25 % Ancho de Banda - Tráf. continuo 0.7367304ns 20.25189ns
60 % Ancho de Banda - Tráf. continuo -1.242280ns 21.17744ns
5 % Ancho de Banda - Tráf. ráfagas -0.09501188ns 21.42074ns
25 % Ancho de Banda - Tráf. ráfagas 0.2494062ns 21.14861ns
60 % Ancho de Banda - Tráf. ráfagas -0.04750594ns 20.05083ns

Tabla 4.4: Tabla comparativa para el Boundary Clock

Queda claro entonces que la única forma para conseguir una muy alta exactitud son las marcas
de tiempo por hardware. Las marcas de tiempo software en muchos casos es problemático,pero su
menos costo hace que en cierto tipos de aplicaciones pueda ser usado cuando no se necesita una
exactitud demasiado alta.
Las marcas de tiempo por Software estan afectadas por muchas actividades en un [Link]
más importantes son el hardware del nodo PTP y el entorno de software,topologı́a de la red y
patrones de tráfico,Por ejemplo :

Interrupciones son habilitadas durante operaciones crı́ticas , por ejemplo : Uso intensivo de
disco para E/S , mucho tiempo es gastado en el kernel.

Otros tráficos usando la misma interfaz de red como los mensajes afectan la coordinación de
operación de transmisión y recepción.

La medida principal para mejorar las marcas de tiempo son :

Ejecución suficiente. Periodos de actividad de alta prioridad e interrupciones deshabilitadas

mas cortas.

Evitar largos periodos de uso intensivo de disco. Picos cortos pueden ser filtrados. La duración
de picos tolerables esta en relación con la estabilidad del reloj y los parametros del servo.

No excesivo tráfico en el segmento Ethernet. Esto minimizará la variación del camino de

transmisión y recepción.

Determinar la asimetrı́a de los caminos transmisión y recepción, y tomarlo en cuenta en los

cálculos.
4.5. DISCUSIÓN FINAL 94

Estas medidas pueden ser tomadas solamente si el entorno operacional esta cuidadamente di-
señado,correctamente configurado y bien [Link] criterios pueden ser encontrados por sis-
temas embebidos corriendo un sistema operativo de tiempo real. En un entorno de PC estándar
es difı́cil alcanzar un resultado predecible. Bajo este pre requisito las marcas de tiempo pueden
entregar resultados aceptables para cierto tipo de aplicaciones.
Capı́tulo 5

Conclusiones

El objetivo principal de este Proyecto de Fin de Carrera, ha sido sincronizar un red de datos con
la mayor precisión posible, para lo cual se ha han analizado varias alternativas de configuración. Se
consideraron alternativas de hardware como Switches y Boundary clocks y se utilizaron varios tipos
de relojes para evaluar cuales eran los que ofrecı́an las mejores prestaciones. También se consideraron
soluciones de solo Software como PTP daemon (PTPd).
De las alternativas analizadas los mejores resultados obtenidos han sido mediante la utilización
del Switch Hirshmann que actúa como Boundary Clock, el cual a pesar de la aplicación de carga
no afecta a la sincronización ,como ası́ lo demuestra los diferentes valores obtenidos de desviación
estándar, para distintos tipos de carga (Ver Tabla 4.4) . A diferencia de lo anterior ,el switch con
la aplicación de niveles de carga bajos (Ver Tabla 4.3) afecta considerablemente el rendimiento de
la sincronización lo que se ve reflejado en los gráficos de la sección. 4.4.2.
De los relojes utilizados (ordinary clocks) el que presenta las mejores prestaciones en cuan-
to a sincronización ha sido la tarjeta PCI Ethernet de la Zurich University of Applied Sciences
Winterthur, con implementación del protocolo IEEE 1588 (ver Tabla 4.2).
La utilización de la implementación del protocolo de solo software ha sido la que peores resultados
ha entregado tal como se puede apreciar en los gráficos de la sección 4.4.5. El tiempo de convergencia
es de alrededor de 400 segundos , y una vez lograda la convergencia el offset del slave con respecto
al master es del orden de 150 microsegundos, muy por debajo ddel rendimiento de otras alternativas
de hardware analizadas en este Proyecto de Fin de Carrera.
Por lo tanto de las alternativas estudiadas, la mejor alternativa para alcanzar la mayor precisión
posible resulta ser de la combinación de Switches con Boundary Clock junto con relojes que utilizan
una unidad de Time Stamping ,como lo es la Tarjeta Ethernet IEEE 1588.

95
5.1. ASPECTOS RELEVANTES Y APORTES 96

5.1. Aspectos Relevantes y Aportes

Los aportes de mayor relevancia realizados por este proyecto de fin de carrera han sido :

Realizar una descripción de los aspectos más importantes del protocolo que deben ser consi-
derados para implementar una red de sincronización.

Mostrar diferentes alternativas para una red de sincronización entregando tanto soluciones de
bajo costo como la utilizacion de PTPd, ası́ como alternativas técnicamente más sofiticadas
como la utilización de Relojes GPS y Switches con Boundary Clock.

Demostrar con mediciones que las alternativas analizadas estudiadas resultan más precisas .

5.2. Trabajos Futuros

En base a el trabajo de este Proyecto de Fin de Carrera en un futuro algunas extensiones podrı́an
ser :

Estudiar el protocolo IEEE 1588 aplicado a redes inalámbricas.

Estudiar posibles aplicaciones en el área de sensores inalámbricos para extender el tiempo de

vida de la red.

Implementar una red de sincronización sobre otros protocolos de comunicación, no sólo con-
siderando como alternativa una red Ethernet.
Bibliografı́a

[1] [Link] protocol

[2] [Link]

[3] ArCERT, Coordinación de Emergencias en Redes Teleinformáticas de Argentina,

[Link] Instalación y configuración de NTP. Agosto 2006.

[4] D. Mills. Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. Octubre,
2006.

[5] Timing Committee Telecomunications and Timing Groupe Range Commander Council. IRIG
Serial Time Code Formats. Septiembre 2004

[6] Universal Time, [Link] .

[7] [Link]

[8] [Link]

[9] [Link]

[10] [Link]

[11] [Link] . The Role of GrandMaster ,Boundary and ordinary Clocks in IEEE 1588 Preci-
sion Time Protocol for frequency synchronization over packet network.

[12] M. Burnicki, H. Gerstung, U. Maltzahn. Using PTP for synchronization legacy networks. IEEE
1588 Conference and Plug Fest, 2005.

[13] H. Weibel. What is it? Where is it used? How does it work ? How to implement it ? , 2005

[14] R. Dlugy, H. Huckeba . Designing and testing IEEE 1588 Timing Networks. Enero ,2007.
97
BIBLIOGRAFÍA 98

[15] H. Weibel, D. Béchaz. IEEE 1588 Implementatios and Performance of Time Stamping Techi-
[Link] on IEEE 1588, 2004.

[16] J. Eidson, M. Fisher, J. White. IEEE 1588 Standard for a Precision Clock Synchronization
Protocol for Metworked Measurement and Control Systems.

[17] K. Correl, N. Barendt, M. Branicky. Design Consideration for Software Only Implementations
of the IEEE 1588 Precision time Protocol.

[18] H. Weibel. IEEE 1588 [Link] on IEEE [Link] Institute of Standars and
Technology. Octubre , 2006.

[19] T. Neagoe, L. Banica. A comparison of clock Synchronization Protocols in Computer Networks.

[20] S. Rodrigues. Many Applications, Different Requirements.

[21] D. Kohl. IEEE 1588 Precise Time Synchronization as the Basis for Real Time Applications in
Automations.

[22] IEEE. IEEE P1588, Draft Standard for a Precision Clock Synchronization Protocol for Ne-
tworked Measurement and Control System. 2002.