Jump to content

Александр Рыжов

Moderators
  • Posts

    1,215
  • Joined

  • Last visited

  • Days Won

    25

Posts posted by Александр Рыжов

  1. 33 минуты назад, MDP сказал:

    А вот с этим как-то надо разобраться...каша образуется в syslog -сервере.

    Почему? В syslog-сервер события ложатся последовательно по мере прибывания, просто с разными time stamp'ами. 

    36 минут назад, MDP сказал:

    Зря сделали отсчет от последнего сохранения конфига

    Отнюдь. Это в т.ч. бережёт от следующей циклической ситуации:

    • Имя NTP-сервера не может быть разрешено, т.к. пока не работает DNS,
    • DoH/DoT DNS не может подняться, т.к. сертификаты пока не валидны по времени.
  2. 29 минут назад, Goblin сказал:

    а логи править некрасиво.

    Зря цепляетесь, там затёрт IP-адрес. 

    37 минут назад, yuoras сказал:

    Пусть там будет хоть 1900 год)

    SSL-сертификаты будут невалидны, а так-то да. От железячечки без RTC чего-то серьёзного в плане точности времени  можно не требовать. Если обратили внимание, после ребута роутер достаёт "текущее" время из последнего сохранённого конфига.

  3. 16 минут назад, Goblin сказал:

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

    Сколько раз висеть?:) 

    ~$ sudo grep -i synchronized  /var/log/x.x.x.x-syslog
    …
    Jun  8 04:13:01 x.x.x.x ndm: Ntp::Client: time synchronized with "0.pool.ntp.org".
    Jun  9 19:25:41 x.x.x.x ndm: Ntp::Client: time synchronized with "3.pool.ntp.org".
    Jun 16 19:25:53 x.x.x.x ndm: Ntp::Client: time synchronized with "0.pool.ntp.org".
    Jun 23 19:26:44 x.x.x.x ndm: Ntp::Client: time synchronized with "3.pool.ntp.org".
    Jun 30 19:27:16 x.x.x.x ndm: Ntp::Client: time synchronized with "0.pool.ntp.org".
    Jul  7 19:27:47 x.x.x.x ndm: Ntp::Client: time synchronized with "1.pool.ntp.org".
    Jul  9 21:47:39 x.x.x.x ndm: Ntp::Client: time synchronized with "1.pool.ntp.org".
    Jul 14 19:41:03 x.x.x.x ndm: Ntp::Client: time synchronized with "2.pool.ntp.org".
    Jul 16 16:16:04 x.x.x.x ndm: Ntp::Client: time synchronized with "2.pool.ntp.org".
    Jul 23 16:16:15 x.x.x.x ndm: Ntp::Client: time synchronized with "3.pool.ntp.org".
    Jul 30 16:16:36 x.x.x.x ndm: Ntp::Client: time synchronized with "1.pool.ntp.org".
    Aug  6 16:16:47 x.x.x.x ndm: Ntp::Client: time synchronized with "2.pool.ntp.org".
    Aug 13 16:16:59 x.x.x.x ndm: Ntp::Client: time synchronized with "3.pool.ntp.org".
    Aug 20 16:17:10 x.x.x.x ndm: Ntp::Client: time synchronized with "0.pool.ntp.org".
    Aug 26 18:58:38 x.x.x.x ndm: Ntp::Client: time synchronized with "2.pool.ntp.org".

    Т.е. раз в несколько дней потенциально тратить на ожидание завершения синхронизации времени несколько дополнительных миллисекунд.

     

    Я бы не доверил роутеру автоматический выбор какого-либо внешнего сервиса, будь-то NTP или DNS или ещё что-то, если это потенциально может привнести доселе отсутствующие проблемы.

    • Upvote 1
    • Y'r wrong 1
  4. В 25.08.2020 в 17:26, Goblin сказал:

    В конце статьи:

    Цитата

    Если точность +-0.05 секунды вас устраивает, можно не заморачиваться с выбором серверов, и синхронизироваться с сервером по умолчанию

    Что-то я не уверен, что внутренний MIPS clocksource способен обеспечить такую точность. А при использовании CONFIG_RALINK_CPUSLEEP вообще суточный дрейф до нескольких секунд.

  5. 17 минут назад, Сергей С сказал:

    Использую debian на кинетике гига 3. Недавно подключил у провайдера высокоскоростной интернет. Проверка на сайте speedtest.net около 300 мбит. Но при проверке утилитой speedtest из debian на кинетике скорость не выше 100 мбит. Может быть какое нибудь ограничение в скорости подключения в debian или провайдер каким то образом обманывает проверку на сайте speedtest?

    Роутер предназначен для работы с транзитным трафиком. Полагаться на показания скорости, намерянные с самого роутера не надо: CPU роутера слишком слаб для этого.

  6. Именно поэтому и уточнял, потому что мне до сих пор непонятно: зачем между роутером и NAS'ом два гигабита, если дальше все соединения (все два:)) будут не шире одного гигабита.

    Отказоустойчивость, т.е. недоверие гигабитному кабелю? Тоже не понятно, простите. К клиентам дальше будет идти по одному вместо пары.

  7. 1 минуту назад, Keenetic сказал:

    Так как между NAS и роутером KN-1810 самое узкое место - гигабитный сосок, то Link Aggregation это выход с ситуации «узкого горлишка».

    Link Aggregation увеличивает пропускную способность NAS с помощью объединения нескольких сетевых интерфейсов и обеспечивает переключение трафика для сохранения сетевого соединения в случае его потери

    Даже если считать гигабит NAS-роутер узким горлышком и устранить его агрегацией, то что делать с клиентами? Подразумевается агрегация оставшихся двух LAN-портов?

     

    В 29.08.2017 в 14:32, vasek00 сказал:

    Утилиту управления можно будет использовать ifenslave (пока ее там нет в Entware-3х но https://github.com/Entware-ng/entware-oldpackages-ports )

    Добавлять не станем: ifenslave использовалась на ядрах 2.6 и безнадёжно устарела. Функционал перенёс в iproute2 с 2011-го года.

  8. 26 минут назад, Keenetic сказал:

    Будет подключатся NAS DS718+

    Это необходимо для того, чтобы передавать по гигабиту одновременно в каждый из оставшихся двух Ethernet-портов, верно?

    Просто выгода от bonding'а при наличии всего четырёх Ethernet-портов как-то не очевидна, а то и вовсе на гране здравого смысла.

  9. 1 час назад, Exrector сказал:

    Нужен. Хотя бы для того чтобы установить homebridge и привязать все устройства в доме

    Он на node.js написан, поэтому на кинетик его добровольно разработчики не добавят.

  10. Запросто может быть из-за перебоев питания. Если роутер не подключен к бесперебойке, то я бы не стал на него складывать сколь-нибудь значимую информацию.

    Полезно будет заглянуть в системный лог для выяснения обстоятельств.

×
×
  • Create New...