Jump to content
Калькуляторы

dr Tr0jan

Активный участник
  • Content Count

    651
  • Joined

  • Last visited

2 Followers

About dr Tr0jan

  • Rank
    Аспирант
  • Birthday 04/03/1987

Контакты

  • Сайт
    http://www.stfw.ru
  • ICQ
    255738981

Информация

  • Пол
    Мужчина
  • Интересы
    Информационные технологии

Город

  • Город
    Россия, Хабаровск

Recent Profile Visitors

2964 profile views
  1. @serg999, Flow Control - это к L2, ошибок и не должно быть. sh int fa8 | inc flow sh int fa8 | inc pause
  2. Тогда, какая разница в битрейте для процессора? Что 4 Mbps, что 10 Mbps - нагрузка на проц будет примерно одинаковая. Прекрасно работает. Уличное освещение по времени суток резко не изменяется, по площади/месту тоже резко не изменяется. Значит, объект при переходе от камеры (сцены) к камере (сцене) резко измениться тоже не может. Только если в помещение не заходит, что тоже прекрасно решается правильным освещением сцен. Над освещением в гараже надо работать. И техподдержку Макро побольше пинать. На заре внедрения макроскопа на предприятии (лет шесть назад) ради эксперимента воткнули в него старую eVidence Apix Vdome M1 (кстати, до сих пор работает прекрасно) и завели аналитику, по приколу решать три разные задачи (в т.ч. и детектор движения) в (!) контровом солнечном свете. Так вот софт прекрасно справился с детектором движения, сами в шоке.
  3. Ненужно ловить мультикастовые пакеты до тех пор, пока не будет решена проблема с STP. Почему, писали выше. Sapienti sat.
  4. Докажи или GTFO. Покажи хоть один алгоритм, который без декомпрессии умеет хоть что-нибудь из следующего: картинка разбивается на прямоугольнички, каждый кадр с каждого прямоугольничка снимается слепок данных, на следующем кадре идет сравнение на изменение каждого, при наличии изменений в одном. Пространственно-цветовые характеристики. Работает норм, но все камеры должны быть примерно одинаковыми (т.е. нельзя воткнуть старый evidence и следом свежую dahua), освещение сцен должно быть также похожим (нельзя освещать одну сцену синим светодиодом, другую - жёлтой лампой накаливания или вообще луной). Соболезную. На пяток четырёхтерабайтных винтов денег не жалеют, а на бетонные столбы жалеют (для справки, у нас глубина промерзания 2,60 метра). Ну а про резкость, нормальные камеры с нормальным автофокусом сами решают эту проблему.
  5. На сжатом или несжатом потоке производятся сии действия? Межкамерный трекинг в сабжевом макроскопе работает прекрасно. Больше трёх камер (до, во время, и после) для мультивида не нужно. Думаете, в Хабаровске не бывает газонов с травой? И газоны, и трава, и лес, всё как везде. В маскхалате под камерой не пробовал лазать, надо попробовать - посмотреть разницу на детекте/битрейте. :) Я не могу ставить эксперименты на загородных домах. Только непосредственно в офисе. Безопасников у нас без малого около 1000 человек, из них около 30 постоянно смотрят видео (и онлайн, и архив). Держать на загородных домах по пять четырёхтерабайтных винтов хозяевам домов накладно, им подавай подешевле. Что? Потратить на 10 минут на настройку загородного дома больше? Настройки делаются всего два раза за всю жизнь объекта (летом и зимой).
  6. Иногда этот вариант выстреливает с первого порта, особенно, если сможешь догадаться, что было на уме у прошлого саппортера. Тогда станешь траблшутером уровня мистера Вульфа из Криминального чтива.
  7. Я честно скажу, я не знаю, как именно работает алгоритм детекции движения. Но мне всегда казалось, что работа любой аналитики производится на несжатом изображении, в таком случае битрейт не имеет никакого значения. Если это не так, поправьте. У меня 60-камерные серваки на производстве нормально работают. На загородных домах 10-16 камер, всё летает, проблем нет. Зачем в мультивиде архива такое нагромождение? У нас всё так же, только трёх камер достаточно. Речь про архив мультивида. Причём здесь онлайн просмотр? Для онлайн просмотра можно во втором потоке хоть 32, хоть 96 каналов смотреть, но зачем? МВД Великобритании (признанный авторитет в мире в видеонаблюдения) доказало, что один человек способен адекватно анализировать полиэкран из максимум 9 каналов. При 16 каналах внимание рассеивается - раз, разрешение ухудшается - два. Никак не можем доказать это своим безопасникам. Но повторюсь, что даже 16 каналов 4K не несёт проблем с производительностью, как в архиве, так и в онлайне. Это какое оборудование не умеет TCP??? Речь о том, что нет никакого смысла забивать гвозди микроскопом. Или Микротик не умеет UDP??? Ещё раз, на нормальных камерах 4K (в т.ч. Dahua, я уже не говорю про Honeywell и тем более Axis) при битрейте 4 Mbps качество картинки позволяет полноценно наблюдать за объектами в 20 000 кв. м, или за помещениями с 200 человека с возможностью немашинного распознавания лиц. Такие задачи регулярно (несколько раз в месяц) прекрасно решаем на FHD камерах (Panasonic, Dahua) с битрейтом даже меньше 4Mbps. И ваше тоже не потянет. А иначе расскажите, как сохранить месячный архив с 60 камер битрейтом 15 Mbps (вы же оба потока пишете + звук) в течение месяца? И как потом обеспечить одновременную работу с этим архивом 30 сотрудникам? 300 терабайт то. С рэйдом и возможностью горячей замены. Ну а 16 камер - 80 терабайт, где всё это дело в загородном доме хранить и охлаждать? Это щас к чему было? А это сейчас что было? Что на каждую камеру в отдельности зайти, что зайти в настройки детектора движения каждого канала в сервере. Или у вас все камеры абсолютно разные и вы их каждый местами меняете?
  8. @LostSoul, видеонаблюдение на загородном доме на Пентиуме I гонять? У нас на четырёх загородных домах стоят специально рассчитанные (под задачу) сервера, на двух детектор движения камеры используется, на двух других - Макроскоп. Проблем с нагрузкой нет.
  9. Зачем? У меня работает на основном потоке. Повторюсь, но трёх-четырёх камер (особенно на загородном доме) достаточно. С 30ю камерами обычно проблем тоже нет, но видюха напрягается. А с другой стороны, практического интереса в 30-камерах в мультивиде ещё ни разу не возникало. И это не загородный объёкт, а огромное предприятие. Ещё раз. Зачем нужна гарантированная доставка пакетов в сети без потерь? В ней априори все пакеты будут доставлены. Аргументов, почему гарантированная доставка пакетов в сети без потерь - лучше, чем её отсутствие, я не услышал. А зачем смотреть архив через UDP? Камеры вещают, а архив пишется в UDP. Архив смотрится через абсолютно любой канал в TCP. Это же video-on-demand, а не real-time. Эта цитата была вырвана из контекста про обсуждение UDP vs TCP. Теперь про медленный канал. Может ты и прав, но я ещё не сталкивался с практической необходимостью транслировать 16 камер потоком 10M каждая через интернет. Повторюсь, 4k в x265 в 4M достаточно для мониторинга любых событий, если мы конечно не видео о живой природе через инет транслируем. Первую попавшуюся камеру 4k взял, так вот она закрывает территорию в 20 000 кв. м и передаёт картинку с битрейтом в 4M в x264. Затем подумал, что это нечестно и взял x265 камеру - там вообще битрейт 3.3M, а качество ещё выше (камера поновее и почище). Где большее качество нужно на загородном доме, не представляю. Т.е. когда выпускались, всё было нормально? Может в таком случае не стоит применять эпитет "приходится"? 1) А зачем? 2) А куда я архив буду складывать? 3) А как у меня пользователи будут это смотреть? Не могу представить. Не понимаю, зачем нужен детектор движения по второму потоку?
  10. Они не лучше работают. Они работают совершенно одинаково. Аргументов, почему они должны работать лучше ты предоставить затруднился. Конечно не представляем. Зачем в загородном доме чужие сети с туннелями и удалённые объекты? Что же здесь непонятного? Всё изначально понятно для любого специалиста/инженера. Глупости какие-то. Нормальный (с нормальными буферами) стомегабитный коммутатор пережёвывает 48 потоков в 15M и выплёвывает в гигабитный аплинк. Можно сказать, это одна из основных обязанностей в работе. Вообще нет нестыковок, даже 300 мс нестыковок нет. Что по UDP, что по TCP. Я думаю, у вас система видеонаблюдения неправильно спроектирована. В нормальных системах (eVidence, Panasonic, Milestone, Макроскоп) таких проблем не то что не может, не должно быть. Обычно, ничего не сообщает. А зачем синхронизировать поток, если он сам синхронизируется по времени RTC? Наверное потому что изначально HTTP работает не только на 10 гигабитных езернет-каналах, но и в совершенно других физических средах. А торренты изначально по TCP работали, когда накладные расходы TCP стали заметны, стали использовать в том числе и UDP. В сетке из 16-камер на 47" ТВ, да когда таких телевизоров шесть на одного оператора? Наверное, вы не умеете их готовить.   Ну я и говорю, в мультивиде - полный поток. Проблем (особенно на загородных домах) не испытываем. Вообще, часто из практики архив мультивидом дёргать приходится? Я думаю, зависит от расстановки камер. Мне обычно трёх-четырёх камер мультивидом в архиве достаточно.
  11. И в чём проблема? Приснопамятный Заббикс может мониторить с любой ОС. А винбокс - не может. Держать кучу различных средств мониторинга - очень плохо (теряется внимание).
  12. А зачем её гарантировать в сетях, где нет потерь, т.к. где доставка априори гарантированна сетью??? Ну если основной поток 10M, тады ой. На длинке вполне допускаю переполнение буфера. Не работаю с такими большими потоками. Обычно с x265 меньше четырёх достаточно. А нахера писать второй поток в 1.5M? Макроскоп прекрасно делает мультивид в записи из основного потока. Я с Длинками не работаю уже 8 лет. Но вот прям сейчас (на загородном доме, кстати) на стареньком DES-1024 (выступает выключателем между двумя каталистами) нет никаких проблем с 10ю камерами с потоком 4 Mbps в работе по UDP. Тогда откуда тогда берётся рассинхронизация??? Да ну! И оверхед у TCP меньше, и контроль соединения в памяти отсутствует, да? Полнейшая профнепригодность!
  13. По теме. Ваша же схема. Микротик, сервер классификации траффика, в сервере помирает винт. Как диагностировать это в винбоксе?
  14. Это ещё почему? Да потому что неправильно построена/рассчитана сеть. Если вероятность переполнения буферов сетевого оборудования в квант времени равна нулю, то никаких тормозов/обрывов/рывков не будет. Рассчитывается элементарно. На TCP только сеть лишний раз загружать ретрансмитами, да джиттер увеличивать. Кстати, от движения рывками TCP никак не поможет. Только от визуальных обрывов.
  15. Попробуй махнуть оба БП местами (в смысле вводы). И поменять бесперебойник. На прошлой неделе получил убер-факап при подобной ситуации. Стоит Zabbix на HPE Proliant DL160Gen8 (а он только с одним БП бывает), подключён через APCшый АВР в два Smart-UPS 10k, которые в свою очередь подключены в щит гарантированного питания (у которого SLA 99,995% - I кат. особая, все дела) Электрики начинают плановые работы в пятницу после конца рабочего дня (никого об этом конечно же не предупредив), имеют дикую просадку (с отражением в логах iLO/BMC и АВР, как потом узнали). С какого-то перепуга DL160Gen8 падаёт с грохотом и забирает с собой базу Заббикса вхлам. Дежурная смена особо не переживает, т.к. упал только сервак заббикса (мало что бывает, всё работает, а разбираться я уже буду, как до компа доберусь). А ЦОД тем временем весело крутится на бесперебойниках. Пока добирался до компа, батареи сели, вместе со всем ЦОДом. Подозреваем (исключая три других фактора, не имеющих отношения к теме), что проблема в БП Пролианта.