[Gemm 0]

собственно сабж

[aaarrr 63]

Marvell PXA320, TI OMAP35x, Freescale i.MX31.

 

Но вопрос так можно ставить разве что в "кампьютерном" форуме. Что именно нужно от процессора?

[IgorKossak 0]

... вопрос так можно ставить разве что в "кампьютерном" форуме....

Или при жгучем желании получить предупреждение за попытку разжигания очередной религиозной войны.

Вопрос желательно конкретизировать.

 

Модератор.

[Gemm 0]

Или при жгучем желании получить предупреждение за попытку разжигания очередной религиозной войны.

Вопрос желательно конкретизировать.

 

Модератор.

 

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

 

У нас есть плата на базе SAM9263 (240 МГц). На плате поднят сетевой стек lwip. По нему плата получает графику, декодирует ее и отправляет на видео систему, реализованную на ПЛИС. Пока скорость работы устраивает, но в следующем поколении платы хотелось бы заложить более быстрый проц, если такой существует. Почему сейчас используем Атмел? - исторически так сложилось, возможно это и не совсем подходящий для задачи проц.

 

Но вопрос так можно ставить разве что в "кампьютерном" форуме.

Почему??? Поясните, пожалуйста...

[aaarrr 63]

Почему??? Поясните, пожалуйста...

Потому что это -

Я спросил про скорость, подразумевая мегагерцы его процессорного клока или мипсы. Не это ли основной показатель скорости его работы? Как еще можно понять мой вопрос???

- не основной показатель скорости работы. Скажем, если Вы занимаетесь обработкой видео, то OMAP и i.MX могут оказаться предпочтительнее Marvell'а несмотря на меньшее количество "попугаев".

 

Без привязки к задаче вопрос не имеет смысла.

[zltigo 0]

Почему??? Поясните, пожалуйста...

Для начала ARM7, ARM9, ARM11,....

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

Если Вы тоже причисляете себя к собравшимся, то не сочтите за труд вопросы задавать тоже грамотно.

[Gemm 0]

Потому что это -

 

- не основной показатель скорости работы. Скажем, если Вы занимаетесь обработкой видео, то OMAP и i.MX могут оказаться предпочтительнее Marvell'а несмотря на меньшее количество "попугаев".

 

Без привязки к задаче вопрос не имеет смысла.

 

Что значит "могут оказаться..", по каким причинам? Я же описал задачу. TCP/IP стек (физикл RTL8201) + разпаковка полученных данных (никаких операций с плавающей точкой) + отправка их по 32-разрядной шине в ПЛИС.

 

Для начала ARM7, ARM9, ARM11,....

 

Если Вы тоже причисляете себя к собравшимся, то не сочтите за труд вопросы задавать тоже грамотно.

Что ARM7, ARM9, ARM11,....? В вашем предложении нет ни подлежащего, ни сказуемого. Если вы просите уточнить семейство, то я не знаю... Я поэтому и задаю вопрос относительно скорости АРМов в целом. До этого работали с 9м, поэтому имеется куча наработок и опыта по работе с ним.

[aaarrr 63]

Что значит "могут оказаться..", по каким причинам?

По причине различного набора ускорителей в периферии.

 

Я же описал задачу. TCP/IP стек (физикл RTL8201) + разпаковка полученных данных (никаких операций с плавающей точкой) + отправка их по 32-разрядной шине в ПЛИС.

Это не описание: какой поток на входе и выходе, что представляет собой распаковка?

[Gemm 0]

По причине различного набора ускорителей в периферии.

Это не описание: какой поток на входе и выходе, что представляет собой распаковка?

 

Поток на входе непостоянный. От сетки удалось выжать 60 Мбит. В самом тяжелом случае вся эта информация - графическая. Компрессор - LZO, никаких аппаратных фич для распаковки пока нет.

 

А вот если не принимать во внимание распаковку, просто сырые данные принимают по сети - и уходят на ПЛИС... Просто требуется максимальная скорость от стека! Вот!

[blackfin 16]

Че тут гадать.

[AlexandrY 3]

Эт че вы по локалке на видеопотоке сумели выжать только 60 Mbit?

И это на проце с шинной матрицей и выделеным DMA на MAC контроллере.

Ну так я вам скажу у вас проблема не в проце, а в софте.

 

Тут никакой скоростной проц не поможет.

Скорость AHB шины даже у процов с вдвое большей скростью ядра практически остается той же.

 

А стек lwip по сути не годен для скоростных решений поскольку в нем нет технологии zero copy насколько знаю.

 

 

 

 

Поток на входе непостоянный. От сетки удалось выжать 60 Мбит. В самом тяжелом случае вся эта информация - графическая. Компрессор - LZO, никаких аппаратных фич для распаковки пока нет.

 

А вот если не принимать во внимание распаковку, просто сырые данные принимают по сети - и уходят на ПЛИС... Просто требуется максимальная скорость от стека! Вот!

[Gemm 0]

Эт че вы по локалке на видеопотоке сумели выжать только 60 Mbit?

И это на проце с шинной матрицей и выделеным DMA на MAC контроллере.

Ну так я вам скажу у вас проблема не в проце, а в софте.

 

Тут никакой скоростной проц не поможет.

Скорость AHB шины даже у процов с вдвое большей скростью ядра практически остается той же.

 

А стек lwip по сути не годен для скоростных решений поскольку в нем нет технологии zero copy насколько знаю.

 

Ну да, 60 Мбит... С включенным кешем инструкций и данных. Без кешей еще меньше было. DMA на MACе спользуется, bus matrix не трогали. MAC складывает полученные пакеты в SDRAM, шина на 100 МГцах.

 

А какой стек пригоден? По моему, lwip наиболее перспективный... возможно, ошибаюсь.

 

Спасибо за дельный комментарий. )

[aaarrr 63]

А стек lwip по сути не годен для скоростных решений поскольку в нем нет технологии zero copy насколько знаю.

У lwip есть no-copy API, вопрос только, используется ли он автором топика.

 

Ну да, 60 Мбит... С включенным кешем инструкций и данных. Без кешей еще меньше было. DMA на MACе спользуется, bus matrix не трогали. MAC складывает полученные пакеты в SDRAM, шина на 100 МГцах.

Система в подобной конфигурации (200MHz ARM9, 100MHz bus) вполне нормально забивала под завязку 100-мегабитный канал под линуксом.

 

Так что виноват стек, если, конечно, LZO и общение с FPGA не слишком сильно грузят процессор.

[Gemm 0]

У lwip есть no-copy API, вопрос только, используется ли он автором топика.

Система в подобной конфигурации (200MHz ARM9, 100MHz bus) вполне нормально забивала под завязку 100-мегабитный канал под линуксом.

 

Так что виноват стек, если, конечно, LZO и общение с FPGA не слишком сильно грузят процессор.

 

 

no-copy API не используем. 60 Мбит - это без LZO и без общения с FPGA, только прием данных по сети.

[aaarrr 63]

Тогда есть над чем работать. Решать проблему использованием более скоростного процессора, ИМХО, в корне неверно.