What System z can do that Intel® can’t

[iDesperado]

Кстати я удосужился почитать дальше, там много было не ясностей и я обращался даже в ИБМ за разяснениями. Вот один из их ответов который Вы явно пропистили мимо ушей:

это не правда, я сразу написал, что подозреваю этого человека употреблении наркотиков, если он на 68 ядер получает 78 оракловых лицензий.
viewtopic.php?p=4681551#p4681551

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

объясняю. как только мы берем реальные тесты, а не выдуманные, мы видим диаметрально противоположную вашим рассказам картину. мы видим, что в реальной жизни, когда серьезные специалисты на МФ запустили ту же задачу, что на SPARC сервере, МФ затратил больше времени на обработку данных. множество ваших сообщений на эту тему этот факт никак не опровергли, а скорее добавили подробностей.


в продолжение к этому тесту я нашел еще один
http://www.oracle.com/us/solutions/benc ... 166414.pdf
http://www.oracle.com/us/solutions/benc ... 166419.pdf

тут запустили совсем идентичный batch тест. на обоих машинах запускали Large model, на обоих Large model с 14 потоков. т.е. условия тестирования были идентичны. писюк обрабатывал 298,507 строк в минуту, МФ с тем же кол-вом процессоров лишь 113,207 в минуту.

[Интеррапт]

Не совсем в тему.... Но XBox отказался от айбиэмовской PowerPC архитектуры и следующий XBox будет x86-64.

[zVlad]

Если я правильно Вас понял Вы сравниваете EC12 c 12 CPU c z114 c 5 CPU для одного и того же значения MIPS? Но EC12 это совсем другой конструктив позволяющеий наращивать мощность до предела, до 78 000 MIPS на 100 CPU, a z114 - это максимум 5 CPU и 5 specialty engines. Если вы видите что укладываетесь в z114 вам нет никакой надобности покупать EC12. Есть еще вариант начать с EC12 c 5 CPU который выдаст те же MIPS-ы что и z114 c 5 CPU, но будет дешевле чем EC12 c 12 CPU.

так я же именно об этом и говорю, ваша схема с 12 CPU из которых 7 и 9 CPU в запасе под DR не имеет экономического смыла.

- MF1 - 5 CPU, 1000 MIPS
- MF2 - 3 CPU, 76 MIPS

В принципе оба МФ одинаковы с одинаковой начинкой. Они имеют наверное 12 CPU из которых 5 могут быть сконфигурированы как general purpose CPU и еще 5 как specialty engines.

вы для нагрузки, которую тянет z114 предлагаете брать EC12, что привете к лишним тратам в миллионы. три отдельных z114 из которых один запасной для первых двух обойдется гораздо дешевле.

Ничего подобного я не предлагал. В моем пример DR количество ЦПУ остается не изменным в случае DR, мощность увеличивается на том же количестве ЦПУ.

[zVlad]

Данные в памяти ето палка о двух концах. Приложения где используют МФ нуждаются в DR, т.е. в репликации всех изменений на DR site. Сейчас это делают дисковые подсистемы автономно. А как это делать с данными в памяти? Как они материлизоваться будут?

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

Можно, но это неизбежно удорожит проект. Кроме того данные в БД как правило очень разные по частоте обращения к ним. К некоторым данным, и их может быть достаточно много, обращений вообще не бывает, это фактически архивные данные. Такая БД у нашего клиента, например. И зачем всю такую БД держать в памяти? Не лучше ли иметь мощный ввод-вывод?

[zVlad]

Не совсем в тему.... Но XBox отказался от айбиэмовской PowerPC архитектуры и следующий XBox будет x86-64.

Я бы даже сказал - совсем не в тему.

[iDesperado]

Ничего подобного я не предлагал. В моем пример DR количество ЦПУ остается не изменным в случае DR, мощность увеличивается на том же количестве ЦПУ.

вы снова за старое
вы же поняли о чем я говорю, к чему этот спектакль ?
что бы была возможность увеличить мощность, нужно иметь модель МФ, в которой будет установлено 5 процессоров на первую задачу и 3 процессора на вторую. т.е. более дорогая модель в расчете на один MIPS мощности, чем z114.

[zVlad]

.....в продолжение к этому тесту я нашел еще один
http://www.oracle.com/us/solutions/benc ... 166414.pdf
http://www.oracle.com/us/solutions/benc ... 166419.pdf

тут запустили совсем идентичный batch тест. на обоих машинах запускали Large model, на обоих Large model с 14 потоков. т.е. условия тестирования были идентичны. писюк обрабатывал 298,507 строк в минуту, МФ с тем же кол-вом процессоров лишь 113,207 в минуту.

