LostSoul

842ND практически не дохнут . уже скока лет

netinstall можно вернуть только если загрузчик не менять. по теме, первая стадия прошивки это просто "загрузка из сети" в ОЗУ. содержимое долговременной памяти оно не меняет поэтому после первой стадии прошивки можно проводить различные тесты в том числе и нагрузочные, прежде чем флеш переписывать

Зависит от модели. если в спецификации на сайте производителя значится "Usb power reset: yes" то умеет. но управление питанием обычно имеет обратную сторону - падение напряжения при повышенном токе. поэтому с древними жрущими модемами типа первой lte от yota была диллема , то ли через управляемый usb включать для авторесета, то ли через неуправляемый для большей стабильности

так и думал. и передернуть usb скриптом, если перестали поступать показания это один раз настроить и кстати за последние 10 лет, я не видел на предприятиях ни одной реализации чтоб RS-485 тянули из здания в здание "на километры" без перехода на Ethernet/оптику

а зачем попу гармонь? я еще понимаю что-то многопортовое, а sxt2 зачем перешивать?

у меня на LTU-PRO тесты speedtest показывают где-то на 15% хуже результат чем оптимистичные встроенные тесты. и насколько помню airmax древний - там было так же   абсолютно не интересный на таком расстоянии и полосе результат. на полосе 80мгц и "на столе" в идеальных условиях должен быть четкий гигабит по идее. так что сначала надо нормально на столе отладить, а потом уже ставить куда-то

тут не все помнят, что ты читать не умеешь. в четвертый раз пишу, tx_en выставляется чипом uart-usb при наличии tx трафика в буфере. это не напрямую с линии tx.   из примерно 600 трудящихся у меня микротиков висла пока только одна модель - 4011 и то 2-3 раза.

Никто. Usb-uart чип ему дергает ТX_EN по факту того, что в буфере появилось что отпрпвить   Я пока не встречал еще психов, пытающихся воткнуть километровые линии в usb-uart. Типовое применение такого - снимать показания с какого-нибудь однофазного счетчика в шкафу с оборудованием по проводкам длиной 30см. Или там степень засратости фильтров вытяжки в заббикс мониторить

в реализациях софта/железа на rs485 принято, что если не используется DSR/DTR то каждый узел когда не передает, то слушает . на автомате. То есть когда если в uart прут байты, она переключается на передачу и глохнет, пока в нее байты переть не перестанут. В протоколе это выглядит , например в modbus , так - все молчат, мастер проводит опрос. отправляет адресный запрос регистра на конкретное устройство и ждет таймаута ( все молчат, устройство которое спрашивали - отвечает ) , дальше мастер опрашивает следующее устройство и.т.д. естественно что это работает чуть медленее и разработчику железки нужно не забывать защитные паузы вставлять в нужные места

там нюансы всякие могут быть в DSR DTR и.т.п. , если вашему софту/оборудованию достаточно базового rx/tx то просто берете любой переходник на uart и соединяете с преобразователем уровней в rs485 ну или вот такой готовый модуль где все уже сделано

думаю , спаянное на совместимых с самим микротиком чипах должно жрать но будут нюансы применения скорее всего например на cp2202 что-то такое https://mysku.ru/blog/aliexpress/73691.html   такая инфа попадалась RouterOS on mips have these modules enabled: USB_NET_MCS7830 USB_NET_AX8817X USB_NET_CDCETHER USB_HSO USB_USBNET Model RouterOS Works AX88772B v5 & v6 Yes UA0025C v5 & v6 Yes AX88178 v5 & v6 No

можно расшифровать по русски?

да уже и унитаз принесли и задницу показали, а все равно недоволен. ( см анекдот ) будет время прогоню зеркальный поток трафика от "много малогрузящих абонентов" - поглядим. пока никаких описанных проблем не вижу

А что, еще где-то школы подключаются к альтернативным операторам? Там же РТ за 10.3 миллиарда подключает сейчас все школы, максимум вроде последнюю милю ему продать можно

далее у вас будет рождество, новый год, праздники , или там срочный выезд к больной тете а вам надо заглючивший комп перебирать или выяснять почему софт заглючил. не все желают тратить своё немногочисленное свободное время на самопальный видеорегистратор hand-made. оптимально иметь и то и другое. простой дешевый регистратор чтоб картинка точно была надежно записана , и второй навороченный на базе компа для всякой там аналитики и прочих странных чудачеств

