Представлен (http://fedoramagazine.org/fedora-21-for-aarch64/) релиз дистрибутива Fedora 21 (http://www.opennet.me/opennews/art.shtml?num=41221) для серверных систем с 64-разрядной архитектурой ARMv8/AArch64 (https://ru.wikipedia.org/wiki/ARM_%28%D0%B0&#.... Сборки для Aarch64 содержат все возможности, доступные в базовом наборе пакетов Fedora 21 Base и в варианте дистрибутив для серверных систем Fedora 21 Server. Из репозиториев для Aarch64 доступно более 15 тысяч пакетов. Среди поддерживаемых платформ отмечены (https://fedoraproject.org/wiki/Architectures/AArch64/F21/Ins... платы Applied Micro X-Gene (Mustang)
и Advanced Micro Devices Opteron A1100 (Seattle), а также эмулятор (https://fedoraproject.org/wiki/Architectures/AArch64/Install... на основе QEMU.URL: http://fedoramagazine.org/fedora-21-for-aarch64/
Новость: http://www.opennet.me/opennews/art.shtml?num=41434
armv8/aarch64 -- первая версия ARM-систем, которые будут нормально поддерживаться линуксами (дистрибутивами)..это несомненно хорошо!
(в отличии от прошлых версий ARM, для которых не было линуксовой поддержки, но были отдельные сборки линуксов под конкретные модели)
# P.S.: http://ru.fedoracommunity.org/content/arm64-%D1%82...
А перечисление нескольких вполне конкретных железок - благородного дона не смутило?
не смутило.я с таким же успехом могу перечислить парочку вполне конкретных моделей Dell и Lenovo, которые x86-компьютеры.
Да с твоим уровнем компетенции хоть ссы в глаза - все божья роса.
> (в отличии от прошлых версий ARM, для которых не было линуксовой поддержки,На ARM только линуксы и крутятся. А свое UEFI и ACPI оставьте себе. Мы этого дepьмища на х86 уже наелись. С кучей глюков blob-only фирмвари, заточенной исключительно под маздай.
>> (в отличии от прошлых версий ARM, для которых не было линуксовой поддержки,
> На ARM только линуксы и крутятся. А свое UEFI и ACPI оставьте
> себе. Мы этого дepьмища на х86 уже наелись. С кучей глюков
> blob-only фирмвари, заточенной исключительно под маздай.Распери, распери, распери - blob-only фирмвари, blob-only фирмвари, blob-only фирмвари.
Коккккоооо.
А тут обитают совсем смешные :)
> На ARM только линуксы и крутятся.говнецо с кастомными патчами (наложенными на устаревшее ядро) -- даже стыдно называть линуксом. Сборка от Вована это наверное ближе к ZverDVD чем к Линуксу :-) ..
> С кучей глюков blob-only фирмвари, заточенной исключительно под маздай.
на x86 -- глюков раз в 9000 меньше чем на ARM. можешь хоть весь пеной весь изойтись -- но это факт.
хотя производители Армов -- не слепые и вполне видят эту ситуацию. поэтому и начали этот переход на UEFI и на ACPI.
> Мы этого дepьмища на х86 уже наелись.
наелся на x86 ? ну давай, попробуй теперь системы arm (версии 7 и младше) -- только изврашенцу оно может показаться нормальным.
если ты так ругаешь x86, то очевидно что ARM ты вообще видал только на картинках. :-)
> гoвнецо с кастомными патчами (наложенными на устаревшее ядро) -- даже стыдно называть
> линуксом. Сборка от Вована это наверное ближе к ZverDVD чем к Линуксу :-) ..То ли дело блобы уефи с троянами и секурбутами и апи от индусов интеля и микрософта, которые они левой пяткой писали. Там разработчики по пять версий ядер к ряду пытаются заворкэраундить глюки проприетарной фирмвари без сорца. Спасибо, я уже видел как это индусское дepьмище у меня на ноуте сделано. Как-то конечно заворкэраундили. Всего 3 года долботни - и даже как-то работает вроде. Хоть и сыпет варнингами на кривой биос в дмесг.
Если из арма делать такое же дepьмо - зачем он тогда нужен? Тебе мало х86 чтоли?
> на x86 -- глюков раз в 9000 меньше чем на ARM.
А ты наглец, паря. У меня если что есть и х86 железки и армовские платки. И уж смею тебя заверить - от опенсорсного u-boot проблем ровно ноль. А вот ACPI из проприетарного биоса - адский кластерфак. Ну то что там сорцами на реализацию и не пахнет - думаю понятно. Так еще и спекам никто не следует. Действуют по принципу "винда вроде грузится". Зашибись подход. А в уефанстве меня вообще от моего компа отгородили секурбутом. Так что все должны минет микрософту делать, чтобы те им загрузчик вообще подписали. А не будут подписывать - будешь кушать одни винды. Или как на некоторых машинах - есть огромный ассортимент: ты можешь выбрать из винды и редхата. Больше вариантов видите ли тамошний уефи не предусматривает.
> можешь хоть весь пеной весь изойтись -- но это факт.
Я исхожу пеной лишь на факт наглых подтасовок. Ты б для начала посмотрел что про это пишет хоть тот же Мэтью Гарретт, а потом разевал свой рот с твоим мегакомпетентным мнением.
> и начали этот переход на UEFI и на ACPI.
И чем это будет лучше x86? Такой же глюкавый проприетарный биос без сорцов и секурбут где с ножом к горлу будут насаждать доверие к MS? Ну вот вы этим и пользуйтесь, спасибо.
> наелся на x86 ? ну давай, попробуй теперь системы arm (версии 7
> и младше) -- только изврашенцу оно может показаться нормальным.Так я уже. У меня есть несколько платок. Ну да, там с ядрами могут быть некоторые особенности. Но я лучше с ними разбираться буду чем с той жестью которая в ACPI/UEFI.
> Ну да, там с ядрами могут быть некоторые особенности. Но я лучше с ними разбираться буду чем с той жестью которая в ACPI/UEFI.так называемая "жесть" (с ACPI/UEFI) -- может случиться при покупке железки -- с вероятностью примерно в-одной-из-десяти моделей железок.
а вот ковыряться с "особенностями" (как ты пишешь, нада же какое красивое слово "особенности"!) -- ковыряться с особенностями ARM и uboot -- нужно ИНЛИВИДУАЛЬНО С КАЖДОЙ моделью arm-железки.
уверенность по поводу того что x86-железка сходу заработает -- обычно настолько высока, что люди могут покупать их без предварительного прогугливания!
а вот геморой изучения (и гугления) arm-железок -- наступает ещё даже до момента покупки железки.
так-что -- нет -- ситуация с ACPI/UEFI намного лучше, чем эти ваши "особенности" с ядром.
но за каким-то чёртом к x86-железкам вы выставляете незнай какие жёсткие требования безглючной работы! а вот если arm-платка подглючивает или имеет чрезмено-костыльный способ загрузки -- то тут вроде как ни чего особо страшного -- ей можно..
провозился с x86-компьютером 4 лишних часа -- "пипец какая жесть"!
а провозился полторы недели с arm-платой -- "ни чего страшного, просто была особенность связанная с ядром и нестандартным uboot"
(как всегда эта ваша элитарно-линуксоидная двуличность!)
> что про это пишет хоть тот же Мэтью Гарретт
всю его песанину можно вкрадце рассказать как: переход производителей на UEFI был тежёлым и не безболезненным.
ну и что? ну тяжело было. но ни кто в результате не умер. современные реализации UEFI -- вполне себе пережили свои детские недоразумения.
> будут насаждать доверие к MS
существует ряд телефонов (с arm-процессорами) -- где без всякого MS идёт "насаживание доверия" к определённой подписанной linux-пошивке.
насаживать оказывается можно и без UEFI (и без MS).. вот тык сюрприз, да? патчить для этих целей uboot тоннами патчей -- компаниям ни кто не запретил (и они это делают если хотят).
а вот проверять цифровую подпись у универсальных arm-плат (не телефоны) -- нет совершенно ни какого смысла. ни в случае UEFI, ни в случае отсутствия UEFI.
> так-что -- нет -- ситуация с ACPI/UEFI намного лучше, чем эти ваши "особенности"Сколько Вам раз советовал -- сперва руками пощупайте, потом сравнивайте... паршивая с ними ситуация, как и с любым подобным оверинженегрингом.
> для серверных систем с 64-разрядной архитектурой ARMv8/AArch64Кто-нибудь их видел/трогал?
> Среди поддерживаемых платформ отмечены платы Applied Micro X-Gene (Mustang)
> и Advanced Micro Devices Opteron A1100 (Seattle)2 платы??? Они хоть в продаже есть?
>2 платы??? Они хоть в продаже есть?Applied Micro X-Gene (Mustang)
- Development Kit Basic $1495
- Development Kit Plus $2495
>>2 платы??? Они хоть в продаже есть?
> Applied Micro X-Gene (Mustang)
> - Development Kit Basic $1495
> - Development Kit Plus $2495Эээ ... как бы ... "Development Kit" и "серверная платформа" не совсем одно и то же. Возможно, различие трудно уловить, но тем не менее :-)
>Эээ ... как бы ... "Development Kit" и "серверная платформа" не совсем одно и то же. Возможно, различие трудно уловить, но тем не менее :-)Понимаю. Но пока только так.
> Applied Micro X-Gene (Mustang)
> - Development Kit Basic $1495
> - Development Kit Plus $2495Выражение "конские цены" приобретает новый смысл :).
> 2 платы??? Они хоть в продаже есть?обратного ходу нет. рано или поздно вся ARM-продукция перейдёт на Восьмую версию.
> обратного ходу нет. рано или поздно вся ARM-продукция перейдёт на Восьмую версию.Чушь полная, до сих пор полно чахлых "старых" армов под задачи, где много и не надо.
сейчас много. да.я же про будущее писал, а не про "сейчас".
учитывая что их энергопотребление сильно похоже на ксеоны.. то видится слабый смысл этой железки.
Их энергопотребление (производительность/ватт) в некоторых задачах до двух раз меньше, а главное - цена намного меньше. В отличие от текущих ARM'ов, там есть поддержка ECC, значит на них можно выполнять уже реальные серверные задачи, требующие не топовой производительности, но более нормальной надежности, чем текущие решения на ARM.Но главное - цена решений с поддержкой большого объема памяти и 10GbE в несколько раз меньше, чем при сборке аналогичной на Xeon. Подсчитайте сами, сколько стоит плата+процессор на Xeon с поддержкой 128Gb памяти и 10GbE интерфейсами. Да, у Intel есть аналог этого ARM по цене и TDP (серверная "атомная" платформа Avoton / Rangeley), но там в отличие от этих ARM'ов нет поддержки RDIMM, а сколько памяти у вас получится набрать четырьмя UDIMM'ами? И сколько это будет стоить..
Для кластера Hadoop эти ARM - вообще конфетка. А бонусом (если мы про текущее решение от AMD) - встроенный в SoC SCP (поддержка IPMI с KVM без доп. расходов и чипов), криптографический процессор (акселерация AES/SHA/ECC криптографии, zlib сжатия/распаковки, генератор случайных чисел). Из-за того, что это все встроено линии PCIe освобождаются - сравните с Avoton, сколько там их доступно остается на реальных платах, когда все необходимые контроллеры стоят...
В общем, сравнение с Xeon некорректное - понятно, что он мощнее, но общее решение, когда стоят все контроллеры выходит намного дороже и горячее (если сравнивать не TDP голого процессора Xeon vs ARM SoC, а всего, что есть на плате там и там). Но ключевое слово тут - дороже. А производительность Xeon очень много где уже не нужна, с внедрением кластеров. Им обычно нужен IO до нескольких дисков, побольше памяти и быстрая сеть. Иногда только побольше памяти и быстрая сеть. Xeon тут дороговато выходит. А старые ARM, не предназначавшиеся для серверов - вообще не конкурент в этих задачах, т.е. никаким местом они не обеспечат требования по работе с памятью и сетью. Это решение в первую очередь конкурирует с серверными атомами от Intel, но по многим параметрам интереснее их.
> IPMI с KVM без доп. расходов и чипов),Неотрываемый бэкдор - это круто. Светлая незамутненная радость папуаса, обменявшего чушку золота на бусы из стекла.
> криптографический процессор (акселерация AES/SHA/ECC криптографии, zlib
> сжатия/распаковки, генератор случайных чисел).И мы на слово поверим что криптография и случайные числа там честные. Ведь проверить это мы никак не сможем...
> того, что это все встроено линии PCIe освобождаются -
Сомнительное достоинство. PCI-e обладает некоей плагнплейностью - сканирование шин найдет все девайсы, можно вгрузить все модули и прочая. А если это отдельная кастомная железка на кастомной шине - добро пожаловать в мир ядер собранных под конкретную железку.
> решение в первую очередь конкурирует с серверными атомами от Intel,
Ждем мобильную версию ксеона, чтоли :)
>> IPMI с KVM без доп. расходов и чипов),сейчас это дополнительный мелкий ARM..
>> криптографический процессор (акселерация AES/SHA/ECC криптографии, zlib
>> сжатия/распаковки, генератор случайных чисел).
> И мы на слово поверим что криптография и случайные числа там честные.
> Ведь проверить это мы никак не сможем...к слову в ксеонах все это есть - что пытаются этим показать? ECC вообще как к криптографии?
Самое ценное что я видел в серверных армах - это async DMA с поддержкой raid 6 offload.
что бы не считать P-Q на чипе, хотя все равно это быстрее на ксеоне выходит.
> Неотрываемый бэкдор - это круто. Светлая незамутненная радость папуаса, обменявшего чушку золота на бусы из стекла.Что значит неотрываемый, стандарт IPMI как бы подразумевает возможность настройки или отключения части функциональности. ipmitool в помощь. Да и в реальности он все равно нужен - пусть лучше будет встроен.
> И мы на слово поверим что криптография и случайные числа там честные. Ведь проверить это мы никак не сможем...
Про fipscheck не слышали? С чего вы вообще решили, что "честность" случайных чисел не проверяется? Давно придумана куча способов, начиная от примитивного "бросания иголоки в квадрат со вписанной окружностью" и заканчивая сложными методиками FIPS.
> Сомнительное достоинство. PCI-e обладает некоей плагнплейностью - сканирование шин найдет все девайсы, можно вгрузить все модули и прочая. А если это отдельная кастомная железка на кастомной шине - добро пожаловать в мир ядер собранных под конкретную железку.
Велосипеды никто не изобретает, отдельные элементы SoC управляются какой-либо стандартной шиной (типа LPC, I2C и т.д. либо просто на линии прерывания - не в курсе деталей, как это сейчас чаще делают), висят на своем адресном пространстве и их можно инициализировать/сбросить/просканировать без проблем. А то, что для поддержки SoC требуется специфический код.. ну да. Вам шашечки или ехать, в смысле минимум кода или низкое тепловыделение?
> Ждем мобильную версию ксеона, чтоли :)
Так серверные атомы туда и метили. Но - память UDIMM, сеть внешняя и прочие нюансы, в общем Opteron 1100 намного интереснее смотрится.
> Про fipscheck не слышали? С чего вы вообще решили, что "честность" случайныхИмелась ввиду rngtest, fipscheck проверяет другое (увидел в man'е FIPS 140-2 и написал, не читая его дальше, сорри).
> Их энергопотребление (производительность/ватт) в некоторых задачах до двух раз меньше,Те внутренние презентации что я видел - говорят о обратном. Для типового использования в серверах - TDP у арма сравнимого с ксеоном по производительности - очень сравнимо.
> , значит на них можно выполнять уже реальные серверные задачи, требующие не топовой производительности, но более нормальной надежности, чем текущие решения на ARM.
Вы хоть один сервак в котором CPU простаивает видели? пользователи почему-то стараются выжать все что можно из купленого. А место в датацентрах - стоит не дешево. Так что давайте будем еще считать цену объема который надо как-то арендовать.
> Но главное - цена решений с поддержкой большого объема памяти и 10GbE в несколько раз меньше, чем при сборке аналогичной на Xeon.
10GigE уже не интересно. 40GigE - да, вполне себе меланокс/броадком.
> Да, у Intel есть аналог этого ARM по цене и TDP (серверная "атомная" платформа Avoton / Rangeley)
Кто вам говорил что я сравниваю с решениями от интела? Есть и другие производители - кроме amd, intel.
> А производительность Xeon очень много где уже не нужна, с внедрением кластеров.Расскажите это Cray, Bull, HP и вообще HPC ... они дружно посмеются. И инвесторам расскажите - когда выяснится что для кластера нужно арендовать лишнее здание. Ибо производительность на единицу объема оказалась ниже чем у конкурентов.
Странно что вы вспоминаете PCI-E хотя все внутренние шины и память - сидят на HT.
собственно единственный плюс ARM это возможно конфигурирования ядра под что надо, где-то что-то обкусил - тут добавил. Но все остальное - чистый маркетинг.
> Те внутренние презентации что я видел - говорят о обратном. Для типового
> использования в серверах - TDP у арма сравнимого с ксеоном по
> производительности - очень сравнимо.Xeon не масштабируется вниз, особенно с сохранением адекватности цены. Еще раз, 25W потребление на 8 ядер - со 128 Гб памяти и 2x 10GbE (без учета потребления памяти и физики сети, конечно) - Xeon такое не может. Кластеры на Xeon будут жрать больше и стоить дороже.
>> , значит на них можно выполнять уже реальные серверные задачи, требующие не топовой производительности, но более нормальной надежности, чем текущие решения на ARM.
> Вы хоть один сервак в котором CPU простаивает видели? пользователи почему-то
> стараются выжать все что можно из купленого. А место в датацентрах
> - стоит не дешево. Так что давайте будем еще считать цену
> объема который надо как-то арендовать.Постоянно вижу простаивающие ядра, в отличие от диска и сети. Равно как и кучу серверов, нагрузку на которые не увеличить, т.к. упираешься в объем памяти. Вообще зависит от задачи.
>> Но главное - цена решений с поддержкой большого объема памяти и 10GbE в несколько раз меньше, чем при сборке аналогичной на Xeon.
> 10GigE уже не интересно. 40GigE - да, вполне себе меланокс/броадком.Кому как. Множеству кластеров более чем достаточно. Да и решения с 40G портами в копеечку выйдут. А 10G тут уже есть.
>> Да, у Intel есть аналог этого ARM по цене и TDP (серверная "атомная" платформа Avoton / Rangeley)
> Кто вам говорил что я сравниваю с решениями от интела? Есть и
> другие производители - кроме amd, intel.И какие же производители серверных платформ есть еще?
Т.е. я конечно знаю про них, но они не в сегменте "маложрущую железку для кластера по минимальной стоимости".>> А производительность Xeon очень много где уже не нужна, с внедрением кластеров.
> Расскажите это Cray, Bull, HP и вообще HPC ... они дружно посмеются.
> И инвесторам расскажите - когда выяснится что для кластера нужно арендовать
> лишнее здание. Ибо производительность на единицу объема оказалась ниже чем у
> конкурентов.Расскажите это Google, Facebook, Twitter и всем остальным игрокам рынка Big Data. Про то, что бывают железки для обработки данных, которые могут заменить кластер. Смеяться будут долго.
> Странно что вы вспоминаете PCI-E хотя все внутренние шины и память -
> сидят на HT.Я говорю про возможность подключения переферии. Тот же 40G контроллер, если приспичит, в HT будете втыкать?
>>> А производительность Xeon очень много где уже не нужна, с внедрением кластеров.
>> Расскажите это Cray, Bull, HP и вообще HPC ... они дружно посмеются.Особенно Cray, у которого машин под одним образом ОС нынче раз-два и обчёлся, не то что в былые времена.
> Расскажите это Google, Facebook, Twitter и всем остальным игрокам рынка Big Data.
Человек с оттопыренной губой, рассуждавший про объёмы выше, может рассказать хорошей фирме Sun всё, что захочет... при встрече.
PS: к HPC причастен в объёме "держал ведёрко краски для #12/top500", не бейте, дяденьки.
> Особенно Cray, у которого машин под одним образом ОС нынче раз-два и обчёлся, не то что в былые времена.Да ну? а мои логи говорят об обратном... правда они ушли от суси на RHEL based. но вполне себе живут на собственной сборке. Хотя зоопарк там еще тот.
> PS: к HPC причастен в объёме "держал ведёрко краски для #12/top500", не бейте, дяденьки.
Да да. я помню.. T-Platform и все такое..
> Да ну? а мои логи говорят об обратном...О том, что Cray возвращается от кластеров на преимущественно COTS hardware к своим уникальным железкам? Вот это новость, рассказывайте!
>> Да ну? а мои логи говорят об обратном...
> О том, что Cray возвращается от кластеров на преимущественно COTS hardware к
> своим уникальным железкам? Вот это новость, рассказывайте!Для вас новость - что для сети крей и не переставал использовать свое железо ? сначала SeaStar а потом Aries? Power7 и все дела. Сейчас еще добавился Nvidia Tesla в каком-то custom виде, и тп. Даже материнки у Крея всегда были странные и не стандартные - требующие "специальной" сборки ядра.
>> О том, что Cray возвращается от кластеров на преимущественно COTS hardware
> Для вас новость - что для сети крей и не переставал использовать свое железо ?Возможно, написал недостаточно кристально ясно -- но вроде же очевидно, что не про интерконнект, а про базовую платформу. По крайней мере Вам. :)
смотря что вы вкладываете в базовую платформу? CPU?
> Xeon не масштабируется вниз, особенно с сохранением адекватности цены. Еще раз, 25W потребление на 8 ядер - со 128 Гб памяти и 2x 10GbE (без учета потребления памяти и физики сети, конечно) - Xeon такое не может. Кластеры на Xeon будут жрать больше и стоить дороже.А во сколько раз менее производительное ядро? ну для телефона потянет, может быть домашний роутер.
А остальное увы. К слову - какое соотношение производительности к формфактору? а то ведь датацентры тоже что-то стоят. Я не зря намекал что если у вас 25W съедают теже 1U что 120W и так же соотносятся по производительности - то будет не удобно.
> Постоянно вижу простаивающие ядра, в отличие от диска и сети. Равно как и кучу серверов, нагрузку на которые не увеличить, т.к. упираешься в объем памяти. Вообще зависит от задачи.Странный у вас кластер.
> И какие же производители серверных платформ есть еще?
А это знаете ? http://www.broadcom.com/press/release.php?id=s797235
Я к слову перечислял его.> Расскажите это Google, Facebook, Twitter и всем остальным игрокам рынка Big Data. Про то, что бывают железки для обработки данных, которые могут заменить кластер. Смеяться будут долго.
Расскажу. Когда в очередной раз прийдут за дисковыми полками. Хотя BigData - по факту выглядит не очень Big..
Стораджи на 20P там есть? или там HSM - когда все что не сильно нужное уходит на ленточки.. ?
> А во сколько раз менее производительное ядро? ну для телефона потянет, может быть домашний роутер.Вообще сказать сложно. Нужно подождать более полных бенчмарков. Сам 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'ами..
> Странный у вас кластер.
Hadoop/HBase, упирающийся в диски и в объем памяти, а также во внутренние особенности HBase, заставляющие выделять отдельные машины для особо горячих регионов. Нет, если сдуру включить какое-нибудь gzip сжатие, можно благополучно упереться в проц, но зачем?
> Я к слову перечислял его.
Ааа так вы про ARM64. Ну с этим просто не успел познакомиться. Понятно, что там еще должны быть игроки. Это хорошо.
> Стораджи на 20P там есть?
Ааа, так у вас общие сторейджи, вот зачем 40G сеть. Не, это не наш метод. Еще небось резервирование для него в копеечку выйдет. Диски на каждой ноде в JBOD и Hadoop поверх этого - и можно масштабировать объем без нужды в 40G сети.
Big Data по чистому объему может и не очень Big, но по подходу вполне себе. В смысле, методы обработки только такие уже работают. А объем, он растет )
>> А во сколько раз менее производительное ядро? ну для телефона потянет, может быть домашний роутер.
> Вообще сказать сложно. Нужно подождать более полных бенчмарков. Сам 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. Когда там Хадуп научится версионности объектов? что бы не требовалось сохранять копию объекта при чтении клиентом
> Криптоакселератор - он в целом как мертвому припарка - хорошо что есть, но нужен весьма и весьма специфических нагрузках.Он там довольно универсальный, с акселерацией SHA и zlib например, это много где в обычных задачах может всплыть. Понятное дело, это далеко не то же самое, что плата акселератора для спец. задач - просто специальные инструкции процессора позволяют ускорять определенный код. Не все ж specint считать, нужно и реальный код запускать.
> Я думал gzip используют что бы уйти от этих самых узких мест
gzip слишком уж все кладет. lzo дает очень хорошее сжатие и не грузит проц, а gzip просто забесплатно сожрет +10 ядер на той же нагрузке. А эффективности сжатия и ввода-вывода почти не добавит. Кроме того, на практике в HBase можно дизайнить таблицы так, чтобы получать эффект от fastdiff (префиксного сжатия), после него дожать что lzo, что gzip - одна фигня.
> Hadoop в общем виде не умеет RDMA по сети
В общем виде ему и не нужно, при правильном проектировании он обеспечивает локальность данных. А пересылки по сети только чтобы поддерживать распределенные копии (т.е. внутренние механизмы) и при изменении места хранений какой-то копии, чтобы данные оказались там, где обрабатываются. Хотя это плохой сценарий и такого не должно быть много, нужно обработку перемещать туда, где данные, а не данные, где обработка. Но даже при перемещении данных для конкретной задачи это будет однократно. Т.е. реальная обработка будет идти сразу с локальными данными (в идеале) или через некоторое время (при проблемах проектирования), и как там загружается сеть и с какими задержками, не имеет значения.
> Подходы у них весьма странные. На счет только такие и работают
Я не говорил, что только такие и работают. Но у кучи очень крупных компаний такой или аналогичный подход и он работает - на очень больших кластерах.
> PS. Когда там Хадуп научится версионности объектов? что бы не требовалось сохранять копию объекта при чтении клиентом
Не знаю, я не в курсе такой проблемы. В HBase очень мощная версионность, что мешает его использовать там, где она нужна?
>> Криптоакселератор - он в целом как мертвому припарка - хорошо что есть, но нужен весьма и весьма специфических нагрузках.
> Он там довольно универсальный, с акселерацией SHA и zlib например, это много
> где в обычных задачах может всплыть. Понятное дело, это далеко не
> то же самое, что плата акселератора для спец. задач - просто
> специальные инструкции процессора позволяют ускорять определенный код. Не все ж specint
> считать, нужно и реальный код запускать.Когда такое же запихали в Xeon - после тестов оказалось что мертвому припарка. Тот же аппаратный CRC32 проигрывает по скорости вычислению через таблицу. Так и с остальными.
>> Я думал gzip используют что бы уйти от этих самых узких мест
> gzip слишком уж все кладет. lzo дает очень хорошее сжатие и не
> грузит проц, а gzip просто забесплатно сожрет +10 ядер на той
> же нагрузке. А эффективности сжатия и ввода-вывода почти не добавит. Кроме
> того, на практике в HBase можно дизайнить таблицы так, чтобы получать
> эффект от fastdiff (префиксного сжатия), после него дожать что lzo, что
> gzip - одна фигня.Понятно. lzo не всегда хорошо сжимает.
>[оверквотинг удален]
> В общем виде ему и не нужно, при правильном проектировании он обеспечивает
> локальность данных. А пересылки по сети только чтобы поддерживать распределенные копии
> (т.е. внутренние механизмы) и при изменении места хранений какой-то копии, чтобы
> данные оказались там, где обрабатываются. Хотя это плохой сценарий и такого
> не должно быть много, нужно обработку перемещать туда, где данные, а
> не данные, где обработка. Но даже при перемещении данных для конкретной
> задачи это будет однократно. Т.е. реальная обработка будет идти сразу с
> локальными данными (в идеале) или через некоторое время (при проблемах проектирования),
> и как там загружается сеть и с какими задержками, не имеет
> значения.насколько я помню архитектуру этого безобразия - там нода обработки и нода хранения в общем случае разные ноды. после чего нужно как-то передавать данные для обработки. Из-за чего даже делали хак в виде hardlinks что бы эмулировать копирование по сети.
>> Подходы у них весьма странные. На счет только такие и работают
> Я не говорил, что только такие и работают. Но у кучи очень
> крупных компаний такой или аналогичный подход и он работает - на
> очень больших кластерах.Очень большие кластера это сколько дисковой памяти и сколько клиентов и средний размер объекта хранения, требуемая скорость доступа? А то может у вас понятие о больших другие чем у меня? У меня все что относится к TOP10 считается большим. Остальное - так себе.
Попутно всплывают требования по скорости 20-40 GBytes/s для обработки чего нить объемами по 4-10Т в одном объекте, при общем количестве обработчиков - 10-30 тысяч.
>> PS. Когда там Хадуп научится версионности объектов? что бы не требовалось сохранять копию объекта при чтении клиентом
> Не знаю, я не в курсе такой проблемы. В HBase очень мощная
> версионность, что мешает его использовать там, где она нужна?Вот уж не знаю. В той версии что я копался - выглядело что он не может читать одновременно с модификацией.
> Когда такое же запихали в Xeon - после тестов оказалось что мертвому припарка. Тот же аппаратный CRC32 проигрывает по скорости вычислению через таблицу. Так и с остальными.Ну у Xeon свои особенности, там общая ПСП о-го-го и кэша до фига. Тут, думаю, есть смысл, иначе бы не стали делать.
> Понятно. lzo не всегда хорошо сжимает.
На практике вместо поблочного сжатия в HBase иногда лучше сжимать/разжимать некоторые данные при обработке, если критично именно сжатие и куски достаточно большие (тогда хоть lzma используй). Иногда получается даже эффективнее, т.к. при встроенном сжатии в кэше данные хранятся несжатыми. Но для всех остальных случаев lzo - самое то.
> насколько я помню архитектуру этого безобразия - там нода обработки и нода хранения в общем случае разные ноды. после чего нужно как-то передавать данные для обработки. Из-за чего даже делали хак в виде hardlinks что бы эмулировать копирование по сети.
В общем случае - да, но это неправильное использование и не должно происходить. Данные из HDFS должны читаться HBase'ом локально - если регион переедет на другую ноду, где нет копии данных, будет временно читаться по сети, но Hadoop тут же начнет перемещение данных туда для обеспечения локальности. Обработка типа map также должна запускаться на нодах с данными.
> Очень большие кластера это сколько дисковой памяти и сколько клиентов и средний размер объекта хранения, требуемая скорость доступа
Обычно для косвенных задач запускают небольшие кластеры в десятки и сотни нодов http://wiki.apache.org/hadoop/Hbase/PoweredBy
А у крупных игроков типа Yahoo, Facebook порядка тысячи (самый крупный, вроде, у Fluffy - два кластера по 1200 нодов). Еще есть Google (у которого не HBase, но Bigtable, на основе которого проектировался HBase) с кластером на несколько тысяч нод по похожей технологии.Типичные оптимальные ноды - 32-64 Гб памяти (128 тоже замечательно, но не всегда требуется) и 4-8 SATA-дисков. Объекты от нескольких байт до нескольких мегабайт в HBase хранить оптимально, для более крупных, видимо, уже стоит напрямую работать с HDFS, записывая туда файлы.
Общая скорость обработки масштабируется линейно с количеством нод. Т.е. сколько требуется, столько и нод.
> Вот уж не знаю. В той версии что я копался - выглядело что он не может читать одновременно с модификацией.
Если мы говорим про HBase, там сильная консистентность - читай и пиши одновременно, всегда будет корректный результат. При чтении обычно берется последняя версия, но можно все или по диапазону (ограничивая количество или их timestamp'ы). Пока вставка не завершилась, ее (частичную) не видно, когда завершилась, сразу все видят.
>>> Странный у вас кластер.
>> Hadoop/HBase
> K-ClusterКоллеги, но это изрядно разные типы кластеров, несмотря на очевидное "сползание" HPC-технологий в ДЦ.
>>>> Странный у вас кластер.
>>> Hadoop/HBase
>> K-Cluster
> Коллеги, но это изрядно разные типы кластеров, несмотря на очевидное "сползание" HPC-технологий
> в ДЦ.отнють.
http://www.opensfs.org/wp-content/uploads/2013/04/LUG2013_Ha...
http://www.intel.com/content/dam/www/public/us/en/documents/...и тп.
Люстрой можно оптимизировать Hadoop а вот сделать из Hadoop posix fs - весьма сложно. Хотя реально.
> обратного ходу нет. рано или поздно вся ARM-продукция перейдёт на Восьмую версию.Ну да, лет через 20 даже в тетрис будут упаковывать 64-битный проц. А покуда большинство ARMов 32-битные. И к огромному счастью - с открытым u-boot и без ужасной жести типа ACPI и UEFI, которые должны умереть жестокой смертью. От них на х86 один головняк и это моя самая нелюбимая часть х86.
> Ну да, лет через 20 даже в тетрис будут упаковывать 64-битный процдумаю пораньше раза в 4.
> с открытым u-boot
заведомо устаревшей версией. (без возможности перепрошить\обновить)
> ужасной жести типа ACPI и UEFI, которые должны умереть жестокой смертью
глупышка, линукс ты бы вообще не запустил БЫ на своём компьютере (x86), если бы на этом компьютере не было бы универсального интерфейса для взаимодействия с прошивкой-и-оборудованием.
в гипотетической альтернативной вселенной, в которой на x86 нет UEFI и нет ACPI -- на каждом таком x86-компьютере установлена предустановленная версия Windows, которую нельзя снести (и нельзя обновить), так как каждая такая Windows заточена под конкретную модель x86-компьютера (снести Windows -- значит невозвратно испортить такой компьютер).
> От них на х86 один головняк и это моя самая нелюбимая часть х86
у тебя головняк от того что один и тот же дистрибутив способен загружаться-и-работать на совершенно разных моделях x86-компьютеров?
может тогда ещё и расскажешь сказку о том что у тебя головняк от наличия лифта в подъезде? ведь наличие лифта в подъезде заставляет тебя постоянно *дожидаться* этого лифта, вместо того чтобы ты пешочком ходил бы по лестнице с любой скоростью (но теперь ты не можешь *заставить* себя ходить пешком, ведь лифт вынуждает тебя использовать лифт? ведь не виноват же ты что у тебя слабая воля, верно?)..
--------------------------------------------------
кто заставляет тебя использовать ACPI на твоём x86-компьютере?
сделай патч к ядру, который будет получать информацию преферии -- в ручном режиме! (патч чисто только для твоей модели x86-компьютера, патч который ты будешь сам сопровождать и сам накладывать на каждую новую версию ядра, и кторый не сможет работать больше ни где, кроме как у тебя).
кто заставляет тебя использовать UEFI ? сделай свою собственную прошивку для материнской платы (прошивку только для твоей модели x86-компьютера, которая будет способна инициировать оборудование и передавать управление коду ядра, без UEFI-среды.. прошивку которая будет способна работать только у тебя).
не хочешь всем этим заниматься? ну тогда РАДУЙСЯ что UEFI и ACPI тебя избавили от этих занятий! (даже если на конкретно твоей модели x86-компьютера реализация этих интерфейсов работает не идеально -- всё равно это лучше, чем если бы тебе пришлось бы самому писать патчи и писать прошивку)
> думаю пораньше раза в 4.Ты думать не умеешь.
> заведомо устаревшей версией. (без возможности перепрошить\обновить)
У меня на sunxi он вполне себе свеженький. Пересобранный лично мной. И народ его как раз синкнул с апстримом + свои наработки поверх. На фоне проприетарного деpьмищa типа ACPI - это просто благодать. Ни единого бага и глюка и вообще - запускает ядро и отваливат восвояси.
> если бы на этом компьютере не было бы универсального интерфейса для
> взаимодействия с прошивкой-и-оборудованием.А не пойти ли тебе #%$№" с твоим враньем, паря? Вот у меня прям ща работает армовская платка. Там обычная такая убунта, хоть они и не делают готовые образа под именно эту платку. И поверь, загрузчик который я могу скомпоновать как мне надо - мне зело симпатичнее блевотного биоса х86. На десктопе биосовый сблюв вообще виснет если на клавиатуре невовремя что-то нажать. Что делает вход в бутлоадер типа grub и например выбор ядра просто неимоверно мучительным начинанием, когда если нажал шифт на полсекунды раньше чем надо - жми ресет. И это никогда никто не сможет починить. Потому что сблюв проприерасских индусов.
> в гипотетической альтернативной вселенной, в которой на x86 нет UEFI и нет ACPI
Ну вот у меня на армовой платке нет никакого уефанства и прочих выceров интеля. А убунта есть. Так что шел бы ты лесом с интересом. Вместе со своим уефанством.
> у тебя головняк от того что один и тот же дистрибутив способен
> загружаться-и-работать на совершенно разных моделях x86-компьютеров?У меня головняк от того что если я нажму шифт на десктопе на полсекунды раньше чем надо - bios встанет колом и придется жать ресет. У меня головняк на ноуте, потому что ACPI сделан левой пяткой индуса и там море глюков. Но главное - эту дрянь никто никогда не починит. Потому что проприетарные му...ки - это как-то вот так. А вот на ARM u-boot вообще на удивление беспроблемная штука.
> от наличия лифта в подъезде? ведь наличие лифта в подъезде заставляет
> тебя постоянно *дожидаться* этого лифта,Это смотря какой лифт. Можешь посмотреть на ютубе как одного неудачливого перца лифт прокатил до крыши (с вылетом через оную, так что перец попал в больницу). Вот уефанство и ацпи - чаще всего работают как-то так же. И да, выбирая между такой поездкой на лифте и пешком - я лучше по лестнице на своих двоих, спасибо. Экстрим при катании на лифте меня не прет.
> кто заставляет тебя использовать ACPI на твоём x86-компьютере?
Мyдвины которые его реализовали. Но да, переключение управления подсветкой с этой глюкавой сpaни на прямое управление в вендор-специфичном виде - моментом вылечивает кучу адских глюков. Прикинь?! Вот реально - утупки не могут скомпоновать пару таблиц без дикой лажи.
> сделай патч к ядру, который будет получать информацию преферии -- в ручном режиме!
ЧСХ, ядро как-то так и делает, в основном посылая биос нафиг. И обычно то что делает ядро напрямую с железом - глючит сильно меньше чем то что делается через писаный левой пяткой ACPI. С подсветкой пример я тебе привел.
> и кторый не сможет работать больше ни где, кроме как у тебя).
Много бла-бла от некомпетентного субъекта, который вообще в предмете не разбирается.
> оборудование и передавать управление коду ядра, без UEFI-среды.. прошивку которая будет
> способна работать только у тебя).Вот именно так у меня взлетает u-boot на армовской платке. И с ним нет грабель. В отличие от уефанства. И секурбуты мне никто не навязывает. И да, знаешь, уефи тоже кто-то под конкретную плату делает. Только потом сорц зажимают, делают мутные троянообразные фичи, зажимают спеки и прочая. Нафиг нужно скажем дружно.
> не хочешь всем этим заниматься? ну тогда РАДУЙСЯ что UEFI и ACPI
Пошел ты! Я лучше сам буду u-boot себе собирать чем радоваться поеданию такого лютого ГOВНA как эта сладкая парочка. Впрочем, u-boot и другие могут за меня собрать, если мне лениво.
> тебя избавили от этих занятий!
Да, знаешь, если тебя запереть в филиале гестапо - у тебя тоже отпадет проблема выбора: сходить поиграть в хоккей или прокатиться на горных лыхаж? Гестаповец скажет - драить камеру! И все, зашибись - не надо ломать голову что делать. Меня избавили от нужды делать выбор.
> лучше, чем если бы тебе пришлось бы самому писать патчи и писать прошивку)
Во первых, под мало-мальски популярные железки прошивки делают. И получше чем гаццкие блобмейкеры, которым я могу пожелать только одно: медленной и мучительной смерти.
>> и Advanced Micro Devices Opteron A1100 (Seattle)
> Они хоть в продаже есть?По факту нет.
>>> и Advanced Micro Devices Opteron A1100 (Seattle)
>> Они хоть в продаже есть?
> По факту нет.Понятно, спасибо. А то я уже начал думать, что не умею гуглить...
>>>> и Advanced Micro Devices Opteron A1100 (Seattle)
>>> Они хоть в продаже есть?
>> По факту нет.
> Понятно, спасибо. А то я уже начал думать, что не умею гуглить...по факту и не надо. Как только армы начинают приближаться к ксеонам по производительности - тепловыделение и потребление становится очень похожим.