Выбор poe свича

[pafftis]

Добрый день, в корень надоели эти отгнивающие самокрутки т камер, вечно отваливающиеся и так далее.
В общем имеем 10 вот таких камер:
https://trade.aliexpress.com/order_deta ... 8518229043" onclick="window.open(this.href);return false;
На расстоянии всё по разному думаю метров до 200, что посоветуете взять что бы всё было стабильно? что бы не резать не какие провода с выделением там жил.
Что бы и питания на всех хватало.

[kROOT]

неправильная ссылка на али
эзернет сегмент 100м вообще-то, но есть РоЕ коммутаторы до 250м при режиме 10 мбит. Вот только как 10 камер уживутся на 10 мбит я не знаю.

[pafftis]

Прошу прощения, вот ссылка:
https://www.aliexpress.com/snapshot/0.h ... 2844909270" onclick="window.open(this.href);return false;
Может вы так же посоветуете прямыми ссылками на то что нужно покупать?

[kROOT]

И опять мимо! Снапшоты показывают только самому покупателю, другим нет доступа.

[pafftis]

https://ru.aliexpress.com/item/32844909 ... 1363ZhPuH8" onclick="window.open(this.href);return false;
а если эдак

[Kangoshi]

...есть РоЕ коммутаторы до 250м при режиме 10 мбит. Вот только как 10 камер уживутся на 10 мбит я не знаю.

Нормально уживутся, если от каждой камеры до этого коммутатора будет своя витая пара (а как инчае? ). У таких коммутаторов 1-2 не PoE порта продолжают работать на 100Мбит (должны, иначе какой в них смысл, но у самого таких пока нет).
А 10 камер - это не более 55 Ватт, судя по спецификации. На это и опирайтесь, с запасом. Всё будет работать, вопрос только как долго. Но это относится к любому "китаю".

[kROOT]

У таких коммутаторов 1-2 не PoE порта продолжают работать на 100Мбит (должны, иначе какой в них смысл, но у самого таких пока нет).

Скорее всего, но надо проверять. У меня есть коммутаторы 6+2, который переключается на 250м и не РоЕ остается на 100 мбит, остальные переключаются на 10мбит, проверял сетевой картой компа.

[kROOT]

https://ru.aliexpress.com/item/32844909 ... 1363ZhPuH8
а если эдак

Так показывает, РоЕ в камере должно быть встроено, так что берите РоЕ коммутаторы, которые поддерживают 250м, про 16 портовых не помню что такие были, но пару по 8 вроде бывают. Или 4 и 8. У ATIS такие были из недорогих в России.

[Tюрин BB]

Нормально уживутся, если от каждой камеры до этого коммутатора будет своя витая пара (а как инчае? ). У таких коммутаторов 1-2 не PoE порта продолжают работать на 100Мбит (должны, иначе какой в них смысл, но у самого таких пока нет).

Если даже, все потоки, со всех камер и пусть даже подключенных по собственной витой паре, НО (!!!) на скорости в 10мбит, вы сведете в один и пусть даже 1гбит порт к которому подключите NVR, то реальная скорость прохождения пакетов в подобной системе, всё равно будет 10мбит (т.к. скважность, ну а значит и тормоза, между пакетами - будут соответствовать 10мбит. Ну а сами же пакеты, из кэша коммутатора, конечно же будут вылетать на порт NVR со скоростью 1000бит/с. Только вот сомневаюсь что вам господа (да и вашим СВН) от подобного 250 метрового 10 мбитного РоЕ - будет легче жить.

[Kangoshi]

...реальная скорость прохождения пакетов в подобной системе, всё равно будет 10мбит (т.к. скважность, ну а значит и тормоза, между пакетами - будут соответствовать 10мбит.

Откуда инфа? Тестировали китайские "дальнобойные" свичи или теория? Потому что если оно на самом деле так, как вы пишите, то такой свич теряет всякий смысл на существование, а я не думаю, что китайцы НАСТОЛЬКО тупы, чтобы делать такую железку. Но, опять же, опыта не имею, руководствуюсь законами логики.

[Tюрин BB]

Откуда инфа?

Ну как бы Вам ответить так, чтобы не обидеть? Ну скажем так, инфа от знакомого верблюда админа ЛВС СВН, который на подобные "откуда", всегда отвечает вопросом на вопрос:
- "Ну если тебе провайдер, на твоей домашний свич в 100 мбит выдает скорость в 1 мбит, то что же ты такой умный - кино в 4k с ютуба не смотришь на своей домашней сотке на всех своих 4 телевизорах?"

Тестировали китайские "дальнобойные" свичи или теория?

Нет, не тестировал и даже не собираюсь.

Потому что если оно на самом деле так, как вы пишите, то такой свич теряет всякий смысл на существование, а я не думаю, что китайцы НАСТОЛЬКО тупы, чтобы делать такую железку. Но, опять же, опыта не имею, руководствуюсь законами логики.

Ну почему же китайцы "дураки" и "нет смысла"?!
Как раз не дураки и смысл есть, причем целых два:
1) чисто заработать на продажах тем кто руководствуется исключительно собственной логикой, а не чужими знаниями и опытом.
2) плюсом к этому еще и заработать на небольших продажах специфических мало-камерных замкнутых системах ШЗ-ВН типа "домашне - коттеджная", просто требующих чуть больших расстояний установки чем стандартные 100м, но при этом не требовательных ни к качеству, ни к скорости отображения, таксзать система наблюдения а-ля слайд-шоу заточенная исключительно для просмотра на телефоне.

[grumbler]

Tюрин BB, "как бы вам ответить так, чтоб не обидеть". Лучше расскажу анекдот, который вам должен быть известен со времен совка:
- дорогая, третья Симфония Рохманинова такая гадость...
- а ты ее слышал?
- нет, мне Васька сосед ее насвистел...

Ваш знакомый админ либо вам не то рассказал, либо вы его не правильно поняли, либо он такой админ. Ну а про скважность и прочее - это все сказки из области "пальцем в небо".

По существу: внутри этих расчудесных китайских коммутаторов обычно стоят PHY RTL8309N со всеми вытекающими последствиями.
При этом, если очень-очень примитивно, то ситуация следующая: в режиме "extend" на RTL8309N поступает запрет на установку PHY соединения между портами "для камер" и самими камерами на скоростях выше 10 мбит. Порты аплинка либо выносятся на отдельный PHY, либо им просто этот запрет не ставят. RTL8309N имеет неблокируемую матрицу, поэтому соединения типа точка-точка устанавливаются независимо друг от друга и работают параллельно. Чтобы избежать штормов броадкаста на скоростях 10 мбит и не получить полный паралич коммутатора, порты "для камер" изолируются друг от друга - их выносят в отдельные VLANы, поэтому они НЕ МОГУТ передавать данные друг другу, только на аплинк и обратно. Параметр broadcast storm обычно выставляется какое-то приемлемое значение для 10 мбит, чтобы залипший порт тушить заранее. Поэтому ни вирусня с броадкастами, ни обычные камеры друг на друга влияния не имеют. Что же происходит с аплинками? Они работают на полной скорости, и емкости коммутационной матрицы на неблокируемых коммутаторах хватает чтобы обслужить все порты на максимальной скорости, благо это не так много, например, для 8 портов, это обычно 8*2*100=1.6 Гбит. Итог: со стороны физики залипаний не будет. А что же регистратор? Ведь действительно скорость загрузки информации от камеры до регистратора - не высокая, всего 10 мбит, и при установке соединения действительно физически данные будут передаваться будут из камеры регистратору на скорости 10 мбит, казалось бы - завал? Нет, не совсем так. На самом деле надо смотреть в корень TCP стека - установленные соединения не закрываются, т.е. накладные расходы после первой сессии установки соединения минимальны - камера открыла ТСР сессию, коммутатор запомнил, как каком порту находится адресат в таблице МАС адресов, и хоть он работает на уровне L2, этого достаточно для быстрой трансляции кадров из порта в порт. Далее коммутатор через оффлоад пакеты шлет либо прямо в порт, если тот свободен, либо может ПОЛОЖИТЬ себе в буфер, пока тот не заполнится и далее выкинуть регистратору пакет уже на МАКСИМАЛЬНОЙ скорости (а не на скорости соединения с камерой). Поэтому самым узким местом может стать малый размер буфера коммутатор, именно для этого мы должны знать и понимать такой важный параметр как PPS - количество передаваемых пакетов в секунду. Зная его, мы можем немного представить себе, сколько же пакетов генерит камера в секунду и сколько поместится пакетов в буфер и сколько регистратор сможет принять пакетов. Но и это еще не все. Как только коммутатор заполнит свой буфер - например - регистратор реально не успевает принять все данные - коммутатор НЕ ДАЕТ подтверждения свободного порта самой камере и тогда уже камера может складировать пакеты себе в буфер, агрегируя пакеты и дожидаясь освобождения кешбуфера/освобождения порта, ведь сессия-то уже установлена. Таким образом, мы имеем два уровня противодействия потере данных - на уровне коммутатора и на уровне камеры.
Когда же начнется то состояние, которое все просто называют - "жопа"? Тогда, когда начнутся проблемы с физикой, т.е. средой передачи, т.е. с кабелями. Как только фреймы с данными начнут повреждаться при передаче, начнутся переспросы, а так как неблокируемые коммутаторы обычно не проверяют контрольные суммы ТСР пакетов, а только выявляют проблемы уровня физики, а выявить их все нельзя, вот тогда регистратор начнет "футболить" камерам ответы - "пакет не принят" и камеры ОБЯЗАНЫ будут перепосылать пакеты заново. Вот тогда и начнутся проблемы, сеть просто захлебнется, причем очень быстро. Но это уже совсем другая история.
Итак, что же надо знать при использовании функции extend?
1. Физика должна быть в идеальном состоянии. Кабель должен быть целый, коннекторы позолочены, соединения гидроизолированы.
2. никакого биметалла, только медь. Вернее не так - видео и биметалл - вещи не совместимые в принципе. совсем, то есть абсолютно.
3. зная количество генерируемых пакетов (на одну сессию передачи уходит до 3 пакетов в обе стороны - запрос, данные и подтверждение) и их объем мы можем примерно прикинуть - хватит ли пропускной способности сети и кеша самого коммутатора. если не хватает кеша и/или скорости, всегда можно выбрать коммутатор со значительно большим буфером, но он и стоить будет значительно дороже.

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