Не бывает так, чтоб не заморачиваться и схалявил. По актуальности на состояние год назад крайне выгодны следующие сочетания 1) регистратор дахуя бюджетный на 16каналов и 2мп купить в мрскве ( в районе 9600тр было в марте во всяких плейер ру и видеоглаз ) + камеры дахуя с али ip-шные по ссылкам что есть на этом форуме от форумчанина saab95, 6мп которые, подтверждаю охрененные камеры в металл корпусе , работают и показывают хорошо, обновляются ( к регу их цеплять в режиме 2мп ибо рег на 6мп небюджетно пока ) Вариант 2 , камеры xm выбирать не абы какие а вдумчиво и грамотно читая форумы с конкретным модулем ( моделью платы ) с хорошим сенсором и под которые есть прошивки с частичной поддержкой дахуя/хиквижен протоколов. Или хотя бы onvif полноценно с отправкой событий движения. Я делал так пока не открыл для себя дахую с али , больше не делаю иьо экономия того не стоит. Но на 12 камерах может и стоит. Еще вам poe коммутатор потребуется. Если кроим то можно бу с авито или местной барахолки. Или можно новые неуправляемые 4 порта пое + аплинк в районе 2400 с бп от 220. Как делать топологию ( 16 портов в ядре и кабель к кажлой камере или 4 мелких коммутатора по 4 камеры зависит от расположения камер и вашего желпния обеспечить их все централизованным питанием. Набор из ahd камер ( или hd-tvi это примерно тож самое фирменное от хик ) тоже можно рассмотреть, но я бы не. Если хочется прям ваще жесткое кроилово то можно и камеры дахуя из пункта 1 + старый комп с бесплатным софтовым регом от дахуя, он работает сносно   Раньше даже таймлапса в стиле ютуб внизу не было. Список того что записалось чтоб пересмотреть грузим список файлов списком и по очереди их проигрыааем

Saab95 вы знаете детали про фрейминг в nv2? Есть в действительности какие то проблемы из описанных 700ым?

так у адекватного провайдера это ВЫКЛЮЧЕНО. пакет отправляется "как есть" , размером от 54 до 1500 байт без какого-либо пакинга. а 3200 байт это вы вообще с nstream перепутали, и вот там да, нагрузка на процессор растет сильнее. Но тем не менее, если вы считаете что такая проблема имеет место быть, то ядро процессора то при этом загружено или оно по вашему "тормозит" не использовав все ресурсы своего одного ядра на очередь?   давайте сначала на вас мою новую вакцину от короны испытаем :-) бред. достаточно прогнать запись трафика указанного поселка . любым tcpreplay с обоих концов линка.   никому он кроме его продавцев не нужен. это давно всем понятно

это очень логично, если исходить из целей и задач проверки - прошерстить тех кто не сдает статистику и не делает отчисления. вас никогда ГАИшник не штрафовал к примеру за то мелкое нарушение, на которое у него план, полностью игнорируя крупное?

так мы выяснили уже , что одного ядра Mikrotik ARM достаточно чтоб обработать 83k pps в одну сторону. и второго ядра чтоб обработать 83k pps в другую. нахрена нам ваш камбиум?

так рассмотри dahua с али

Пошел, проверил информацию. Да, входящий трафик с каждого интерфейса на mikrotik arm , похоже обрабатывается только на своем отдельном ядре. но есть маленький нюанс, от трафика в 100мбит это самое ядро загружается аж на целых 10% к сожалению нету возможности проверить, насколько линейно растет нагрузка, но если линейно, то получается что на радиомосту с 2 интерфейсами , одно ядро выжимет 1ГБит с проводного интерфейса , второе ядро 1ГБит с радиоинтерфейса. Из чего следует, что проблема , озвученная, slv700 высосана из пальца и надумана, ради продажи своего мусора. Указанное ограничение может стать узким местом, в случае если устройство несет дополнительный функционал типа NAT, шейпера , netflow , прозрачного моста для существенного количества ( сотни ) mac-адресов. В случае L3 моста , когда с каждой стороны канала виден только один единственный MAC , озвученное ограничение не актуально полностью.

