Почему root_delay NTP так сильно отличается от моего измеренного туда-обратно? - PullRequest
0 голосов
/ 05 июня 2018

При получении пакета протокола сетевого времени (NTP версии 4, см. здесь ):

from contextlib import closing
from socket import socket, AF_INET, SOCK_DGRAM
import struct, time

start = time.time()
with closing(socket(AF_INET, SOCK_DGRAM)) as s:
    s.sendto('\x23' + 47 * '\0', ('pool.ntp.org', 123))       # NTP v4, see RFC 5905
    msg, address = s.recvfrom(1024)
now = time.time()

Я обычно получаю время туда-обратно now - start около 40 миллисекунд.

Однако, с

format = "!4b4h9I"
unpacked = struct.unpack(format, msg[0:struct.calcsize(format)]) 
livnmode, stratum, poll, precision = unpacked[0:4]
print 'root_delay',  unpacked[4] + float(unpacked[5]) / 2**16                             # https://tools.ietf.org/html/rfc5905#page-13
print 'root_dispersion', unpacked[6] + float(unpacked[7]) / 2**16
print 'ref_id', unpacked[8]
print 'ref_timestamp  %.3f' % (unpacked[9] + float(unpacked[10]) / 2**32 - 2208988800L)
print 'orig_timestamp %.3f' % (unpacked[11] + float(unpacked[12]) / 2**32)
print 'recv_timestamp %.3f' % (unpacked[13] + float(unpacked[14]) / 2**32 - 2208988800L)
print 'tx_timestamp %.3f' % (unpacked[15] + float(unpacked[16]) / 2**32 - 2208988800L 

я получаю root_delay 0,00056 секунд, что вряд ли будет правдой!(Я не думаю, что у меня пинг 0,5 мс до сервера времени, время туда-обратно ... это действительно слишком мало)

Вопрос: как именно root_delay измеряется в протоколе NTP?

Примечание:

  • RFC 5905 состояния:

    Root Delay (rootdelay): Total round-trip delay to the reference
    clock, in NTP short format.
    
  • больше я перезапускаю скрипт, кажется, что root_delay уменьшается (даже если время RTC моего локального компьютера не обновляется моим скриптом Python ... так что это странно ...)

  • Мой анализ root_delay кажется правильным, см. https://tools.ietf.org/html/rfc5905#page-19:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |LI | VN  |Mode |    Stratum     |     Poll      |  Precision   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Root Delay                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Root Dispersion                       |
    ...
    

    и https://tools.ietf.org/html/rfc5905#page-13:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Seconds              |           Fraction            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
                         NTP Short Format
    
  • Я не используюntplib, который, похоже, имеет другой root_delay разбор (но не в соответствии с https://tools.ietf.org/html/rfc5905#page-13?)

1 Ответ

0 голосов
/ 18 октября 2018

Вы просто запрашиваете удаленный «сервер» как «клиента», отправляемые им root_delay и root_dispersion - это значения сервера относительно источника Stratum-0.

Вы должны выполнить свою собственную математику, еслиВы хотите выяснить свою собственную root_delay & root_dispersion.

Вы можете использовать данные временной метки, которые вам нужны, чтобы вычислить обратную передачу для пакета, добавить значение, которое сервер отправил как его root_delay, и теперь у вас естьВАША root_delay.

...