Проектируется система видеонаблюдения на основе цифровых видеорегистраторов. Количество устройств наблюдения - до 10.

Регистраторы сливают видеоданные по проводному Ethernet-100 на специальный сервер, к которому также подключается ЭВМ оператора. Трафик каждой камеры составляет примерно 3 Мбайт/сек.

Какая аппаратная и программная организация сервера была бы в данном случае оптимальна?
Я предполагаю использование ОС Linux.

А в чем смысл сервера? Какой "сервис" он предоставляет? 30 мегабайт/с по Ethernet-100 это круто, да... И почему Linux?

Что за видеорегистраторы ?

Собирает данные с 10 камер, хранит на жестком диске, выдает оператору по запросу. Кроме всего прочего, сервер хранится в отдельной, защищенной от проникновения комнате (особенности эксплуатации системы).
На Linux я не настаиваю. Но полагаю, что линукс прозрачнее и не такая сбойная как windows.



Видеокамеры, которые выдают несжатые видеоснимки bmp-формата с определенной частотой.

Вопрос - почему такой огромный поток от камер? Без сжатия что ли? Нет денег на разработку IP-камеры? Да и на дисках будет быстро исчерпываться место.

нууу... прозрачнее - да, но безсбойнее - я бы так не сказал. Смотря кто к этому линуксу приложит руки ...

P.S.: сорри - о камерах понял. Просто Вы дописали пока я пыталСО отправилть сообщение с этого самого глючного форума рунета. Хотя и не понял зачем такая система ...

P.P.S.: тогда еще подвопрос - а в чем собственно вопрос? Четырехядерник, мощная видяха с CUDA и вперед...

P.P.P.S.: это диплом?

Кадры передаются без предварительного сжатия, это данность. 10 камер не смогут работать по одному сетевому кабелю одновременно - нужно несколько 100Мбитных сетевых интерфейсов + хорошая вычислительная способность устройства сбора данных + достаточный объем жесткого диска (запись на жесткий диск будет производиться не все время, а по наступлению определенного события) + физическая недоступность - поэтому я решил использовать для построения системы отдельный видеосервер.




Вопрос в том - как организовать программную начинку видеосервера?

Это не диплом...

UPD: Что скажете про ОС QNX?

Задача поставлена неверно (несжатый поток как минимум), и если камеры заменить нельзя то я Вам сочувствую.
10 интерфейсов в сервер теоретически воткнуть возможно но это очень теоретически и в очень не любой сервер, прощще и правильнее взять гигабитный свич - должно хватить даже с учето оверхеда, которого будет немало. На сервере потоки нужно жать иначе прийдется городить оооочень нехилый дисковый массив. С учетом этого берите максимальный доступнйс сервер и всеравно будет мало ;-) 4xЗеон это минимум.

По оси все просто - использовать то под что умеют писать программиты которые будут разрабатывать софт.

10 сетевых интерфейсов не требуется. Количество камер не превышает 10, но пока на деле будет использоваться 6 - 2 интерфейсов будет достаточно+1 интерфейс под оператора. Запись на диск будет производиться тоже не все время, а при наступлении определенного события, которое на практике случается не так уж и часто, запишется некоторое количество кадров.



Как совместить 1Гб оптику и 100Мб камеру?

А зачем оптика? Нет, ну если нужно то можно и оптику конечно. Не вижу или непонял проблемы.
Берете любой гигабитный свич (10/100/1000 порты) и всех делов. Можно взять скажем 14x100 + 2x1000 свич но он может оказаться дороже чем 16x1000. Порты в которых камеры будут работать на 100, порт в котором гигабитная сетевуха сервера соответствекнно на 1000
Если нужно оптику то соответственно свич с оптическим портом или gbic, но это пустая трада денег (в задаче вроде ничего требований под которые была бы нужна оптика)

А если камеры пространственно разнесены на сотни метров? =)

+1!
Только добавлю, что найти людей под QNX и Windows(для этих целей) будет сложнее. А насчет самой QNX никогда с ней не работал, но Вы превратно трактуете REAL TIME OS - "не даст подтормаживать" не равно "заработает быстрее" ...


эээ...а какая связь тут со скоростью сети?

Да какая разница, я же описал - свич с портами под нужную среду, хоть медь, хоть оптика. И кстати применение свича добавит гибкости в смысле топологии

Именно, как вы программно это организуете?
С этого надо начинать, а не с проблем интерфейсов или оси.
Нужен движок типа DVR но не DVR.
Вместо видео будут кадры и их надо как-то превратить в видео как я понял и сопроводить служебной информацией о дате, канале, объеме, месте хранения и т.д.
Служебная информация будет понятно в MySQL сервере, а сами кадры или видеофайлы сделанные из кадров будут храниться где-то на RAID-е в файлах( а может поля BLOB в SQL сервере применить или тип FILESTREAM в MS SQL 2008?)
И нужна еще неслабая GUI оболочка.

Писать такой софт - гемор высшей пробы. Здесь только винды подойдут с RAD тулсами.

С другой стороны можно попытаться заюзать готовые DVR движки, но им надо подать уже конвертированный понятный им видеопоток.

Можно сделать еще аппаратный конвертер (несложно, кстати) к каждой камере или один на несколько камер для трансформации потока в IPTV скажем для стандартного DVR-а