8-ми процессорный RISC сервер никак не писюк, не надо утрировать.
Вы наверное думаете что раз оба сервера имеют по 8 CPU то это значит что тестируется нечто одинаковое.
На самом деле:

- в моделе 116 CPU "зажаты". MIPS-ы этой модели примерно равны MIPS-ам незажатого МФ с 12 CPU. Речь идет естественно о z900. В отчете говорится о 1612 MIPS для 8 CPU LPAR. Арифметика говорит что все 16 ЦПУ должны бы дать 3200 MIPS, но из других источников (нескольких разных) следует что модел 116 имеет 2700 MIPS, 3200 MIPS имеет модел 216. Таким образом получается что в тесте использовались 6 ЦПУ на максимольной их скорости, а не 8.

- в тесте на LARGE моделе МФ был загружен всего на 60%. RISC server na 90%. Следовательно мы сравниваем результат работы 3.6 CPU MF c 7.2 CPU RISC server (если конечно РИСЦ сервер мог бы быть нагружен на 100%, МФ точно мог бы).

- память у RISC servera - 32 GB, y MF - 10 GB или в три раза меньше.

- отчет не говорит какие и сколько каналов ввода-вывода использовалось на МФ.А с этим связано несколько возможностей дающих разную производительность. У нас были такие диски о которых говорит отчет и онии были подключены через ESCON и не использовались на продакш, а только на тестовой системе. Shark была неудачной дисковой подсистемой.

Так что я бы не стал делать каких либо выводов из этих тестов, но я уверен что МФ в тех тестсах по крайней мере был недогружен.

[zVlad]

Ничего подобного я не предлагал. В моем пример DR количество ЦПУ остается не изменным в случае DR, мощность увеличивается на том же количестве ЦПУ.

вы снова за старое
вы же поняли о чем я говорю, к чему этот спектакль ?
что бы была возможность увеличить мощность, нужно иметь модель МФ, в которой будет установлено 5 процессоров на первую задачу и 3 процессора на вторую. т.е. более дорогая модель в расчете на один MIPS мощности, чем z114.

Это не я а Вы спектакль тут разыгриваете. Я уже говорил, но видимо придется еще раз повторить - не нужны 3 процессора для второго МФ на первом. Теже 5 CPU (model Q05 992 MIPS) конвертированные в модел Z05 (найдите сами сколько это будет MIPS, я так полагаю будет больше 2000) прекрасно осправятся с сумарной нагрузкой. Более того приложение с первого МФ прекрасно ложится на три процессора второго конвертированного из A03 (76 MIPS) в Z03 (1500 MIPS). Обе машины у нас - одна z114, вторая z10 BC.

Так кто здесь спектакли разыгривает?

[zVlad]

.....в продолжение к этому тесту я нашел еще один
http://www.oracle.com/us/solutions/benc ... 166414.pdf
http://www.oracle.com/us/solutions/benc ... 166419.pdf

тут запустили совсем идентичный batch тест. на обоих машинах запускали Large model, на обоих Large model с 14 потоков. т.е. условия тестирования были идентичны. писюк обрабатывал 298,507 строк в минуту, МФ с тем же кол-вом процессоров лишь 113,207 в минуту.

В дополнении к сказанному выше меня очень смущает и настораживает вот это из списка используемого софта для МФ:
- Merant Server Express (COBOL) 2.0

Я не знаю что это за зверь, но похоже этот зверь юнисксовского происхождения и ничего хорошeго для производительности я от этого не ожидал бы.
Для z/OS есть нормальный COBOL от ИБМ и именно он должен использоваться с z/OS в тестах производительности. Я знаю что ИБМ-ский кoмпилятор затачивается на архитектуру MF. Заточен ли Mertant nobody knows.

[iDesperado]

8-ми процессорный RISC сервер никак не писюк, не надо утрировать.

да, наверно воркстейшен правильней называть. я не утрирую, просто нужен термин на unix/linux/windows платформы.

Вы наверное думаете что раз оба сервера имеют по 8 CPU то это значит что тестируется нечто одинаковое.

нет, я так не думаю, потому как знаю, что там разные архитектуры.
суть в том, что мы имеем бенчмарк, сделанный профессионалами, с привлечением спецов IBM c одной стороны и басню с другой:

