Computing power comparison: mainframe versus Intel Xeon

[Dmitry67]

Что уважаемый ALL скажет по этому поводу?

https://www.linkedin.com/pulse/computin ... ier-durand

[ALV00]

Хоть я ни разу не мейнфремщик, даже мне очевидна ущербность сравнений MIPS без учета всего остального. У MF надежность пять девяток, а у x86? Есть MF, которые работают лет 20 без выключения, причем все железо было заменено на новое на работающей системе.

[zVlad]

Я пока только начал читать статью, но уже виду натяжку.
Говорится: "A MIPS of System/360 announced in 1964 represents the same raw computing power as a MIPS of the most recent z13, introduced last year".
Мы сделали несколько ugrade's, z9-->z114-->zBC12, все время оставаясь на примерно 1000 MIPS. Если на z9 были нарекания от клиента и жалобы от програмистов, которые работают в низкопривелигированном классе сервиса, по производительности и мы были на грани выпонения SLA, то с z114 это прекратилось, а с zBC12 у меня ощущения что можно бы и поуменьшить MIPS-ы.
Так что MIPS-ы, которые вовсе не презентабельны для оценки производительности, с каждым новым семейством МФ как бы становятся более наполненными. Да и набор команд (instructions) S/360 и z14 это две большие разницы. Набор S/360 это маленькое, малюсенькое, подмножество набора z14.

[zVlad]

Это конечно здорово что есть тесты сравнивающие 1000 MIPS mainframe (1 core zBC12 2013 выпуска. 1 core zEC12 (тоже 2013)это уже 1514 MIPS) с 80 core Xeon. Но ссылка не открывается:

In 2013, HPE published a very interesting paper (get it here) about the results of its proprietary zRef benchmark which compares the same Cobol programs (transactional and batch) executed both on mainframes and on x86 servers. A summary of the detailed results: 1'000 MIPS of mainframe power can be replaced with better performances (on this benchmark) by a single server HP DL980 equipped with 8 Xeon E7-4870 (2.4 GHz, 10 cores / Xeon, 1 TB RAM).

На МФ с 1000 MIPS никогда не поставят 1 TB RAM. Это слишком много для 1000 MIPS. Кстати by a single server звучит очень наивно поскольку 1000 MIPS это очень мало для a single mainframe. Хотя, да, у нас есть mainframe с 50 MIPS, но это явный изврат. Это только канадцы могли до такого додуматься.

[flip_flop]

Но ссылка не открывается:

Google - могуч!

Достаточно отметить "about the results of its proprietary zRef benchmark which compares the same Cobol programs (transactional and batch) executed both on mainframes and on x86 servers", кликнуть "Google search" - и вуаля, искомый pdf легко находится:

https://www.platformmodernization.org/h ... ePaper.pdf

Много букaв, цифер, картинок и прочего интересного. Надеюсь на плодотворное продолжение дискуссии.

P.S. Краткое резюме, в конце статьи от HP:

In addition to showing relative throughput, the results disproved several common myths:
• Myth #1—Distributed systems can’t do mixed workload, e.g., CICS and batch.
– Reality—The HP MFA systems delivered good service even while running CICS and batch at very high levels of
CPU utilization.
• Myth #2—Mainframe is superior at running batch.
– Reality—The zRef batch jobs ran in a much shorter elapsed time on the HP MFA platforms than on the mainframe.
• Myth #3—Only a mainframe can run at or near 100% sustained system utilization and deliver good service.
– Reality—HP MFA systems running near 100% utilization delivered consistent sub-1 second CICS response time.

[zVlad]

Но ссылка не открывается:

Google - могуч!
....
https://www.platformmodernization.org/h ... ePaper.pdf

Много букaв, цифер, картинок и прочего интересного. Надеюсь на плодотворное продолжение дискуссии.

P.S. Краткое резюме, в конце статьи от HP:

In addition to showing relative throughput, the results disproved several common myths:
• Myth #1—Distributed systems can’t do mixed workload, e.g., CICS and batch.
– Reality—The HP MFA systems delivered good service even while running CICS and batch at very high levels of
CPU utilization.
• Myth #2—Mainframe is superior at running batch.
– Reality—The zRef batch jobs ran in a much shorter elapsed time on the HP MFA platforms than on the mainframe.
• Myth #3—Only a mainframe can run at or near 100% sustained system utilization and deliver good service.
– Reality—HP MFA systems running near 100% utilization delivered consistent sub-1 second CICS response time.

Спасибо. Открыл документ. Но мне кажется мы уже здесь это обсуждали. Стоит ли снова затевать тоже самое? Я распечатаю тугомен, на обеде полистаю, но если подтвердится что я по этому уже высказывалась, то повторять не буду. Если не читал, то буду.

[Dmitry67]

На МФ с 1000 MIPS никогда не поставят 1 TB RAM. Это слишком много для 1000 MIPS.

Почему? Для раза много кэша не бывает

[flip_flop]

Спасибо. Открыл документ. Но мне кажется мы уже здесь это обсуждали. Стоит ли снова затевать тоже самое? Я распечатаю тугомен, на обеде полистаю, но если подтвердится что я по этому уже высказывалась, то повторять не буду. Если не читал, то буду.

Пожалуйста. Да, меня терзают смутные сомнения, что это уже было. Просто восполнил пробел, на всякийс случай.

[zVlad]

Спасибо. Открыл документ. Но мне кажется мы уже здесь это обсуждали. Стоит ли снова затевать тоже самое? Я распечатаю тугомен, на обеде полистаю, но если подтвердится что я по этому уже высказывалась, то повторять не буду. Если не читал, то буду.

Пожалуйста. Да, меня терзают смутные сомнения, что это уже было. Просто восполнил пробел, на всякийс случай.

Да, читал, изучал давал свои оценки. Повторять смысла не вижу - белые нитки в этих "technical white paper" торчат пучками просто, начиная на ссылки на каких-то експертов, которые делали проверку что на МФ все было сделано ОК, и заканчивая тем что в исследовании этом mainframe дали 8 GB RAM, a server на Xeon 1 TB RAM. Эксперты уже отпали как минимум. И это далеко не все.

Единственное о чем можно было бы поговорить в связи с этим это о профессиональной ответственности тех кто такие "исследования" проводит, прежде всего с точки зрения целей. А цели очень не чистые - переманить на альтернативную платформу в условиях когда оставление на МФ заведомо выгоднее и не имеет никаких препятствий, а переход ничем не мотивирован. Конечно все сводится к неким деньгам, но деньги при этом как правило не все показываются, а цена перехода даже не оценивается.

Не о чем здесь говорить в техническом аспекте. Это, выражаясь новоязом, фэйк ньюс. Гнилой товар, наперстки. Я готов принять грамотное исследование - без наперстков, я тратил время на изучение этого и многих других, предлагавшихся мне здесь, бумаг. Ни разу не было такого чтобы мне не к чему было придраться, а раз есть то получается мы не знаем как бы это все могло быть на самом деле - повторять такие экспериментысо всеми, например моими претензиями и предложениями никто не будет, а у меня нет таких ресурсов чтобы провести их самому.

[mskmel]

mainframe дали 8 GB RAM, a server на Xeon 1 TB RAM. Эксперты уже отпали как минимум. И это далеко не все.

8ми сокетнику на х86 невозможно дать 8ГБ. Для оптимальной производительности надо заполнить как минимум 4 DIMM у каждого процессора. Чтобы получилось 8ГБ надо DIMM по 256МБ, а их не делают уже давно.

[zVlad]

mainframe дали 8 GB RAM, a server на Xeon 1 TB RAM. Эксперты уже отпали как минимум. И это далеко не все.

8ми сокетнику на х86 невозможно дать 8ГБ. Для оптимальной производительности надо заполнить как минимум 4 DIMM у каждого процессора. Чтобы получилось 8ГБ надо DIMM по 256МБ, а их не делают уже давно.

И что? Как это сочетается с целями и результатами исследований?
А восемьдесят cores против двух, это о чем.

[mskmel]

И что? Как это сочетается с целями и результатами исследований?

Так никто там ничего не исследовал, просто показали что такой-то сервер может сделать столько "попугаев" в specjbb тесте (CPU bound). Что за 3 года производительность выросла на Х %.

Сравнение делать по MIPS глупо, согласен, надо брать стандартные тесты и их сравнивать. Тот же specjbb индустриальный стандарт для java workload. Но IBM ни разу нигде не показала подверждения своим словам, что строить приватный клауд на z это выгодно. Их отдел маркетинга, имея такой козырь в рукаве, думаю, не стал бы его держать столько лет. Ведь чего может быть проще: поставьте кучу zLinux, прогоните тесты, выложите всем на обозрение и наблюдайте как тыщи корпораций посыпают голову пеплом, меняя свои тыщи Linux on Intel на zLinux. При чем specjbb может скачать и погонять любой: https://www.spec.org/jbb2015/docs/userguide.pdf Вменяемому инженеру работы на вечер.

[ARARAT.]

