>> А во сколько раз менее производительное ядро? ну для телефона потянет, может быть домашний роутер.
> Вообще сказать сложно. Нужно подождать более полных бенчмарков. Сам AMD публиковал только
> SPECint_rate, 80 на 8-ми ядерный процессор или 10 на ядро. Результаты
> для младших Xeon E3 можно глянуть тут http://jp.fujitsu.com/platform/server/primergy/performance/p...
> (90 для E3-1220L - у которого TDP 20W у старого или
> 17W у V2). Т.е. в голом SPECint выигрыша при TDP нет,
> как и проигрыша по производительности по сравнению с low-power E3, но
> доп. криптоакселератор для кучи всего (у E3 только AES) и все,
> что встроенно в SoC и его тепловыделение дают выигрыш. Плюс сами
> знаете, сколько памяти реально в E3 воткнуть с его UDIMM'ами..Только K-Cluster имени фуджиков - живет далеко не на ARM. в октябре во всяком случае было так.. железка из top10.. точно ранк не помню.
Криптоакселератор - он в целом как мертвому припарка - хорошо что есть, но нужен весьма и весьма специфических нагрузках.
>> Странный у вас кластер.
> Hadoop/HBase, упирающийся в диски и в объем памяти, а также во внутренние
> особенности HBase, заставляющие выделять отдельные машины для особо горячих регионов.
> Нет, если сдуру включить какое-нибудь gzip сжатие, можно благополучно упереться в
> проц, но зачем?
Я думал gzip используют что бы уйти от этих самых узких мест.. Как и btrfs/zfs/reiserfs - которые сжимали данные для ухода от узкого горлышка в передаче с винтов.. А вас оказывается это узкое горло не волнует.. Лишь бы CPU простаивало.
>> Стораджи на 20P там есть?
> Ааа, так у вас общие сторейджи, вот зачем 40G сеть. Не, это
> не наш метод. Еще небось резервирование для него в копеечку выйдет.
> Диски на каждой ноде в JBOD и Hadoop поверх этого -
> и можно масштабировать объем без нужды в 40G сети.
не получится. Hadoop в общем виде не умеет RDMA по сети. Некоторые реализации ISCSI это могут - но далеко не все. А 40GigE нужен просто для маштабируемости - когда у тебя тысяч 30 клиентов..
> Big Data по чистому объему может и не очень Big, но по
> подходу вполне себе. В смысле, методы обработки только такие уже работают.
> А объем, он растет )
Подходы у них весьма странные. На счет только такие и работают - расскажите это ORNL, LLNL, Sandia.gov.. у них почему-то работают другие :-) причем даже в метеорологии - где часто используется ала Hadoop - уже по тихоньку другой метод используют.
PS. Когда там Хадуп научится версионности объектов? что бы не требовалось сохранять копию объекта при чтении клиентом
