BRPI0711770A2 - serviço de timestamping de precisão de protocolo de tempo de rede - Google Patents
serviço de timestamping de precisão de protocolo de tempo de rede Download PDFInfo
- Publication number
- BRPI0711770A2 BRPI0711770A2 BRPI0711770-1A BRPI0711770A BRPI0711770A2 BR PI0711770 A2 BRPI0711770 A2 BR PI0711770A2 BR PI0711770 A BRPI0711770 A BR PI0711770A BR PI0711770 A2 BRPI0711770 A2 BR PI0711770A2
- Authority
- BR
- Brazil
- Prior art keywords
- packet
- transmission
- lef
- timestamp
- ntp
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04J—MULTIPLEX COMMUNICATION
- H04J3/00—Time-division multiplex systems
- H04J3/02—Details
- H04J3/06—Synchronising arrangements
- H04J3/0635—Clock or time synchronisation in a network
- H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
- H04J3/0658—Clock or time synchronisation among packet nodes
- H04J3/0673—Clock or time synchronisation among packet nodes using intermediate nodes, e.g. modification of a received timestamp before further transmission to the next packet node, e.g. including internal delay time or residence time into the packet
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04J—MULTIPLEX COMMUNICATION
- H04J3/00—Time-division multiplex systems
- H04J3/02—Details
- H04J3/06—Synchronising arrangements
- H04J3/0635—Clock or time synchronisation in a network
- H04J3/0685—Clock or time synchronisation in a node; Intranode synchronisation
- H04J3/0697—Synchronisation in a packet node
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/28—Timers or timing mechanisms used in protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L7/00—Arrangements for synchronising receiver with transmitter
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Synchronisation In Digital Transmission Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
SERVIçO DE TIMESTAMPING DE PRECISãO DE PROTOCOLO DE TEMPO DE REDE. As modalidades da presente invenção estabelecem ummétodo e um sistema para a redução da incerteza nas timestamps de recepção e de transmissão criadas por um servidor de NTP. A incerteza nas estampas de tempo de recepção é removida pela gravação do tempo de chegada no relógio de hardware do servidor de NTP, antes dos pacotes de entrada poderem ser atrasados por atravessarem as várias camadas de software em um sistema de timestamping. A incerteza nas estampas de tempo de transmissão é removida ao se proporcionar aos pacotes de saída uma timestamp no futuro usando uma estimativa de uma latência de transmissão calculada pelo filtro estimador de latência. Subseqüentemente, o tempo de partida real é usado para se recalcular e atualizar a timestamp da latência de transmissão. Desta forma, um controle superior da função de Limestamping pode ser implementado em servidores de NTP existentes de uma maneira que retenha uma compatibilidade de entrelaçamento com os padrões de NTP atuais.
Description
SERVIÇO DE TIMESTAMPING DE PRECISÃO DE PROTOCOLO DE TEMPO DE REDE
ANTECEDENTES DA INVENÇÃO
Campo da Invenção
As modalidades da presente invenção se referem geralmente à melhoria da acurácia de desvio de tempo entre os percursos de transmissor e de receptor por redes de dados e, mais especificamente, a um serviço de timestamping (estampagem de tempo) de precisão de protocolo de tempo de rede.
Descrição da Técnica Relacionada
Em muitas aplicações de comunicações, cada elemento em uma rede tem seu próprio relógio interno que roda independentemente dos outros relógios na rede. Quando as redes são redes slncronas, como em muitas aplicações de telecomunicações e em redes de área ampla de alta velocidade, estes relógios devem ser sincronizados com o servidor. Em redes de telecomunicações de legado, os elementos de rede utilizavam enlaces de "TDM", tais como Tl e SONET, os quais são inerentemente capazes de portarem uma informação de sincronismo do servidor para o cliente na camada física. Contudo, geralmente é acordado que as redes de próxima geração serão baseadas em uma infra-estrutura de pacote comutado e, portanto, métodos baseados em pacote para o transporte de uma informação de sincronismo serão usados. Um dos métodos para sincronização de relógios em redes de dados de pacote comutado é o Protocolo de Tempo de Rede (NTP).
Os servidores comerciais de NTP tipicamente empregam relógios baseados em hardware altamente acurados, os quais são disciplinados aos padrões externos. Por sua vez, os clientes de NTP enviam pacotes cuidadosamente produzidos para os servidores de NTP e analisam suas respostas, de modo a se determinar o desvio do relógio de cliente em relação ao relógio de servidor. Um pacote típico contém quatro estampas de tempo. As estampas de tempo são projetadas para marcarem precisamente o tempo dos percursos de transmissão e de recepção do intercâmbio de pacote de tempo de cliente / servidor, de modo que o atraso de ida e volta entre os pontos extremos e o desvio do relógio de cliente possam ser calculados. Contudo, apesar da alta acurácia do relógio baseado em hardware no servidor de NTP, se houver quaisquer inacurácias associadas à função de timestamp (estampa de tempo) no servidor de NTP, o servidor de NTP introduzirá erros nas estampas de tempo providas para o cliente. Subseqüentemente, estes erros se propagam para o relógio de cliente e comprometem a correção apropriada do relógio de cliente.
A maior parte das inacurácias em estampas de tempo criadas pelo servidor de NTP é introduzida por várias camadas de software, incluindo drivers de dispositivo, pilhas de rede e aumentando-se o uso de sistemas operacionais não em tempo real. Isto é ilustrado na Figura 1, demonstrando conceitualmente um fluxo de timestamp de pacote em um sistema de NTP típico 100, de acordo com a técnica anterior. A maioria dos servidores de NTP existentes inclui sistemas tal como o sistema de NTP 100.
Tipicamente, uma timestamp em um pacote é suposta como refletindo o instante da chegada ou partida referenciado para a interface de camada física. Com referência à Figura 1, a camada física está associada a uma PHY de Ethernet 110. Neste caso, o tempo de chegada se refere ao instante em que o primeiro bit (ou o designado) de cada um dos pacotes de chegada atravessa a fronteira entre o ambiente externo (não mostrado) e a PHY de Ethernet 110 e o ambiente externo.
Conforme ilustrado na Figura 1, quando um pacote de entrada 102 chega ao sistema de NTP 100, ele passa através de várias entidades: a camada física associada à PHY de Ethernet 110, um Controlador de Acesso a Mídia de Ethernet (MAC) 120, serviços de sistema operacional (O/S) 130, um aplicativo de NTP 140. Algumas destas entidades são físicas (tal como o MAC de Ethernet 120) e algumas são lógicas (tais como os serviços de O/S 130) . Um percurso para o pacote de entrada 102 é mostrado com as setas 112, 122 e 132. Conforme mostrado com uma seta 142, o aplicativo de NTP 140 requisita uma timestamp a partir de um relógio de hardware 150 a ser gravada no pacote de entrada 102 apenas após o pacote de entrada 102 atravessar a PHY de Ethernet 110, o MAC de Ethernet 120 e os serviços de O/S 130 e realmente atingir o aplicativo de NTP 140 (uma timestamp como essa é referida aqui como "timestamp de recepção"). Mediante o recebimento de uma requisição a partir do aplicativo de NTP 140, o relógio de hardware 150 envia o valor de tempo atual como a timestamp de recepção, ilustrada como as estampas de tempo 144. Assim, há um atraso, com um componente randômico significativo, entre o tempo de chegada real no sistema de NTP 100 e o tempo em que o aplicativo de NTP 140 realmente lê o relógio de hardware 150 para avaliar o valor para a timestamp de recepção.
Uma situação similar ocorre para um pacote de saída 104 deixando o sistema de NTP 100. O aplicativo de NTP 140 lê o valor de tempo atual a partir do relógio de hardware 150 e insere aquele valor como uma timestamp no campo apropriado dentro do pacote de saída 104 (uma timestamp como essa é referida como uma "timestamp de transmissão"). Após a timestamp de transmissão ser inserida, o aplicativo de NTP 140 abre o pacote de saída 104 em um percurso mostrado pelas setas 134, 124 e 114. De novo, uma vez que o pacote de saída 104 deve primeiramente atravessar os serviços de O/S 130, o MAC de Ethernet 120 e a PHY de Ethernet 110, há um atraso, com um componente randômico significativo, entre o instante em que a timestamp de transmissão foi obtida a partir do relógio de hardware 150 e o tempo de partida real a partir do sistema de NTP 100. Conseqüentemente, estampas de tempo de recepção e de transmissão não acuradas se propagam a partir do sistema de NTP 100 para o relógio de cliente e regulam o erro de linha de base para a manutenção de tempo e a manutenção de taxa no relógio de cliente.
Como ilustra o precedente, o que é necessário na técnica é um método de timestamp de NTP melhorado, o qual pudesse prover uma medição mais precisa e estável da transição dos pacotes de NTP.
SUMÁRIO DA INVENÇÃO
Uma modalidade da presente invenção estabelece um pacote de método para o estabelecimento de uma timestamp de transmissão a ser inserida em um pacote de saída por um servidor de protocolo de tempo de rede (NTP). O método inclui as etapas de requisição do tempo atual a partir de um relógio de hardware dentro do servidor de NTP, e a requisição de um termo de correção a partir de um filtro estimador de latência (LEF), onde o termo de correção é uma estimativa de uma latência de transmissão associada ao pacote de saída atravessando várias camadas de software, antes de cruzar uma fronteira com um ambiente externo. O método também inclui as etapas de inserção de uma soma do tempo atual e do termo de correção no pacote de saída como a timestamp de transmissão, a colocação do pacote de saída com a timestamp de transmissão em uma fila externa, o disparo do relógio de hardware para finalizar ("latch") um tempo de partida do pacote de saída, a realização das etapas de um algoritmo de LEF para a atualização do termo de correção pelo cálculo de um desvio entre a timestamp de transmissão e o tempo de partida finalizado para a obtenção de uma timestamp de transmissão mais acurada no próximo pacote de saída, o armazenamento do termo de correção atualizado e o uso do termo de correção atualizado para a inserção da timestamp de transmissão em um próximo pacote de saída.
Uma vantagem dos sistemas e métodos mostrados é que um controle melhorado da função de timestamp de transmissão pode ser implementado nos servidores de NTP existentes, sem o risco de introdução de incompatibilidades de entrelaçamento com outros servidores e clientes que estejam em conformidade com os padrões de NTP atuais. De modo importante, os métodos mostrados incluem as etapas que utilizam um agente de timestamping de pacote e o filtro estimador de latência de uma maneira que retém a compatibilidade com os padrões de NTP atuais. Desta forma, o tempo de chegada e o tempo de partida são detectados e registrados pelo hardware, desse modo se obtendo um alto grau de precisão, e a incerteza associada aos drivers e dispositivo, pilhas de rede, sistema operacional e assim por diante é evitada. Como resultado, estampas de tempo de servidor de NTP mais acuradas e mais estáveis são providas para o cliente de NTP.
BREVE DESCRIÇÃO DOS DESENHOS
Para que a maneira pela qual os recursos recitados acima da presente invenção podem ser entendidos em detalhes, uma descrição mais particular da invenção, brevemente resumida acima, pode ser tida por uma referência às modalidades, algumas das quais sendo ilustradas nos desenhos em apenso. Ê para ser notado, contudo, que os desenhos em apenso ilustram apenas modalidades típicas desta invenção e, portanto, não devem ser considerados como limitativos de seu escopo, pois a invenção pode admitir outras modalidades igualmente efetivas.
A Figura 1 é um diagrama conceituai de um fluxo de timestamping de pacote em um sistema de NTP típico, de acordo com a técnica anterior;
a Figura 2 ilustra estampas de tempo contidas em um cabeçalho de um pacote de NTP, de acordo com uma modalidade da presente invenção;
a Figura 3 é um diagrama conceituai de um fluxo de timestamping de pacote em um sistema de timestamping de precisão (PTS), de acordo com uma modalidade da presente invenção;
a Figura 4 estabelece um fluxograma de etapas de método implementadas pelo sistema de PTS da Figura 3, de acordo com uma modalidade da presente invenção;
a Figura 5 estabelece um fluxograma de etapas de método implementadas pelo filtro estimador de latência da Figura 3, de acordo com uma modalidade da presente invenção; e
a Figura 6 ê um diagrama conceituai de um servidor de NTP de precisão configurado para a implementação de um ou mais aspectos da presente invenção.
DESCRIÇÃO DETALHADA
A Figura 2 ilustra estampas de tempo contidas em um cabeçalho de um pacote de NTP, de acordo com uma modalidade da presente invenção. Conforme mostrado na Figura 2, cada medição de tempo ao longo de uma linha de tempo 200 envolve quatro estampas de tempo, as quais são definidas conforme se segue: T1 é uma timestamp que representa a melhor estimativa da época de origem de transmissão de um pacote se originando a partir do relógio de cliente 210, T2 é uma timestamp que representa a melhor estimativa da época de terminação de recepção de um pacote terminando em um relógio de servidor de NTP de precisão 220, T3 é uma timestamp que representa a melhor estimativa da época de origem de transmissão de um pacote se originando a partir do relógio de servidor de NTP de precisão 220, e T4 é uma timestamp que representa a melhor estimativa da época de terminação de recepção de um pacote terminando no relógio de cliente 210. Após a medição de tempo, estas quatro estampas de tempo são usadas para o cálculo do atraso de ida e volta entre os pontos extremos e o desvio do relógio de cliente 210 de acordo com os princípios a seguir: a) estimativa de atraso: σ = (T4- T1) - (T3 - T2) (1)
b) estimativa de desvio: Θ = [(T2- Ti) + (T3 - T4)]/2 (2)
c) erro: ε = φ . (T4-Ti) + α (3) onde φ(t) é uma função que descreve a taxa de acumulação de inclinação ("skew") do relógio de cliente e α é uma medida de incerteza da medição de tempo de servidor de NTP de precisão.
Uma vez que o servidor de NTP de precisão é primariamente responsável pela provisão de T2 e T3 para o relógio de cliente 210, qualquer inacurácia nos valores de T2 e de T3 contribui para as inacurácias nas estimativas de atraso e desvio, o que, por sua vez, resulta em um valor aumentado de incerteza no processo de medição de tempo a. Contudo, a equação (3) demonstra que o servidor de NTP de precisão também pode melhorar a performance do circuito de medição de tempo pela redução da incerteza no processo de medição de tempo α. 0 sistema e o método para a obtenção de medições de tempo mais acuradas e estáveis a partir do servidor de NTP de precisão são descritos nas Figuras 3 a 5.
A Figura 3 é um diagrama conceituai de um fluxo de timestamping de pacote em um sistema de serviço de times tamping de precisão (PTS) 300, de acordo com uma modalidade da presente invenção. Conforme mostrado, o sistema de PTS 300 inclui, sem limitação, a camada física associada a uma PHY de Ethernet 310, um MAC de Ethernet 320, os serviços de O/S 330, um aplicativo de NTP 340 e um relógio de hardware 350. Conforme descrito previamente, o tempo de chegada (denotado como Trx) de um pacote de entrada 302 se refere ao instante em que o primeiro bit (ou designado) do pacote de entrada 3 02 atravessa a fronteira entre o ambiente externo (não mostrado) e a PHY de Ethernet 310. Subseqüentemente, a primeira etapa para o pacote de entrada 3 02 que recém cruzou a referida fronteira entre o ambiente externo e a PHY de Ethernet 310 é continuar para o MAC de Ethernet 320 através de um canal de pacote de recepção 312. Um percurso para o pacote de entrada 302 é mostrado com as setas 312, 322 e 332. Conforme também descrito, o tempo de partida Ttx de um pacote de saída 3 04 se refere ao instante em que o primeiro bit (ou designado) do pacote de saída 3 04 cruza a referida fronteira entre a PHY de Ethernet 310 e o ambiente externo. A última etapa para o pacote de saída 3 04 que está para cruzar a referida fronteira entre a PHY de Ethernet 310 e o ambiente externo é viajar através de um canal de pacote de transmissão 314 (um percurso para o pacote de saída 3 04 é mostrado com as setas 334, 324 e 314) . Combinados, o canal de pacote de recepção 312 e o canal de pacote de transmissão 314 são referidos aqui como o "canal de interface independente de mídia (MII)".
De modo importante, o sistema de PTS 300 ainda inclui uma unidade de derivação passiva 316 e um filtro de estimador de latência (LEF) 360. A unidade de derivação passiva 316 é um agente de timestamping de pacote configurado para monitorar o tráfego de rede fluindo através do canal de MII. Conforme cada pacote passa, a unidade de derivação passiva 316 analisa os dados fluindo através do canal de MII para determinar se o pacote de entrada 302 é de interesse para o aplicativo de NTP 340 (isto é, se o pacote de entrada 302 é um pacote de NTP). Se este for o caso, a unidade de derivação passiva 316 será configurada para disparar o relógio de hardware 350 para finalizar (isto é, gravar temporariamente) o tempo de chegada, Trx, conforme mostrado com uma seta 319. De modo similar, se a unidade de derivação passiva 316 detectar o pacote de saída 304 criado pelo aplicativo de NTP 340, a unidade de derivação passiva 316 disparará o relógio de hardware 350 para finalizar o tempo de partida, Ttx, conforme mostrado com uma seta 318. A funcionalidade de um agente de timestamping de pacote como a unidade de derivação passiva 316 que inclui a monitoração do tráfego de rede fluindo através do canal de MII e o disparo de uma finalização de tempo no relógio de hardware 350 pode ser implementada em hardware ou em software. Um exemplo de uma implementação de hardware pode ser encontrado na Patente U.S. N° 6.985.499, depositada em 17 de abril de 2001, e intitulada "Precise Network Time Transfer", a qual é incorporada aqui como referência. As pessoas versadas na técnica reconhecerão que, em modalidades diferentes, a derivação passiva 316 e o relógio de hardware 350 podem ser dispostos sobre o / no mesmo módulo ou sobre / em módulos diferentes.
O LEF 360 é configurado para a obtenção do tempo de partida finalizado, Ttx, a partir do relógio de hardware 350 e implementar as etapas de método descritas na Figura 5, para o cálculo de um termo de correção k. O termo de correção k é uma estimativa da latência de transmissão através do servidor de NTP de precisão que se pretende que considere os atrasos experimentados pelos pacotes de NTP enquanto viajam entre o aplicativo de NTP 340 e a PHY de Ethernet 310. Após cada intercâmbio de pacote de cliente / servidor de NTP, o LEF 360 atualiza o valor do termo de correção k para manutenção da melhor estimativa para o próximo atraso de transmissão. Usando o tempo de chegada finalizado, Trx, e o termo de correção mais recente k calculado pelo LEF 360, o sistema de PTS 300 implementa as etapas de método descritas na Figura 4, produzindo medições de tempo mais precisas e estáveis das estampas de tempo T2 e T3.
A Figura 4 estabelece um fluxograma de etapas de método implementadas pelo sistema de PTS 300 da Figura 3, de acordo com uma modalidade da presente invenção. Embora as etapas de método sejam descritas em conjunto com o sistema da Figura 3, as pessoas versadas na técnica entenderão que qualquer sistema que realize as etapas de método, em qualquer ordem, está no escopo da presente invenção.
O método começa na etapa 402, onde o sistema de PTS 300 inicializa o LEF 360 pela regulagem dos elementos no array de latências de transmissão para zero. Em modalidades alternativas, os elementos no array de latências de transmissão podem ser regulados para alguns outros valores predeterminados. Na etapa 404, a unidade de derivação passiva 316 determina se há um novo pacote de entrada 302 que seja um pacote de NTP. Se não houver nenhum pacote de NTP novo, então, o método prossegue para a etapa 405 em que o sistema de PTS 300 espera até o novo pacote chegar. A partir da etapa 405, o método retorna para a etapa 404.
Se, na etapa 404, a unidade de derivação passiva 316 determinar que um novo pacote de entrada 302 é um pacote de NTP7 então, o método prosseguirá para a etapa 406, onde a unidade de derivação passiva 316 disparará o relógio de hardware 350 para finalizar o tempo de chegada Trx. Conforme o pacote de entrada 302 atravessa o MAC de Ethernet 320 e os serviços de O/S 330, o método prossegue para a etapa 408, onde o pacote de entrada 302 é recebido no aplicativo de NTP 340. Uma vez que o aplicativo de NTP 340 reconheça que o pacote de entrada 302 chegou, o método prossegue para a etapa 410, onde o aplicativo de NTP 340 requisita o tempo de chegada finalizado, Trx, a partir do relógio de hardware 350, conforme mostrado na Figura 3 com a seta 342. Após o aplicativo de NTP 340 obter o tempo de chegada finalizado requisitado, Trx, conforme mostrado na Figura 3 com a seta 344, o método prossegue para a etapa 412. Na etapa 412, o aplicativo de NTP 340 insere a timestamp T2 com um valor igual a Trx no pacote de entrada 302. Note que esta abordagem de determinação da timestamp T2 é bastante diferente do método de operação no sistema de NTP típico 100, em que, mediante o envio do gatilho de timestamp 142 para o relógio de hardware 150, o aplicativo de NTP 140 recebe o valor de tempo atual em oposição ao valor de tempo representando o instante no passado em que o pacote de entrada 102 realmente chegou.
Na etapa 414, o aplicativo de NTP 340 cria um pacote de resposta para o pacote de entrada 302. Como o pacote de resposta ainda não foi transmitido, nenhuma informação de transmissão correspondente está disponível para o relógio de hardware 350. Na etapa 416, o aplicativo de NTP 340 requisita o tempo atual, Tcurrent, para o relógio de hardware 350, conforme mostrado na Figura 3 com a seta 34 6, e o método prossegue para a etapa 418. Na etapa 418, o aplicativo de NTP 340 requisita o termo de correção k a partir do LEF 360. Uma seta 362 na Figura 3 ilustra o LEF 360 enviando o termo de correção k para o aplicativo de NTP 340. Na etapa 420, o aplicativo de NTP 340 adiciona o termo de correção, o qual é uma estimativa da latência de transmissão através do servidor de NTP de precisão, ao valor de Tcurrent obtido a partir do relógio de hardware 3 50 e insere o resultado como a timestamp T3 no pacote de resposta. A timestamp T3 também é enviada para o LEF 360.
Na etapa 422, o aplicativo de NTP 340 coloca o pacote de resposta com a timestamp T3 na fila de saída como o pacote de saída 304. Conforme o pacote de saída 304 atravessa os serviços de O/S 330, o MAC de Ethernet 320 e é detectado pela unidade de derivação passiva 316, o método prossegue para a etapa 424. Na etapa 424, a unidade de derivação passiva 316 dispara o relógio de hardware 350 para finalizar o tempo de partida real Ttx. O método, então, prossegue para a etapa 426, onde o relógio de hardware 350 supre o valor do tempo de partida real, Ttx, para o LEF 360, conforme mostrado na Figura 3 com a seta 352. Por sua vez, na etapa 428, o LEF 360 implementa as etapas de método que são descritas em maiores detalhes na Figura 5, e calcula um valor atualizado para o termo de correção k. O método então retorna para a etapa 404, descrita acima.
A Figura 5 estabelece um fluxograma de etapas de método implementadas pelo LEF (filtro estimador de latência) 360 da Figura 3, de acordo com uma modalidade da presente invenção. De novo, embora as etapas de método sejam descritas em conjunto com o sistema da Figura 3, as pessoas versadas na técnica entenderão que qualquer sistema que realize as etapas de método, em qualquer ordem, está no escopo da presente invenção.
O LEF 360 é projetado para suavizar uma instabilidade na atualização do termo de correção. Isto é realizado mantendo-se um pequeno array de latências de transmissão com a entrada mais nova forçando a entrada mais antiga a sair do array. 0 array pode ser denotado como {μί, μί-1, μi- 2, ..., μί-N} / onde N+1 é o número de elementos no array. Em uma modalidade, o array pode conter apenas 2 elementos, em cujo caso N é igual a 1.
O método começa na etapa 502, onde, conforme descrito na etapa 402 da Figura 4, o sistema de PTS 300 inicializa o LEF 360 pela regulagem dos valores dos elementos no array de latências de transmissão para zero. Em modalidades alternativas, as variáveis no array de latências de transmissão podem ser reguladas para alguns outros valores predeterminados. Na etapa 504, o LEF 360 determina se há uma nova timestamp T3 provida pelo aplicativo de NTP 340.
Se não houver uma nova timestamp T3, então, o método prosseguirá para a etapa 505, onde o LEF 3 60 espera por uma certa quantidade de tempo. A partir da etapa 505, o método retorna para e tapa 504.
Se, na etapa 504, o LEF 360 determinar que há uma nova timestamp T3 (conforme mostrado na Figura 3 com uma seta 349), então, o método prosseguirá para a etapa 506, onde o LEF 360 descarta a timestamp antiga T3. O método então prossegue para a etapa 508, onde o LEF 360 carrega a nova timestamp T3 obtida a partir do aplicativo de NTP 34 0, bem como o valor do tempo de partida real, Ttx, provido pelo relógio de hardware 350. O método então prossegue para a etapa 510.
Na etapa 510, o LEF 360 executa as etapas de um algoritmo de LEF, de modo a classificar o array de latências de transmissão e escolher o valor mínimo como o próximo valor do termo de correção k. Em uma modalidade, usando-se as variáveis definidas acima, o algoritmo de LEF da etapa 510 é conforme se segue:
Etapa 1: <formula>formula see original document page 16</formula> (decrementa o array em um)
Etapa 2: <formula>formula see original document page 16</formula>(atualiza a latência de transmissão)
Etapa 3: <formula>formula see original document page 16</formula> (calcula o novo valor para o termo de correção).
Como resultado da execução das etapas do algoritmo de LEF, na etapa 512, o LEF 36 0 produz um valor atualizado para o termo de correção k, o qual representa uma estimativa da latência de transmissão através do servidor de NTP de precisão. O termo de correção atualizado k é armazenado e subseqüentemente usado no cálculo da próxima timestamp de transmissão T3 para o pacote de resposta, conforme descrito na Figura 4. As pessoas versadas na técnica reconhecerão que algoritmos alternativos para o cálculo da melhor estimativa do termo de correção k podem ser utilizados também, sem que se desvie do escopo básico da presente invenção. O algoritmo de LEF apresentado nesta modalidade constitui uma operação eficiente em termos computacionais. A partir da etapa 512, o método retorna para a etapa 502 descrita acima.
A Figura 6 é um diagrama conceituai de um servidor de NTP de precisão 600 configurado para a implementação de um ou mais aspectos da presente invenção. Conforme mostrado, o servidor de NTP de precisão 600 inclui, sem limitação, uma unidade de processamento central (CPU) 610, uma interface de rede 620 e o sistema de PTS 3 00, o qual ainda inclui o relógio de hardware 350. A interface de rede 620 comunica pacotes para o sistema de PTS 300, o qual, por sua vez, comunica-se com a CPU 610 e implementa as etapas de método descritas aqui para o estabelecimento das estampas de tempo de recepção e de transmissão T2 e T3.
A presente invenção permite que um servidor de NTP de precisão:
- Monitore o tráfego de rede através de um canal de MII, calcule a latência de transmissão através do servidor de NTP de precisão, insira uma timestamp de recepção
T2 em um pacote de NTP entrando com base em um tempo de chegada finalizado por um relógio de hardware, insira uma timestamp de transmissão T3 em um pacote de NTP de saída com base em uma estimativa para a latência de transmissão que se espera que o pacote de
NTP de saída experimente, e atualize uma estimativa da latência de transmissão após cada intercâmbio de pacote de cliente / servidor de NTP pela realização das etapas de:
o Detecção de um pacote de entrada a partir de um cliente de NTP de precisão imediatamente após o pacote de entrada cruzar a fronteira entre o ambiente externo e a camada física do sistema de serviço de timestamping de precisão (PTS);
o Disparo de uma finalização de tempo no relógio de hardware para temporariamente gravar o tempo de chegada do pacote de entrada; o Recuperação do tempo de chegada finalizado a partir do relógio de hardware e inserção de uma timestamp de recepção T2 igual ao tempo de chegada finalizado no pacote de entrada; o Requisição do tempo atual a partir do relógio de hardware e da estimativa mais recente da latência de transmissão a partir de um filtro estimador de latência, e inserção de uma timestamp de transmissão T3 igual à soma do tempo atual e da estimativa mais recente da latência de transmissão no pacote de saída, antes do pacote de saída realmente cruzar a fronteira entre a camada física do sistema de PTS e o ambiente externo;
o Detecção de um pacote de saída imediatamente antes do pacote de saída cruzar a fronteira entre a camada física e o ambiente externo; o Disparo de uma finalização de tempo no relógio de hardware para temporariamente gravar o tempo de partida do pacote de saída; o Atualização da estimativa da latência de transmissão pelo cálculo do desvio entre o valor de timestamp de transmissão calculado por software e a timestamp de transmissão medida real e filtração da diferença para escolha do valor mínimo da latência de transmissão como a próxima estimativa da latência de transmissão; Proveja medidas mais acuradas e estáveis das transições dos pacotes de NTP para e para fora do servidor de NTP de precisão, se comparado com os métodos da técnica anterior.
Uma vantagem dos sistemas e métodos mostrados é que um controle significativamente melhor da função de timestamping pode ser implementado nos servidores de NTP existentes, sem o rico de introdução de incompatibilidades de entrelaçamento com outros servidores e clientes que estejam em conformidade com os padrões de NTP atuais. 0 sistema de serviço de timestamping de precisão (PTS) mostrado inclui um agente de timestamping de pacote implementado em hardware e configurado para reconhecer pacotes de NTP. O sistema de PTS mostrado ainda inclui um filtro estimador de latência configurado para calcular uma estimativa de latência de transmissão através de várias camadas de software em servidores de NTP. De forma importante, os métodos mostrados incluem etapas que utilizam o agente de timestamping de pacote e o filtro estimador de latência de uma maneira que retém a compatibilidade com os padrões de NTP atuais. Desta forma, o tempo de chegada e o tempo de partida são detectados e registrados por hardware, desse modo se obtendo um alto grau de precisão, e a incerteza associada aos drivers de dispositivo, às pilhas de rede, ao sistema operacional e assim por diante é evitada. Como resultado, estampas de tempo de servidor de NTP mais acuradas e estáveis são providas para os clientes de NTP.
Uma modalidade da presente invenção é implementada como um produto de programa para uso com um sistema de computador. 0(s) programa(s) do produto de programa define(m) funções das modalidades (incluindo os métodos descritos aqui) e podem estar contidos em uma variedade de meios de armazenamento que podem ser lidos em computador. Os meios de armazenamento que podem ser lidos em computador ilustrativos incluem, mas não estão limitados a: (i) meios de armazenamento que não podem ser escritos (por exemplo, dispositivos de memória apenas de leitura em um computador, tais como discos de CD-ROM que podem ser lidos por uma unidade de CD-ROM) em que uma informação é permanentemente armazenada; (ii) meios de armazenamento graváveis (por exemplo, discos flexíveis em uma unidade de disquete ou uma unidade de disco rígido) em que uma informação alterável é armazenada. Esses meios de armazenamento que podem ser lidos em computador, quando portando instruções que podem ser lidas em computador que dirigem as funções da presente invenção, são modalidades da presente invenção.
Outros meios incluem meios de comunicações através dos quais uma informação é portada para um computador, tal como através de uma rede de computadores ou de telefonia, incluindo redes de comunicações sem fio. A última modalidade especificamente inclui a transmissão de uma informação para a / a partir da Internet e de outras redes. Esses meios de comunicações, quando portando instruções que podem ser lidas em computador que dirigem as funções da presente invenção, são modalidades da presente invenção.
Embora o precedente seja dirigido a modalidades da presente invenção, outras modalidades e adicionais da invenção podem ser divisadas, sem que se desvie do escopo básico da mesma.
Claims (20)
1. Método para o estabelecimento de uma timestamp de transmissão a ser inserida em um pacote de saída por um servidor de protocolo de tempo de rede (NTP) , o método caracterizado pelo fato de compreender: a inicialização de um filtro estimador de latência (LEF); a criação de um pacote de saída; a requisição do tempo atual a partir de um relógio de hardware dentro do servidor de NTP; a requisição de um termo de correção a partir do LEF, onde o termo de correção é uma estimativa de uma latência de transmissão associada ao pacote de saída atravessando várias camadas de software, antes de cruzar uma fronteira com o ambiente externo; a inserção de uma soma do tempo atual e do termo de correção no pacote de saída como a timestamp de transmissão; a provisão da timestamp de transmissão para o LEF; a colocação do pacote de saída com a timestamp de transmissão em uma fila de saída; a monitoração do tráfego de rede fluindo através de um canal de interface independente de mídia (MII) para a detecção do pacote de saída; o disparo do relógio de hardware para finalizar um tempo de partida do pacote de saída detectado; a provisão do tempo de partida finalizado para o LEF; a realização das etapas de um algoritmo de LEF para atualização do termo de correção pelo cálculo de um desvio entre a timestamp de transmissão e o tempo de partida finalizado para 9- obtenção de uma timestamp de transmissão mais acurada no próximo pacote de saída; o armazenamento do termo de correção atualizado e o uso do termo de correção atualizado para a inserção da timestamp de transmissão em um próximo pacote de saída.
2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de o LEF ser inicializado pela regulagem de elementos de uma array de latências de transmissão iguais a zero ou pela regulagem dos elementos do array de latências de transmissão iguais a valores predeterminados.
3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de o pacote de saída ser criado como uma resposta a um pacote de entrada a partir de um cliente de NTP.
4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de o algoritmo de LEF incluir o seguinte: Etapa 1: mover os elementos de uma array de latências de transmissão para baixo em um: μi-1 = μi. Etapa 2: atualizar a latência de transmissão mais recente: μi = Ttx - T3 + k. Etapa 3: calcular o novo valor para o termo de correção: k = min (μi-1, μi).
5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de incluir outras etapas para o estabelecimento de uma timestamp de recepção a ser inserida em um pacote de entrada pelo servidor de NTP, as etapas compreendendo: a monitoração do tráfego de rede fluindo através do canal de MII para a detecção de um pacote de entrada a partir de um cliente de NTP; o disparo do relógio de hardware para finalizar um tempo de chegada do pacote de entrada detectado; a inserção do tempo de chegada finalizado no pacote de entrada como a timestamp de recepção.
6. Sistema de serviço de timestamping de precisão (PTS) configurado para a inserção de uma timestamp de transmissão em um pacote de saída, o sistema caracterizado pelo fato de compreender: uma camada física associada a uma PHY de Ethernet; um controlador de acesso a mídia (MAC) de Ethernet; um canal de interface independente de mídia (MII) conectando a PHY de Ethernet e o MAC de Ethernet; serviços de sistema operacional (O/S); um relógio de hardware configurado para prover um tempo atual e para finalizar um tempo de partida do pacote de saída; um filtro estimador de latência (LEF) configurado para ser inicializado e realizar etapas de um algoritmo de LEF para o armazenamento e a atualização de um termo de correção pelo cálculo de um desvio entre a timestamp de transmissão e um tempo de partida finalizado pelo relógio de hardware e para a obtenção de uma timestamp de transmissão mais acurada em um próximo pacote de saída; um aplicativo de protocolo de tempo de rede (NTP) configurado para: criar o pacote de saída, requisitar o tempo atual a partir de um relógio de hardware, requisitar o termo de correção a partir do LEF, onde o termo de correção é uma estimativa de uma latência de transmissão associada ao pacote de saída atravessando várias camadas de software, antes de cruzar uma fronteira entre a camada física e o ambiente externo, inserir uma soma do tempo atual e do termo de correção no pacote de saída como a timestamp de transmissão, prover a timestamp de transmissão para o LEF, colocar o pacote de saída com a timestamp de transmissão em uma fila de saída, uma unidade de derivação passiva configurada para: monitorar o tráfego de rede fluindo através do canal de MII para a detecção do pacote de saída, disparar o relógio de hardware para finalizar o tempo de partida do pacote de saída detectado, prover o tempo de partida finalizado para o LEF.
7. Sistema, de acordo com a reivindicação 6, caracterizado pelo fato de o LEF ser inicializado pela regulagem de elementos de uma array de latências de transmissão iguais a zero ou pela regulagem dos elementos do array de latências de transmissão iguais a valores predeterminados.
8. Sistema, de acordo com a reivindicação 6, caracterizado pelo fato de o pacote de saída ser criado como uma resposta a um pacote de entrada a partir de um cliente de NTP.
9. Sistema, de acordo com a reivindicação 6, caracterizado pelo fato de o algoritmo de LEF incluir o seguinte: Etapa 1: mover os elementos de uma array de latências de transmissão para baixo em um: <formula>formula see original document page 25</formula> Etapa 2: atualizar a latência de transmissão mais recente: <formula>formula see original document page 25</formula> Etapa 3: calcular o novo valor para o termo de correção: <formula>formula see original document page 25</formula>
10. Sistema, de acordo com a reivindicação 6, caracterizado pelo fato de incluir outras etapas para o estabelecimento de uma timestamp de recepção a ser inserida em um pacote de entrada pelo sistema de PTS, as etapas compreendendo: a monitoração do tráfego de rede fluindo através do canal de MII para a detecção de um pacote de entrada a partir de um cliente de NTP; o disparo do relógio de hardware para finalizar um tempo de chegada do pacote de entrada detectado; a inserção do tempo de chegada finalizado no pacote de entrada como a timestamp de recepção.
11. Servidor de protocolo de tempo de rede de precisão (NTP) configurado para a inserção de uma timestamp de transmissão em um pacote de saída, o servidor caracterizado pelo fato de compreender: uma unidade de processamento central (CPU); uma interface de rede; um sistema de serviço de timestamping de precisão (PTS) que tem um relógio de hardware configurado para prover um tempo atual e para finalizar um tempo de partida do pacote de saída, onde o sistema de PTS inclui: uma camada física associada a uma PHY de Ethernet; um controlador de acesso a mídia (MAC) de Ethernet; um canal de interface independente de mídia (MII) conectando a PHY de Ethernet e o MAC de Ethernet; serviços de sistema operacional (O/S); um filtro estimador de latência (LEF) configurado para ser inicializado e realizar etapas de um algoritmo de LEF para o armazenamento e a atualização de um teimo de correção pelo cálculo de um desvio entre a timestamp de transmissão e um tempo de partida finalizado pelo relógio de hardware e para a obtenção de uma timestamp de transmissão mais acurada em um próximo pacote de saída; um aplicativo de protocolo de tempo de rede (NTP) configurado para: criar o pacote de saída, requisitar o tempo atual a partir de um relógio de hardware, requisitar o termo de correção a partir do LEF, onde o termo de correção é uma estimativa de uma latência de transmissão associada ao pacote de saída atravessando várias camadas de software, antes de cruzar uma fronteira entre a camada física e o ambiente externo, inserir uma soma do tempo atual e do termo de correção no pacote de saída como a timestamp de transmissão, prover a timestamp de transmissão para o LEF, colocar o pacote de saída com a timestamp de transmissão em uma fila de saída, uma unidade de derivação passiva configurada para: monitorar o tráfego de rede fluindo através do canal de MII para a detecção do pacote de saída, disparar o relógio de hardware para finalizar o tempo de partida do pacote de saída detectado, prover o tempo de partida finalizado para o LEF.
12. Sistema, de acordo com a reivindicação 11, caracterizado pelo fato de o LEF ser inicializado pela regulagem de elementos de uma array de latências de transmissão iguais a zero ou pela regulagem dos elementos do array de latências de transmissão iguais a valores predeterminados.
13. Sistema, de acordo com a reivindicação 11, caracterizado pelo fato de o pacote de saída ser criado como uma resposta a um pacote de entrada a partir de um cliente de NTP.
14. Sistema, de acordo com a reivindicação 11, caracterizado pelo fato de o algoritmo de LEF incluir o seguinte: Etapa 1: mover os elementos de uma array de latências de transmissão para baixo em um: μi-1 = μi. Etapa 2: atualizar a latência de transmissão mais recente: μι = Ttx - T3 + k. Etapa 3: calcular o novo valor para o termo de correção: k = min (μi-1, μi) .
15. Sistema, de acordo com a reivindicação 11, caracterizado pelo fato de incluir outras etapas para o estabelecimento de uma timestamp de recepção a ser inserida em um pacote de entrada pelo sistema de PTS, as etapas compreendendo: a monitoração do tráfego de rede fluindo através do canal de MII para a detecção de um pacote de entrada a partir de um cliente de NTP; o disparo do relógio de hardware para finalizar um tempo de chegada do pacote de entrada detectado; a inserção do tempo de chegada finalizado no pacote de entrada como a timestamp de recepção.
16. Meio de armazenamento que pode ser lido em computador, caracterizado pelo fato de conter instruções para o controle de um servidor de protocolo de tempo de rede (NTP) para a realização de etapas de: inicialização de um filtro estimador de latência (LEF); criação de um pacote de saída; requisição do tempo atual a partir de um relógio de hardware dentro do servidor de NTP7- requisição de um termo de correção a partir do LEF, onde o termo de correção é uma estimativa de uma latência de transmissão associada ao pacote de saída atravessando várias camadas de software, antes de cruzar uma fronteira com o ambiente externo; inserção de uma soma do tempo atual e do termo de correção no pacote de saída como a timestamp de transmissão; provisão da timestamp de transmissão para o LEF; colocação do pacote de saída com a timestamp de transmissão em uma fila de saída; monitoração do tráfego de rede fluindo através de um canal de interface independente de mídia (MII) para a detecção do pacote de saída; disparo do relógio de hardware para finalizar um tempo de partida do pacote de saída detectado,- provisão do tempo de partida finalizado para o LEF; realização das etapas de um algoritmo de LEF para atualização do termo de correção pelo cálculo de um desvio entre a timestamp de transmissão e o tempo de partida finalizado para a obtenção de uma timestamp de transmissão mais acurada no próximo pacote de saída; armazenamento do termo de correção atualizado e o uso do termo de correção atualizado para a inserção da timestamp de transmissão em um próximo pacote de saída.
17. Sistema, de acordo com a reivindicação 16, caracterizado pelo fato de o LEF ser inicializado pela regulagem de elementos de uma array de latências de transmissão iguais a zero ou pela regulagem dos elementos do array de latências de transmissão iguais a valores predeterminados.
18. Sistema, de acordo com a reivindicação 16, caracterizado pelo fato de o pacote de saída ser criado como uma resposta a um pacote de entrada a partir de um cliente de NTP.
19. Sistema, de acordo com a reivindicação 16, caracterizado pelo fato de o algoritmo de LEF incluir o seguinte: Etapa 1: mover os elementos de uma array de latências de transmissão para baixo em um: μί-1 = Pi- Etapa 2: atualizar a latência de transmissão mais recente: μί = Ttx - T3 + k. Etapa 3: calcular o novo valor para o termo de correção: k = min (μί-1, μi) .
20. Sistema, de acordo com a reivindicação 16, caracterizado pelo fato de incluir outras etapas para o estabelecimento de uma timestamp de recepção a ser inserida em um pacote de entrada pelo sistema de PTS, as etapas compreendendo: a monitoração do tráfego de rede fluindo através do canal de MII para a detecção de um pacote de entrada a partir de um cliente de NTP; o disparo do relógio de hardware para finalizar um tempo de chegada do pacote de entrada detectado; a inserção do tempo de chegada finalizado no pacote de entrada como a timestamp de recepção.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US80202306P | 2006-05-19 | 2006-05-19 | |
| US60/802.023 | 2006-05-19 | ||
| PCT/US2007/069066 WO2007137085A2 (en) | 2006-05-19 | 2007-05-16 | Network time protocol precision timestamping service |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| BRPI0711770A2 true BRPI0711770A2 (pt) | 2011-12-13 |
Family
ID=38723995
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BRPI0711770-1A BRPI0711770A2 (pt) | 2006-05-19 | 2007-05-16 | serviço de timestamping de precisão de protocolo de tempo de rede |
Country Status (11)
| Country | Link |
|---|---|
| US (1) | US8451867B2 (pt) |
| EP (1) | EP2025104A4 (pt) |
| JP (1) | JP2009538101A (pt) |
| KR (1) | KR20090024170A (pt) |
| CN (1) | CN101449520B (pt) |
| AU (1) | AU2007253824A1 (pt) |
| BR (1) | BRPI0711770A2 (pt) |
| CA (1) | CA2652594A1 (pt) |
| MX (1) | MX2008014768A (pt) |
| RU (1) | RU2008150317A (pt) |
| WO (1) | WO2007137085A2 (pt) |
Families Citing this family (54)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9112632B2 (en) * | 2008-01-25 | 2015-08-18 | Cisco Technology, Inc. | Supporting efficient and accurate sync/followup timestamps |
| FR2928765B1 (fr) * | 2008-03-13 | 2011-12-30 | Suez Environnement | Systeme de transmission de donnees a partir d'un capteur de mesure pour telereleve avec horodatage. |
| US8327028B1 (en) * | 2008-09-22 | 2012-12-04 | Symantec Corporation | Method and apparatus for providing time synchronization in a data protection system |
| US9727473B2 (en) * | 2008-09-30 | 2017-08-08 | Intel Corporation | Methods to communicate a timestamp to a storage system |
| US8169999B2 (en) * | 2009-01-16 | 2012-05-01 | Broadcom Corporation | Method and system for preserving content timing across femtocell interfaces via timestamp insertion |
| US8107502B2 (en) * | 2009-09-11 | 2012-01-31 | Symmetricom, Inc. | Method and apparatus for monitoring packet networks |
| US8571068B2 (en) * | 2010-01-05 | 2013-10-29 | Futurewei Technologies, Inc. | Network timing distribution and synchronization using virtual network delays |
| US8644352B1 (en) * | 2010-03-12 | 2014-02-04 | Marvell International Ltd. | System and method for accurate time sampling in presence of output delay |
| US9319335B1 (en) | 2010-12-07 | 2016-04-19 | Pluribus Networks, Inc. | Distributed operating system for a layer 2 fabric |
| US8891543B1 (en) | 2011-05-23 | 2014-11-18 | Pluribus Networks Inc. | Method and system for processing packets in a network device |
| US9154445B2 (en) | 2010-05-03 | 2015-10-06 | Pluribus Networks Inc. | Servers, switches, and systems with virtual interface to external network connecting hardware and integrated networking driver |
| US8767752B1 (en) * | 2010-05-03 | 2014-07-01 | Pluribus Networks, Inc. | Method and system for resource coherency and analysis in a network |
| US9160668B2 (en) | 2010-05-03 | 2015-10-13 | Pluribus Networks Inc. | Servers, switches, and systems with switching module implementing a distributed network operating system |
| US9300576B2 (en) | 2010-05-03 | 2016-03-29 | Pluribus Networks Inc. | Methods, systems, and fabrics implementing a distributed network operating system |
| US9306849B2 (en) | 2010-05-03 | 2016-04-05 | Pluribus Networks, Inc. | Methods and systems for managing distribute media access control address tables |
| US9304782B2 (en) | 2010-05-03 | 2016-04-05 | Pluribus Networks, Inc. | Network switch, systems, and servers implementing boot image delivery |
| KR101702562B1 (ko) | 2010-06-18 | 2017-02-03 | 삼성전자 주식회사 | 멀티미디어 스트림 파일의 저장 파일 포맷, 저장 방법 및 이를 이용한 클라이언트 장치 |
| US9042366B2 (en) * | 2010-09-30 | 2015-05-26 | Vitesse Semiconductor Corporation | Timestamp predictor for packets over a synchronous protocol |
| CN101986590A (zh) * | 2010-11-03 | 2011-03-16 | 烟台持久钟表集团有限公司 | 子钟同步时间精确性检测装置及检测方法 |
| US8675689B2 (en) * | 2011-02-15 | 2014-03-18 | General Electric Company | Method of time synchronization of free running nodes in an avionics network |
| CN103051438A (zh) * | 2011-10-11 | 2013-04-17 | 康佳集团股份有限公司 | 一种时间同步方法和时间同步装置 |
| CN102571911B (zh) * | 2011-11-17 | 2014-11-19 | 电信科学技术第五研究所 | 一种基于ntp协议的计算机时间同步及监控方法 |
| WO2013078100A1 (en) * | 2011-11-23 | 2013-05-30 | Vitesse Semiconductor Corporation | Packet-based timing measurement |
| US9686169B2 (en) * | 2012-07-02 | 2017-06-20 | Ixia | Real-time highly accurate network latency measurement with low generated traffic or data requirements |
| US10015688B2 (en) * | 2012-12-17 | 2018-07-03 | Telefonaktiebolaget L M Ericsson (Publ) | Technique for monitoring data traffic |
| DE112012005356T5 (de) | 2012-12-18 | 2014-10-02 | Intel Corporation | Techniken in Verbindung mit Server-Transaktionslatenzinformationen |
| US9853949B1 (en) | 2013-04-19 | 2017-12-26 | Amazon Technologies, Inc. | Secure time service |
| CN104113517A (zh) * | 2013-04-22 | 2014-10-22 | 华为技术有限公司 | 时间戳生成方法、装置及系统 |
| US10169171B2 (en) * | 2013-05-13 | 2019-01-01 | Nxp Usa, Inc. | Method and apparatus for enabling temporal alignment of debug information |
| US20160006526A1 (en) * | 2014-07-03 | 2016-01-07 | Qualcomm Incorporated | Systems and methods of network clock comparison |
| CN104601307B (zh) * | 2015-01-15 | 2018-07-24 | 北京奥普维尔科技有限公司 | 基于fpga万兆以太网时间戳的添加系统及方法 |
| CN104639399B (zh) * | 2015-02-03 | 2018-10-09 | 新华三技术有限公司 | 多主时间服务器检测方法和装置 |
| RO131470A2 (ro) | 2015-04-10 | 2016-10-28 | Ixia, A California Corporation | Metode, sisteme şi suport citibil pe calculator pentru măsurarea întârzierii unei linii de comunicaţii unidirecţionale |
| US10019333B2 (en) | 2015-04-16 | 2018-07-10 | Keysight Technologies Singapore (Holdings) Pte. Ltd. | Methods, systems, and computer readable media for emulating network devices with different clocks |
| US9736804B2 (en) | 2015-04-16 | 2017-08-15 | Ixia | Methods, systems, and computer readable media for synchronizing timing among network interface cards (NICS) in a network equipment test device |
| RO131471A2 (ro) | 2015-04-21 | 2016-10-28 | Ixia, A California Corporation | Metode, sisteme şi suport citibil pe calculator pentru testarea calităţii tactului recuperat |
| KR101665924B1 (ko) | 2015-08-04 | 2016-10-13 | 주식회사 이노와이어리스 | NTP(network time protocol) 타임 오프셋을 이용한 주파수 오차 추정 시스템 |
| US9813226B2 (en) | 2015-08-05 | 2017-11-07 | Ixia | Modeling a clock |
| US9614861B2 (en) | 2015-08-26 | 2017-04-04 | Microsoft Technology Licensing, Llc | Monitoring the life cycle of a computer network connection |
| US9800595B2 (en) | 2015-09-21 | 2017-10-24 | Ixia | Methods, systems, and computer readable media for detecting physical link intrusions |
| US11799713B2 (en) * | 2015-09-22 | 2023-10-24 | Parrable Inc. | Timestamp-based association of identifiers |
| CN106230540B (zh) * | 2016-06-30 | 2019-03-26 | 电信科学技术第五研究所有限公司 | 高精度ntp报文接收方法和发送方法 |
| US10609054B2 (en) | 2017-04-07 | 2020-03-31 | Keysight Technologies Singapore (Sales) Pte. Ltd. | Methods, systems, and computer readable media for monitoring, adjusting, and utilizing latency associated with accessing distributed computing resources |
| US10425321B2 (en) | 2017-04-25 | 2019-09-24 | Keysight Technologies Singapore (Sales) Pte. Ltd. | Methods, systems, and computer readable media for testing time sensitive network (TSN) elements |
| US10892972B2 (en) | 2017-04-26 | 2021-01-12 | Microsemi Storage Solutions, Inc. | Scheduled network setup test method and system |
| US10742782B2 (en) * | 2017-05-26 | 2020-08-11 | Xilinx, Inc. | Time stamping network device |
| CN109699199B (zh) * | 2017-08-23 | 2021-05-14 | 华为技术有限公司 | 一种报文处理的方法和网络设备 |
| US10868828B2 (en) * | 2018-03-19 | 2020-12-15 | Fortinet, Inc. | Mitigation of NTP amplification and reflection based DDoS attacks |
| US11927950B2 (en) * | 2018-07-27 | 2024-03-12 | Rockwell Automation Technologies, Inc. | System and method of communicating safety data over high availability industrial control systems |
| US10965392B2 (en) | 2019-01-25 | 2021-03-30 | Keysight Technologies, Inc. | Active network tap supporting time sensitive network (TSN) standards |
| US11563768B2 (en) | 2019-01-31 | 2023-01-24 | Keysight Technologies, Inc. | Methods, systems, and computer readable media for detecting and mitigating effects of timing attacks in time sensitive networks |
| US11689440B2 (en) * | 2019-02-06 | 2023-06-27 | Marvell Israel (M.I.S.L) Ltd. | Method and apparatus for transmit time timestamping |
| EP3873009A1 (de) * | 2020-02-28 | 2021-09-01 | Siemens Aktiengesellschaft | Verfahren zur synchronisation von steuerungsanwendungen über ein kommunikationsnetz zur übermittlung zeitkritischer daten, netzinfrastrukturgerät und kommunikationsendgerät |
| CN115022010B (zh) * | 2022-05-30 | 2023-12-15 | 南京尤尼泰信息科技有限公司 | 一种ntp客户端智能抗欺骗方法及系统 |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4673979A (en) * | 1984-06-15 | 1987-06-16 | Matsushita Electric Industrial Co., Ltd. | Digital data reproducing system |
| US20050160272A1 (en) * | 1999-10-28 | 2005-07-21 | Timecertain, Llc | System and method for providing trusted time in content of digital data files |
| US6985499B2 (en) * | 2000-04-20 | 2006-01-10 | Symmetricom, Inc. | Precise network time transfer |
| US7058020B2 (en) * | 2000-05-18 | 2006-06-06 | Brix Networks, Inc. | Hardware time stamping and registration of packetized data method and system |
| US6535057B2 (en) * | 2000-05-29 | 2003-03-18 | Stmicroelectronics Ltd. | Programmable glitch filter |
| US6868069B2 (en) * | 2001-01-16 | 2005-03-15 | Networks Associates Technology, Inc. | Method and apparatus for passively calculating latency for a network appliance |
| CA2363396A1 (en) * | 2001-11-21 | 2003-05-21 | Handshake Interactive Technologies Inc | Hard real time control center |
| US7151945B2 (en) * | 2002-03-29 | 2006-12-19 | Cisco Systems Wireless Networking (Australia) Pty Limited | Method and apparatus for clock synchronization in a wireless network |
| KR100431700B1 (ko) * | 2002-08-16 | 2004-05-17 | 엘지전자 주식회사 | 에스지에스엔과 지지에스엔간의 시각 동기화 시스템 및 방법 |
| US7372875B2 (en) * | 2002-09-30 | 2008-05-13 | Lucent Technologies Inc. | Systems and methods for synchronization in asynchronous transport networks |
| US7590151B2 (en) * | 2004-02-09 | 2009-09-15 | Semtech Corporation | Method and apparatus for aligning time references when separated by an unreliable data packet network |
| US20060056377A1 (en) * | 2004-09-16 | 2006-03-16 | Chiung-Hsien Wu | Power-saving method for a wlan station |
| US7409022B2 (en) * | 2004-10-01 | 2008-08-05 | Mitsubishi Electric Research Laboratories, Inc. | Synchronizing clocks in wireless personal area networks |
| US7603137B1 (en) * | 2005-01-27 | 2009-10-13 | Verizon Corporate Services Group Inc. & BBN Technologies Corp. | Hybrid communications link |
| US20070223477A1 (en) * | 2006-03-27 | 2007-09-27 | Eidson John C | Packet recognizer with hardware/software tradeoff |
-
2007
- 2007-05-16 AU AU2007253824A patent/AU2007253824A1/en not_active Abandoned
- 2007-05-16 CA CA002652594A patent/CA2652594A1/en not_active Abandoned
- 2007-05-16 EP EP07811895A patent/EP2025104A4/en not_active Withdrawn
- 2007-05-16 RU RU2008150317/09A patent/RU2008150317A/ru not_active Application Discontinuation
- 2007-05-16 KR KR1020087030996A patent/KR20090024170A/ko not_active Application Discontinuation
- 2007-05-16 MX MX2008014768A patent/MX2008014768A/es not_active Application Discontinuation
- 2007-05-16 BR BRPI0711770-1A patent/BRPI0711770A2/pt not_active IP Right Cessation
- 2007-05-16 WO PCT/US2007/069066 patent/WO2007137085A2/en active Application Filing
- 2007-05-16 US US11/749,666 patent/US8451867B2/en active Active
- 2007-05-16 CN CN2007800182578A patent/CN101449520B/zh not_active Expired - Fee Related
- 2007-05-16 JP JP2009512223A patent/JP2009538101A/ja active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| JP2009538101A (ja) | 2009-10-29 |
| RU2008150317A (ru) | 2010-06-27 |
| AU2007253824A1 (en) | 2007-11-29 |
| US8451867B2 (en) | 2013-05-28 |
| CA2652594A1 (en) | 2007-11-29 |
| KR20090024170A (ko) | 2009-03-06 |
| EP2025104A4 (en) | 2013-04-03 |
| MX2008014768A (es) | 2009-04-16 |
| CN101449520B (zh) | 2012-05-30 |
| EP2025104A2 (en) | 2009-02-18 |
| CN101449520A (zh) | 2009-06-03 |
| WO2007137085A3 (en) | 2008-01-24 |
| US20070268938A1 (en) | 2007-11-22 |
| WO2007137085A2 (en) | 2007-11-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| BRPI0711770A2 (pt) | serviço de timestamping de precisão de protocolo de tempo de rede | |
| US10320506B2 (en) | System for establishing and maintaining a clock reference indicating one-way latency in a data network | |
| US8879586B2 (en) | Inband timestamping | |
| US7643430B2 (en) | Methods and apparatus for determining reverse path delay | |
| US10142088B2 (en) | Network clock skew estimation and calibration | |
| US7876791B2 (en) | Synchronizing apparatus and method in packet network | |
| CN101675614A (zh) | 使网络组件的时钟与另外的网络组件的时钟同步的方法及其网络组件 | |
| EP2490357A2 (en) | A method of time synchronization of free running nodes in an avionics network | |
| CN102197611B (zh) | 用于分组网络同步的方法和设备 | |
| US9401856B2 (en) | Latency monitoring function | |
| US11916660B2 (en) | TSN operation management system with time capture location protocol | |
| CN112039621B (zh) | 一种时间同步方法和系统 | |
| WO2017152564A1 (zh) | 一种链路负载均衡方法及装置 | |
| KR20190072745A (ko) | 안정적인 네트워크 기반 시간동기화 방법 | |
| US11606156B1 (en) | Clock synchronization | |
| Kim et al. | One-way delay estimation without clock sychronization | |
| EP3824573A1 (en) | Peer-to-peer transparent clocks and methods of estimating skew in peer-to-peer transparent clocks | |
| CN113890841B (zh) | 高效的大规模单向延迟测量方法及装置 | |
| Hadzialic et al. | Impact of frequency synchronization on QoS in IP based networks | |
| Nicolau et al. | Flat soft-synchronization for gigabit ethernet | |
| Kima et al. | One-way delay estimation without clock sychronization |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B08F | Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette] |
Free format text: REFERENTE AS 4A E 5A ANUIDADES. |
|
| B08K | Patent lapsed as no evidence of payment of the annual fee has been furnished to inpi [chapter 8.11 patent gazette] |
Free format text: NAO APRESENTADA A GUIA DE CUMPRIMENTO DE EXIGENCIA. REFERENTE AS 4A E 5A ANUIDADES. |