Прикольный коммент под статьей:
george thompson
--
idiot

Коротко и ясно...

[flip_flop]

Сравнение делать по MIPS глупо, согласен, надо брать стандартные тесты и их сравнивать.

Обсуждали уже. Раз сто. Для МФ нет подходящих тестов. Всё, что есть - не подходит, а что подходит - мы не знаем и не узнаем никогда. Аминь.

[mskmel]

Обсуждали уже. Раз сто. Для МФ нет подходящих тестов. Всё, что есть - не подходит, а что подходит - мы не знаем и не узнаем никогда. Аминь.

Вы хотите сказать, нет подходящих нагрузок? Миллионы х86 ядрышек крутят java, вполне понятная и тестируемая нагрузка.

[flip_flop]

Вы хотите сказать, нет подходящих нагрузок? Миллионы х86 ядрышек крутят java, вполне понятная и тестируемая нагрузка.

Нет, я лишь привожу краткий вывод наших прошлых дискуссий. По мнению zVlad-a для МФ нет подходящих тестов, поскольку МФ сияет в зените славы не при пошлой однотипной нагрузке а при неких особенных смешанных нагрузках, для которых тестов не было, нет, и (по моему предвидению) не будет никогда.

Можно zVlad спросить, но это было жёвано - пережёванно много раз. Без консенсуса, к сожалению. Так что я не уверен в новых прениях.

[zVlad]

Сравнение делать по MIPS глупо, согласен, надо брать стандартные тесты и их сравнивать.

Обсуждали уже. Раз сто. Для МФ нет подходящих тестов. Всё, что есть - не подходит, а что подходит - мы не знаем и не узнаем никогда. Аминь.

Нет, это не совсем так. Вы (не Вы лично) ждете и пытаетесь сравнивать делая простые тесты. Вы считаете что именно их простота позволяет понимать что делается. Плюс, ваше понимание сервера предполагает использование сервера для одного сервиса (бд, вебсервер, и т.д.), более того вы эти одиночные сервисы еще и на кластер растянуть пытаетесб.
А мф предназначен для сложной, комплексной нагрузки, когда на одном сервере не один, а много сервисов выполняется - и база данных и сервер приложений и вебсервер. В этом случае связи их происходят не по сети, а напрямую, через память.
В тесте по которому эта тема, если мне память не изменяет (завтра я уточню), тесты с пакетными заданиями и диалоговые выполнялись раздельно, а в реальной жизни, на мф, это все делается одновременно.
Чем нагрузка сложнее и комплекснее тем больше отдача от мф. Чем проще тем отдача меньше. Мы все время анализируем простые нагрузки, такие как принято делать на распределенных системах. Когда будет сделан сложный тест (кем?) тогда картина и проясниться как вы хотите - на тестах. Вам это надо, вы и делайте. Тем кто работает серьезно на мф и так все понятно, им никаких тестов с участием х86 не нужно, они не собираются уходить с мы.
Это нужно тем кто хочет погреть руки на решивших уйти с мф, вот они делают такие тесты. Но фишка в том что решение уходить с мф принимается тоже не по тестам вовсе, как например у нас это происходит.
Остаются только любопытствующие вроде наших, приветовских пикетных жилетах, которые чтобы zVlad-а "завалить" этим интересуются чисто теоритически. Вот эти тесты жля них, для вас ребята.

Спокойной ночи. Да завтра.

[flip_flop]

Тем кто работает серьезно на мф и так все понятно, им никаких тестов с участием х86 не нужно

Спасибо за ответ, старина. Я выделил квинт ессенцию, так сказать. В дидактических целях, для нашей аудитории.

[oshibka_residenta]

Тем кто работает серьезно на мф и так все понятно, им никаких тестов с участием х86 не нужно

Спасибо за ответ, старина. Я выделил квинт ессенцию, так сказать. В дидактических целях, для нашей аудитории.

Хорошо когда можно не сравнивать. У нас вот есть старая система построенная на МФ и новая, постороенная на х86, так что роскоши не сравнивать нет. Некоторые вредные страны хотят чтобы данные пользователей хранились только в локальном датацентре. Поэтому переодически возникает вопрос: на чем строить датацентр- МФ или х86. Решение на МФ оказывается в _сто_ раз дороже. Так наши МФ специалисты не такие гордые как zVlad- скромно смотрят в пол и надеются дожить по пенсии.

[mskmel]

А мф предназначен для сложной, комплексной нагрузки, когда на одном сервере не один, а много сервисов выполняется - и база данных и сервер приложений и вебсервер.

