Аберрантные отрицательные значения задержки на флоте LAN Raspberry Pi [закрыто]

Я пытаюсь получить точные замеры задержки от флота из Raspberry Pi 5, которые отправляют сигналы ускорения мыши на WebSocket сервер по проводной сети LAN. Я поставил одну временную метку на каждую Raspberry Pi, когда она отправляет сообщение, как показано (с использованием python3):

async def simulate_mouse_events(queue):
[...]
    async def generate_events(device_name):
    [...]
    "timestamp_rasp": int(round(time.time() * 1000))

и одну временную метку на машине, где расположены как WebSocket сервер, так и HTTP клиент (используемый для отображения симулированных указателей мыши), с помощью JavaScript :

   data.forEach((instruction, index) => {
      timestamp_client = Date.now()
      const supposedLatency = timestamp_client - instruction.timestamp_rasp
})

Но я получаю ненормальные показания задержки (менее 0 миллисекунд), как таковые :

искаженные результаты задержки
(avgP – средняя задержка, maxP – худшая задержка, зафиксированная в этой сессии)

И действительно, временные метки из моей JavaScript консоли на клиенте абсурдны (временная метка от клиента меньше, чем на Raspberry, несмотря на то, что это произошло позже):

timestamp client = 1736521967726  timestamp rsp =  1736521967772

Моя логика заключалась в том, что эти показания, вероятно, вызваны тем, что мои машины были синхронизированы с разными серверами времени, поэтому я настроил NTP для синхронизации машин.

на подчиненных Raspberry Pi, используемых для отправки сигналов мыши, ntpq -p показывает :

     remote                                   refid      st t when poll reach   delay   offset   jitter
=======================================================================================================
 0.ubuntu.pool.ntp.org                   .POOL.          16 p    -  256    0   0.0000   0.0000   0.0001
 1.ubuntu.pool.ntp.org                   .POOL.          16 p    -  256    0   0.0000   0.0000   0.0001
 2.ubuntu.pool.ntp.org                   .POOL.          16 p    -  256    0   0.0000   0.0000   0.0001
 3.ubuntu.pool.ntp.org                   .POOL.          16 p    -  256    0   0.0000   0.0000   0.0001
*th1.localdomain                         45.87.76.3       3 u   69  128  377   0.3633 -10.4162   1.5014
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx         193.190.230.65   2 u   19  128  377  18.1793  -7.6719   3.1826
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx       .PPS.            1 u    2  128  377  20.4149  -3.6354   2.8498
+xxxxxxxxxxxxxxx                         10.0.0.5         2 u   16  128  377  21.1018  -7.1599   3.7262
[...]

что, кажется, указывает на то, что часы подчиненных Raspberry Pi синхронизированы с часами th1.localdomain, который является моей локальной машиной с WebSocket сервером и клиентом.

мои ожидания были, что после синхронизации часов машин я постепенно перестану получать эти показания, но спустя ~30 минут я все еще получаю отрицательную задержку.

скорее всего, у меня есть неверные предположения о NTP, так как у меня ограниченные знания в области компьютерных наук и сетей. Я также попробовал аппаратное временное штампование с PTP, но мне не удалось синхронизировать часы вообще.

Так что мои вопросы такие:

• есть ли у меня неправильные предположения о NTP?
• разве мои часы (и временные метки) не должны быть синхронизированы в пределах миллисекунд сейчас?
• или я использую неправильный метод для расчета задержки между Raspberry и моим WebSocket клиентом в целом?

Большое спасибо за вашу помощь.

PS/ для дополнительного контекста, репозиторий кода находится здесь

• show.html — это клиент ws
• server.js — это сервер ws
• mouse-grabr.py — это программа на Python, работающая на Raspberry