Опять ложь, звездежь и натягивание совы на глобус. Допустим что распределение трафика по ядрам это хорошо и замечательно ( что не так , так как рождает ряд дополнительных проблем ) . Но зачем врать, будто бы без супер технологий этого не происходит совсем? Проблемы с распределением обработки пакетов по ядрам процессора исходно существовали только для обработки множества пакетов С ОДНОГО интерфейса. То есть, допустим , одно ядро у нас обрабатывает 350 Kpps ( 500мбит/1500байт , 166мбит/500байт, 17мбит/54байт , что там у вас "реальный трафик" подставьте сами ). Но трафик то идет в 2 направлениях, и с распределением по ядрам потоков download и upload ни на одной платформе проблем не было никогда, ибо прерывания и интерфейсы разные. Соответственно даже самая кривая и недоделанная платформа, имея 2 ядра прокачает 350kpps в одну сторону, и 350kpps в другую сторону ( то есть на пакетах 1500 байт суммарно in+out 500+500 = 1ГБит ) Так является ли это указанное приемущество Cambium реально востребованным? Сомнительно. Как сомнительно и то, что на Mikrotik ARM до сих пор не сделано распределение очереди пакетов с одного интерфейса по ядрам. и да, откуда slv700 взял что в LTU стоит одноядерный процессор? по cpuinfo выдает что там вполне себе двухядерный процессор MIPS частотой 2ГГц абсолютно одинаковый процессор стоит, что в rocket ltu , что в ltu pro   это фантастика. из 300 пользователей у 200 будет стоять дома 1-2 ТВ-приставки с какой-нибудь смотрешкой. Из этих 200 , минимум 50 будут регулярно забывать выключать ее на ночь вместе с телевизором, поэтому трафик от 300 домохозяйств не может быть ниже 225 мбит практически никогда, если это живые абоненты а не мертвые души.

Знания о сетевых технологиях носят системный характер и не привязаны к конкретному вендору или классу устройств. Для TDM-подобных каналов с сихнронизированным временем старта передачи очередного кадра, пакеты трафика размерами меньше чем транспортный кадр среды передачи можно либо передать немедленно, либо положить в очередь и пытаться дополнить подходящим по размеру другим пакетом ( или его частью ) в целях повышения полезного использования канала. И во всех случаях это будет приводить к увеличению задержки передачи пакета. Хоть гламурный маркетолог назовет это packet packing , хоть "очередями с акселератором" , суть не меняется. Для синхронного TDM-подобного канала без упаковки пакетов в кадры, производительность в битах(мегабитах и.т.п ) всегда будет равна PPS * на средний размер пакета. То есть ( приблизительно ) , один и тот же TDM канал без упаковки, выдает 500мбит/c на размере пакета 1500байт , 166МБит на размере пакета 500 байт , и 17Мбит/c на размере пакета 54 байта. Рассуждения про какой-то там "реальный трафик" без конкретики это ложь, трындеж и провокация. Очевидно, что нагрузку на канал могут формировать разные виды трафика. Если это игровой клуб на 500 посадочных мест , где проводится международный чемпионат по Counter Strike, то средний размер пакета будет <250 байт и пропускная способность около 20-25 МБит/c. Если это гостиница, в которой 90% нагрузки формируют Smart-телевизоры , загружающие OTT потоки пакетами по 1450 байт , то и пропускная способность будет 483МБит из 500 полученных для "полного кадра". Реальный профиль трафика для домашних подключений при количестве 20-50 абонентов на вынос показывает что средний размер пакета примерно в районе 1350 байт , таким образом 500мбит измеренных "по тесту" превратятся в 450мбит по "графикам интерфейсов". Но так как пользователь не хочет покупать тарифы в виде "пакетов в секунду" , а практически для абонента реальная скорость имеет значение только в одном случае - когда он пытается перекачивать большие файлы. И в этом случае большие файлы нарезаются как раз по 1500 байт, поэтому трафиком от этого пользователя канал будет нагружен максимально эффективно. Поэтому "замылить глаза клиенту" никто не пытается, клиенту демонстрируют реальную скорость загрузки файла из сети Интернет , достижимую на практике. В случаях же "иного использования" ( кроме передачи файлов или высокоскоростных потоков данных ) клиенту в принципе не важна скорость. Допустим клиент купил 300мбит/с безлимитный тариф. А я "в уме" перечитал это как 25 тысяч пакетов в секунду , потому что вместо охрененного камбиум с электролитами очередями и акселераторами купил себе "пионерский" микротик. При загрузке файлов клиент увидит свои честные 300мбит. А что если он решит поиграть в CS? Трафик от одного игрока - аж целых 3 пакета в секунду. Таким образом, купленного тарифа клиенту хватит аж на 8333 игроков , играющих одновременно у него дома. Замылил ли я глаза клиенту, если не предупредил его, что 8 тысяч игроков из его квартиры играть смогут, а вот 133 тысячи ( с игровым трафиком 300мбит ) уже не смогут? Видимо я очень недобросовестный провайдер. Надо покупать камбиум и жить не по лжи.

все верно говоришь. использовать камбиум , распределяющий пакеты по очередям , для чего ему требуется целых 4 ядра с аксселератором это путь пионера-любителя. а мы просто ставим одноядерный микротик и получаем 500мбит нашего профиля трафика ( и 300мбит вашего профиля трафика ) без всяких извращений   когда вместо сказок про "не предусмотрено отделом маркетинга производителя" будут представлены факты про разницу между rocket LTU и LTU-PRO , тогда будем подвергать сомнению верность методики теста.