Хочется понять, а сколько оно потянет в линейке Amazon>FB>GMail>....>ларёк торгующий пивом? Распределенные системы на х86 тянут всё что надо просто добавлением в топку новых ядер\гигабайт памяти.

Остаются только любопытствующие вроде наших, приветовских пикетных жилетах, которые чтобы zVlad-а "завалить" этим интересуются чисто теоритически. Вот эти тесты жля них, для вас ребята.

Вот зря Вы так. Завалить нет желания совсем.
Хочется понять, почему победили Linux на х86 VM, а не zLinux. Почему java workload живёт массово на x86, а не МФ.
Может в следующем моём месте работы получится организовать POC ребятами из IBM, и таки убедить поменять тыщи винтел на один z14.

[zVlad]

Тем кто работает серьезно на мф и так все понятно, им никаких тестов с участием х86 не нужно

Спасибо за ответ, старина. Я выделил квинт ессенцию, так сказать. В дидактических целях, для нашей аудитории.

Хорошо когда можно не сравнивать. У нас вот есть старая система построенная на МФ и новая, постороенная на х86, так что роскоши не сравнивать нет. Некоторые вредные страны хотят чтобы данные пользователей хранились только в локальном датацентре. Поэтому переодически возникает вопрос: на чем строить датацентр- МФ или х86. Решение на МФ оказывается в _сто_ раз дороже. Так наши МФ специалисты не такие гордые как zVlad- скромно смотрят в пол и надеются дожить по пенсии.

Вы должны помнить мои рассказы о том как один из наших клиентов ушел с МФ. С одним и тем же приложением, от одного и того же вендора. Я приводил подробные данные на чем этот клиент работал пока это был МФ и на чем он стал работать когда ушел. Также я рассказывал что у клиента долго не было ДР и долго (пока не заменили то что им насчитали изначально на установки в разы более мощные, а следовательно и дорогие). Это тоже из разряда сравнений и оно было более адекватное и корректное чем то что мы обсуждаем, я имею в виду от HP. Так что сравнения есть, не надо ля-ля, и их никто не боится, даже наоборот.

Я не знаю Ваших систем, ни старой ни новой, не знаю Ваших МФ специалистов, но могу уверенно сказать что "сто раз дороже" это булшит или чье то лукавство - обман, и как минимум это деньги только на TCA, а не на TCO. Приведите больше данных и я Вам обьясню что не так. Предложите Вашему руководству пригласить меня для проверки и консультации (я готов приехать куда угодно). Причем, на данном уровне, я не утверждаю что в Вашем случае датацентр надо обязательно строить на МФ, а не на х86. Скорее всего в датацентре должно быть и другое, а может быть и только x86, но точнo не вариант "потому что в _сто_ раз дороже".

[zVlad]

...
Хочется понять, почему победили Linux на х86 VM, а не zLinux. Почему java workload живёт массово на x86, а не МФ.
Может в следующем моём месте работы получится организовать POC ребятами из IBM, и таки убедить поменять тыщи винтел на один z14.

Где победили? Как? Крапленные карты в студию.

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

Несколько (больше десяти) лет назад у нас имплементировали Java приложение - вебморду к нашей ERP системе на МФ. Сначала наш клиент требовал это установить на МФ, провели POC, с ребятами из IBM, все было установленно и работало. Потом была пауза на два-три года, видимо сменилось руководство в отделе CIO клиента (мне как-то по ошибке пришел e-mail, так я в addressee list насчитал больше 20 головов из CIO клиента), была нанята внешняя сила для нового проекта этой Java вебморды, и вот эта вот внешняя сила просто силовым приемом "убедила" нашего клиента ставить вебморду не на МФ, а на Power и AIX.
Как я не пытался переубеждать (а до клиента я естественно добраться не мог, не тот у меня уровень) с фактами на руках - меня просто не слушали, не слушали и все.
Несмотря на зaпрет я создал всю инфраструктуру на МФ (WebSphere), продеплоил и сконфигурировал Java приложение той вебморды, IBM нам дали поиграться zIIP на два месяца. Сам протестировал работу, послал всем URL к вебморде на МФ. Ни одна сука даже не подошла и не попробовала. Причем я это все сделал на МФ на несколько месяцев раньше чем это появилось на Power и AIX - сервера тогда еще долго и мучительно покупали, потом долго и мучительно устанавливали WebSphere и DB2 Connect (платная фишка в случае МФ не нужная в принципе) на AIX, пытались даже меня привлечь - я их послал на х.й, в итоге это делали IBM-вцы.
Мне грозили дисциплинарными мерами вплодь до увольнением за самоуправство. Шутили наверное.
Одной из причин почему не МФ называлось цена zIIP, мол это дорoго. Самое смешное что когда все уже улеглось и мы делали upgrade на то что у нас сейчас - zBC12 - то в конфигурацию нового МФ включили этот zIIP, он есть у нас. Но поскольку у нас нет Java workload, то этот zIIP используется только DB2 нa 2-3% - там немного случаев когда DB2 использует zIIP. В итоге клиент наш купил WebSphere for z/OS ($400 000), zIIP ($40 000) и работает на купленных же Power, AIX, WebSphere for AIX, i DB2 Connect for AIX. Фактически оплатил два комплекта инфраструктуры, а использует один.