Сегодня говорил с колегами по команде которые работают на другого клиента - крупная фирма по распределению электоэнергии. Клиент этот переводит приложение с МФ на Юникс/Оракл. МФ был двухпроцессорным z9 N02 s 214 MIPS-ами под production i z9 A01 s 26 MIPS-ами под ДР и development.
Спрашиваю на какие сервера переходят. Отвечают, не знаем, нам не говорят, но проект дилжен был закончится в октябре 2012 и по ходу тестирования выяснелось что начальные параметры серверов были занижены и пришлось их докупать. Было сказано что вместо 110 активных юсеров на тех серверах могли потынуть только 10. Предположение теам леад-а который хорошо знает клиента это 6-8 многопроцессорных AIX серверов

видите какая несостыковочка выходит. когда тестирует IBM, у них МФ 1612 MIPS не очень то здорово смотрится на фоне UNIX. а вы нам рассказываете, что замена на порядок менее мощного МФ z9 N02 s 214 MIPS потребовала табун UNIX серверов, каждый из которых в 2012 году в сотни раз мощнее того сервера 8xPA-RISC, что использовался в тесте peoplesoft.

[zVlad]

Вот два более современных теста с похожими результатами:

http://www.oracle.com/us/solutions/benc ... 946204.pdf

8 cores, 32 Gb memory

http://www.oracle.com/us/solutions/benc ... 888755.pdf

32 cores, 256 Gb memory

И опять же Оракл упорно занижает количество job streams на MF - 8 streams, а на своем SPARC пускает 32, 64, i 128 job streams. Кто-нибудь может узнать или обяснить почему Оракл так делает

Для тест на SPARC Оракл приводит данные по I/O для МФ таких данных нет. И посмотрел свою продакш несколько минут, посмотрел I/O per second только для DB2. Максимум что я увудел было 14 000 I/O per second. Таких чисел нет у SPARC-а и там видно насыщение по IO/s. A storage у них там не хилая судя по параметрам. Что скажитe, iDesperado?

[zVlad]

....суть в том, что мы имеем бенчмарк, сделанный профессионалами, с привлечением спецов IBM....

Я привел свои соображения по поводу представленных Вами бенчмарков и у меня складывается впечатление что Вы ыих не читали. По крайней мере Вы ничего не сказали о них, а ведь я с Вашей подачи тратил время разобраться с Вашим материалом. Не хорошо это, не вежливо с Вашей стороны.
Не уверен что были привлечены спецы ИБМ, а если и были то не знаю для чего. Лично мне кажется, я уверен, что из МФ можно было бы вежать много больше.
Вообще беда этих тестов в том что они не показывают динамики по количеству job streams. В результате не ясно удалось ли насытить МФ. А без этого ничего сказать не возможно. Может теже данные можно было бы и на меньшем МФ получить.

[zVlad]

В англоговорящем интернете похожие дебаты происходят. Вот случайно наткнулся:

http://bit.listserv.ibm-main.narkive.co ... -article.2

There *is* a reason
> that SPEC (and other benchmarking organizations) exist. These customers
> want a common performance metric to identify the value they are getting for
> the money they spend. Yes, reliability, fault-tolerance, data integrity,
> etc. are all factors too - but the mainframe does not have a lock on these
> features, other platforms do as well, including those based on x86.
>
> Maybe I can point out the dilemma better this way:
>
> People here have asked how managers can justify migrating their
> mission-critical applications off the mainframe and onto a 'PC'. At the
> same time, these people will say that there is no common metric to compare
> the various platforms, that they are just different. So, a manager who
> must make a business/financial decision is given no tools with which to make
> that decision - so is it any wonder that those decisions seem, well, random?
>
> One would think that *if* the mainframe can compete head-to-head with these
> other server systems that those in the business would *want* a common
> metric. They would *strive* to identify something that managers could use
> to make better decisions. This should, you would think, include the vendor
> who would benefit most by such information. Continually claiming that
> there is, and cannot be any comparison seems counter productive. You are
> *asking* these managers to go with the latest fad because they have nothing
> else to use as a guideline. If it can't compete, then perhaps it makes
> sense to claim that no such metric can be identified.
>
> As long as the workloads are completely different, then it makes sense.
> They they overlap, however, you are asking for people to flip a coin to
> choose unless you give them another tool to use.
>
> As for the car analogy in performance, I would suggest the following: I
> can look at horsepower, top speed, acceleration, luggage capacity, towing
> capacity, gas mileage and various other factors that are available for *all*
> vehicles. This allows me to make an intelligent, informed decision about
> which particular vehicle is best for my needs, whether it be a sportscar, a
> family vehicle, a farm vehicle or a large commercial vehicle.
>
> Instead, Timothy Sipples suggests (and I paraphrase from his reply to me)
> "if you don't know, talk to your IBM rep - he'll tell you what you need".
> Sure, he'll tell me I need a Sun system instead of an IBM system - right?
> Or perhaps I should go talk to Sun or HP or Dell to find out what best suits
> my needs. If you care about the platform, you should care about the
> problem... or so it seems to me.
>
> Regards,

