Что делать, если сеть не тянет камеры?

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

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

Расчёт делается за пять минут. Приложение 2 к Правилам НСВМ задаёт минимальный битрейт 5000 кбит/с на камеру — это 5 Мбит/с. Умножаем на число камер и получаем непрерывный поток записи, который сеть обязана держать круглосуточно, без учёта живого просмотра. Для 24 камер это 120 Мбит/с, для 60 камер — 300 Мбит/с.

Расчёт объёма: 5000 кбит/с = 0,625 МБ/с, за сутки 0,625 × 86 400 = 54 ГБ на камеру, за 30 суток — 1,62 ТБ. Отсюда 60 × 1,62 = 97,2 ТБ. Срок хранения не короче 30 суток требует ПП РК от 06.05.2021 № 305, поэтому сокращать глубину архива ради разгрузки диска — не вариант; подробнее мы разбирали это в материале о том, сколько дней нужно хранить видеоархив.

Живой просмотр добавляется сверху. Мультиэкран на 16 камер основным потоком — это ещё 16 × 5 = 80 Мбит/с на каждое рабочее место. Два поста охраны на 24-камерной системе дают 120 + 160 = 280 Мбит/с. Гигабитное ядро это выдерживает, стомегабитный аплинк — нет.

Потери кадров возникают там, где трафик упирается в физический предел линии или в ошибки на ней. Порядок проверки один и тот же: сначала скорость и дуплекс порта, затем счётчики ошибок, затем суммарный поток против полки аплинка. Ниже — точки, которые на наших объектах срабатывают чаще остальных.

1. Аплинк коммутатора доступа. Камеры подключены гигабитными портами, а вверх идёт 100 Мбит/с, поэтому при 24 камерах расчётные 120 Мбит/с физически не помещаются в канал.
2. Скорость и дуплекс договорились неверно. Порт ушёл в 100 Мбит/с half-duplex из-за повреждённой пары или превышения 100 м медного сегмента (предел витой пары по IEEE 802.3 и ISO/IEC 11801: 90 м стационарной линии плюс шнуры).
3. Ошибки CRC на линии. Плохая обжимка, повреждённая изоляция, влага в уличной муфте, поэтому кадры доходят битыми, поток восстанавливается ретрансмиссиями, оператор видит рывки.
4. Общий сегмент с офисной сетью. Резервное копирование или выгрузка учётной базы в рабочее время забирает канал, и камеры сыплются ровно в эти часы.
5. Рабочее место оператора. Декодирование 16 потоков 1920×1080 при 25 к/с упирается в процессор АРМ. Сеть здесь ни при чём, а выглядит как сетевая проблема.

Первые четыре пункта лечатся настройкой и заменой одного-двух узлов, пятый — переключением мультиэкрана на субпоток. Если субпоток настроен на 1 Мбит/с, те же 16 окон дают 16 Мбит/с вместо 80.

Камера, которая пропадает и возвращается циклами, обычно не зависает, а перезагружается из-за нехватки питания. Коммутатор снимает мощность с порта при превышении бюджета, камера уходит в ребут, оператор видит чёрный квадрат. В журнале порта это выглядит как серия событий link down / link up, поэтому по ним причина определяется однозначно.

Ключевая ловушка — суммарный PoE-бюджет коммутатора. Он указан в паспорте отдельной строкой и, как правило, заметно меньше суммы максимумов всех портов: 24 порта класса Type 2 по 25,5 Вт на устройстве — это 612 Вт потребления, которые редкий коммутатор доступа отдаёт целиком. Летом запас есть, зимой включается обогрев, потребление уличных камер растёт, и бюджет заканчивается, отсюда сезонные «зависания», которые весной проходят сами.

Отдельно проверьте автономность. Приложение 2 к Правилам НСВМ требует не менее 60 минут работы при пропадании основного питания, и это относится ко всей цепочке: камера, коммутатор доступа, коммутатор ядра, регистратор. Если ИБП стоит только у регистратора, при отключении света запись прекращается, хотя формально резерв «есть».

Недостаток освещения — это сетевая проблема, а не только вопрос качества картинки. При переменном битрейте камера кодирует шум как полезную деталь, и ночной поток растёт относительно дневного. Канал, который днём загружен наполовину, ночью упирается в полку, отсюда классическая жалоба «днём всё нормально, ночью каша».

ПП РК от 06.05.2021 № 305 в п. 68 требует охранного освещения полосой 3–4 м и не менее 10 люкс. Норма написана про безопасность объекта, но выполняет её и сеть: чем меньше шума на матрице, тем ниже битрейт и стабильнее поток. Поэтому при разборе ночных лагов мы всегда снимаем замер потока в тёмное время суток и сравниваем с дневным, прежде чем предлагать менять коммутаторы. Что ещё влияет на поток, кроме света, мы разбирали в материале о том, что важнее: мегапиксели, объектив, свет, WDR или аналитика.

Edge-буфер — это запись на карту памяти внутри камеры, которая включается при потере связи с регистратором и дописывает пропущенный фрагмент в архив после восстановления канала. Он не заменяет исправную сеть, но закрывает главный риск: инцидент, случившийся ровно в момент обрыва, остаётся зафиксированным.

Считаем ёмкость по тому же битрейту: при 5000 кбит/с камера пишет 0,625 МБ/с, то есть 2,25 ГБ в час и 54 ГБ в сутки. Карта на 64 ГБ покрывает около 28 часов автономной записи, на 128 ГБ — около 57 часов (фактически чуть меньше за счёт служебной разметки). Этого хватает на выходные, на замену повреждённого патч-корда или на аварию питания в удалённом корпусе.

Практический минимум, который мы закладываем на объектах: буфер не меньше суток на камерах периметра, кассовых узлов и въездных групп, и обязательная проверка дозаписи после восстановления связи. Функция часто включена, а дозапись не настроена, тогда буфер есть только на бумаге.

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

1. Снимите счётчики портов на всех коммутаторах: скорость, дуплекс, CRC-ошибки, discards. Ненулевые CRC — это дефект линии, никакие настройки его не лечат.
2. Посчитайте суммарный поток на каждом аплинке: число камер × 5 Мбит/с (или фактический битрейт из регистратора) и сравните с полкой порта.
3. Разделите живой просмотр и архив — воспроизведите запись за проблемный период и посмотрите, есть ли пропуски там.
4. Проверьте PoE-бюджет по паспорту коммутатора против суммы потребления камер с учётом зимнего обогрева.
5. Повторите замер потока ночью, в самое тёмное время, и сравните с дневным.
6. Проверьте автономность — отключите ввод и убедитесь, что вся цепочка держит не менее 60 минут.
7. Проверьте дозапись из edge-буфера: отсоедините камеру на 10 минут и убедитесь, что фрагмент появился в архиве.

Результат этих семи шагов — короткий перечень конкретных узлов с цифрами, а не общий вывод «сеть слабая». По нашему опыту, значительная часть пунктов закрывается настройкой субпотоков и разделением сегментов, без закупки.

Сначала настройки, потом узлы, потом топология. Переключение мультиэкрана на субпоток и вынос камер в отдельный сегмент не стоят ничего и снимают часть нагрузки сразу. Замена коммутатора доступа с гигабитным аплинком оправдана, когда расчётный поток превышает полку. Переделка топологии нужна, когда камеры собраны в цепочку из нескольких коммутаторов последовательно.

И главное. Почти всегда сеть считалась под ту систему, которая была на старте. Восемь камер по 5 Мбит/с — это 40 Мбит/с, они спокойно жили на стомегабитном аплинке. Дальше добавили склад, парковку, въезд, и те же 24 камеры дают уже 120 Мбит/с, которые в этот аплинк физически не помещаются. Камеры при этом исправны, регистратор исправен, а система «не работает». Это же развилка между модернизацией и полной заменой. Мы её разбирали в материале о том, когда выгоднее модернизация, а когда полная замена.