Это еще ладно - был период когда серьезно хотели использовать МФ. А обычно про МФ даже не думают - некому и нечем (нет знаний) думать. Вот так и побеждает х86. Это не победы никакие. Я таких "побед" стеснялся бы и не вылазил с ними в приличное, технически образованное общество.

[zVlad]

Тем кто работает серьезно на мф и так все понятно, им никаких тестов с участием х86 не нужно

Спасибо за ответ, старина. Я выделил квинт ессенцию, так сказать. В дидактических целях, для нашей аудитории.

В этой работе настолько много белых ниток (я сейчас пробежался по тексту и просто ужаснулся и удивился насколько надо быть зашоренным чтбы не видеть этих белок ниток и принимать эти тесты всерьез) что никакой вообще ессенции выделить невозможно, кроме одной - если привлечь настоящих спецов по МФ и вырaвнять хотя бы приблизительно некоторые технические параметры сравниваемых установок в первую очередь RАМ (неужели Вы считаете нормальным даже начинать тесты с базой данный на установках с 8 GB и 1 TB RAM? x128 разница!) далее каналы ввода-вывода: 4*2 Gb и 4*8 Gb, которые в случае с 8 GB RAM загасят response time раньше чем наступит 100% CPU busy что и демострируется Figure 2 - там нет 100% CPU busy, следовательно MF держал ввод-вывод. Причем те в среднем 5% каждого из двух CPU могли бы продвинуть TPS в пределах 1 sec response time вперед значительно, но насколько мы никогда не узнаем, Плюс если бы хотя бы 32 GB RAM (с 2013 года это минимум с каким IBM поставляет МФ) попробовали то тоже ТПС ушел бы вперед, опять же насколько мы никогда не узнаем.

Смешанного выполнения CICS+Batch на МФ почему то не делали, а это весьма классический вариант нагрузки МФ. Почему? Кто, что, мешало поставить тест против которого у меня не было бы принципиальных возражений против того что тест нерелевантный для МФ? ИБМ не тестирует, почему HP не протестировал CICS+Batch на MF?

И есче одно замечание по финансовому разделу "исследования". Как я думаю уже показал чисто техническая часть "исследования" не выдерживает элементарной критики (я не все что нашел здесь озвучил). Kакой тогда вообще может быть смысл считать деньги? Нисколько не стоит подключить диски к МФ не через switch, а напрямуы (так кстати уу нас и большенства MF shops сделано. Switch вообще то нужен только для GDPS - geographically dispersed Parallel Sysplex, а уже совсем другая история. RAM как я уже сказал на МФ можно минимум иметь 35 GB по состоянию на следущий за "исследиванием" год, да и вообще могли бы логически ограничить 1 TB ну хотя бы до 128 GB. Хотя все это, конечно, зависит от размера используемой БД, которого я в "исследовании" не нашел.

Самое смешное что кроме варианта RDBMS и Application на одном сервере, что единственно возможно было для МФ, еще не лень было делать тесты x86 когда они раздельны. Зачем? Думаю чтобы показать нерелевантные в принципе 936 TPS.

[mskmel]

Где победили? Как? Крапленные карты в студию.

AWS, Google Cloud, тыщи более мелких public clouds и ни одного МФ.

[flip_flop]

zVlad, одно дело говорить что тесты фиговые и надо было бы провести те же тесты в других, более адекватных условиях. Ну, как в моей области - конкурент N утверждает, что его решения в 100 раз лучше нашего (при этом махлюет на тестах). Мы делаем те же тесты в адекватных условиях и приводим данные, что наше решение в 1.5 раза лучше (ну или всего в 3 раза хуже вместо 100 раз, но мы приводим обьективные данные). Тесты воспроизводимые, любой может вникнуть в детали и прогнать самому.

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

Как говорится, две большие разницы.