Can the mainframe z900/z990/z9 compete head to head with Intel?
IMHO, yes.

Head to head. You are talking about the same number of processors and
same amount of "RAM/Central Storage".


We have two z990, a 304 and 303. A total of 7 (seven) CPU's and 20GB of
total central stoage for the z/OS images.

Now in our enviroment we do NOT have a test mainframe, we do not have
test LPAR's. All production/test/development/QA/user accecptance
testing are done with the same LPARs. There is a system programmer sand
box on the 303.

We are planning to migrate 80% of our workload off the mainframe on to
Intel. If the Intel processors were really faster/better than the z990
CPU, then we sould be to get a single Intel box with 6 CPUs to replace
our two mainframes. Right? Remember this is head to head.

Are we? NOPE. In the end to replace 80% of 7 z990 CPU's and 20GB of
RAM the Intel side will have

Right now the plan is to ONLY have 96 total "cores" (some systems will
have single core processors and some will have dual core) CPU's and 456
GB of RAM. This is a est. and they beleive that they may need to
increase this by as much as 50%.

So the "head to head" comparsion is 7 CPU's and 20GB to 96 CPU's and 456
GB of RAM. Doesn't seem to "head to head" to me.

That is a about a 13:1 ratio on CPU's and 23:1 on "RAM". If Intel was
"faster" then we should be able to do more work on less processors.

Please show me a site that has migrated off a modern day mainframe to
Intel using the same number of CPU's and same amount of Central
Storage/RAM as they had on the mainframe. You know head to head.

Обратите внимание на выделенное. Я давно считаю что разделять продукшн и остальные инстансы вовсе не нужно. Все прекрасно будет работать в одной системе если это конечно z/OS. У нас два LPARs на одном МФ - один продукшн и второй все остальное. И еще одна глупость у нас есть с которой я много боролся, но так ничего и не смог добиться - у нас в продакш системе 5 application serevers (CICSs). Достаточно было бы одного, но никто не хочет брать на себя ответственность.

[zVlad]

I don't understand why the comparison is always technological. Why not
compare what the costs to acquire, provision, operate and maintain
the "system" over, say, 4 years?

This is the TCO stuff, including staff, software license costs, electricity, floor
space, etc. Head to head where it counts: IT spending.

Do people *really* care that much about MHz or GB? I figured folks were
primarily interested in affordability. Can you get the function you need, with
the qualities of service you require, at a price you can afford? Can your
infrastructure absorb/accomodate growth?

If all you want is a web server, don't buy a mainframe. If all you want is 5
webservers, don't buy a mainframe. If, on the other hand, you want 400
webservers, buy a mainframe. If all you want is 50 servers, buy a small
mainframe.

Alan Altmark
z/VM Development
IBM

[zVlad]

Dean Kent writes:
>Yes, reliability, fault-tolerance, data integrity,
>etc. are all factors too - but the mainframe does not have a lock on these
>features, other platforms do as well, including those based on x86.

I'm sorry, Dean, but that statement borders on malpractice. If you focus
solely on the chip you're totally missing the point, because business
outcome <> two chips. Why are we still focused on the chip in this
discussion? John Giltner makes an excellent point, and SPEC wouldn't give
you a clue about his situation. Also, the chips, though still important,
are probably the least important architectural component in delivering
reliability, fault tolerance, data integrity, and other service qualities.

As just one example among many, if there's another way to have an
active-active highest availability MQ configuration without using z/OS and
shared queues in an IBM coupling facility, I'd be interested to know what
it is. To pick another example, there's just nothing else like DB2 data
sharing. Even Larry Ellison said so.

Are there any other general purpose business servers constitutionally
capable of delivering five-9s business service availability, no excuses
(i.e. including both planned and unplanned outages)? General purpose here
means, in particular, running middleware that's actually market relevant?

There are niche systems, perhaps. There are also general purpose servers
that don't meet the business service availability levels. Is the
combination of "general purpose" and "highest service qualities" unique to
the IBM mainframe? I think so.

Let me try to make it simple again. An IBM mainframe is, quite literally,
an entire data center in one box. (The earlier server farm comment is
quite correct.) If you can benchmark an entire data center all at once you
might be on to something. As it turns out some of the outsourcing
companies are relatively good at this. You can also get IBM to do the work
independently, dispassionately. One good example:

http://www.ibm.com/servers/library/pdf/scorpion.pdf

- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific