RE: [uanog] Re: [uanog] RE: [uanog] Re: [uanog] Нужны люди, желающие учиться и работать. Направление - внедрение "тяжелых" RISC-систем (Sun, IBM).
-----Original Message----- From: owner-uanog-outgoing@uanog.kiev.ua [mailto:owner-uanog-outgoing@uanog.kiev.ua] On Behalf Of Alexander V Soroka Sent: Wednesday, June 21, 2006 10:02 AM To: Hrynchuk Oleh Subject: [uanog] Re: [uanog] RE: [uanog] Re: [uanog] Нужны люди, желающие учиться и работать. Направление - внедрение "тяжелых" RISC-систем (Sun, IBM).
Привет !
Здарово, Саша.
Tuesday, June 20, 2006, 5:44:45 PM, you wrote: HO> И считать тут некоторые (тот же Дмитрий, к примеру) умеют очень HO> хорошо. Уж поверь мне на слово. Насчет "провайдингу не надо" (хотя HO> смотря какому), то тут ты прав, если имеешь ввиду ISP. Это да.
А вот если насчет "надо Банку" и "деньгу умеют считать" - я тут спорить буду :) кластер на базе 1U писюков - по моему и дешевле и проще получается, к тому-же не понравилось - продал- перепрофилировал
А откуда ты знаешь, что в любой ситуации "дешевле и проще получается"? Есть Банки, а есть банки-"шаромыжники". Банк банку тоже рознь. TCO системы (CapEx + OpEx), предполагающей _выполнение_твоих_задач_, за период 3-5 лет просчитать умеешь? Думаю, да. (Под "выполнением твоих задач" кроме, прежде всего, функционала этой системы я понимаю также необходимую степень доступности обеспечиваемых ею сервисов и готовности составляющих ее ресурсов. Что приводит в общем случае к _надежности_ этой системы). Если тебе пох минуты и часы простоя сервисов и ты не связан оху*нными обязательствами с клиентами - ну так какие проблемы! Ставь писюки и Д-Линки :-). Альтернативы сравнить тоже способен? Или некому простым понятным языком, без тех. выебо*ов, рассказать о всех существенных плюсах и минусах этих разных альтернатив? Не видел систем, построенных на "тяжелых" решениях, для которых ТСО является меньшим (при наличии _полного_ функционала и обеспечении всех требований, необходимых для решения твоих задач), чем систем, построенных на писюках? Ну так я ж не виноват в этом :)
- а Сан как чемодан без ручки - и непонятно куда деть и непонятно как с ним далее жить, да и денег дофига в этом "чемодане". опять-же ИМХО...
Есть задачи, для решения которых клево подойдет тоненькая стамесочка. Но есть и такие, для решения которых нехило вооружиться широким и толстым долотом. Пример? Пожалуйста. Real-time биллинг миллиона ритейловых мобильных, или биллинговых клиентов. Аргументировать, что для конкретно этой задачи решение на Sun/IBM обойдется не в пример лучше и дешевле, чем на сотне кластерных писюков?
У нас, как у "Оператора телефонии и Аудиотекс" - нет ни одного Сана и ИБМ :) у нас кластер небольшой, который все это считает и обслуживает.
Ключевые слова - "у нас кластер небольшой, который все это считает и обслуживает". Круглый дурак бы поспорил. Я - не буду. Совершенно согласен. Вам САНтехники не надо. Бо элементарно задача не предполагает.
А "база" доработана так чтобы реактивней работала - и поверьте, нам хватает. И "писюки" просто тупо меняются раз в три года или раньше - если что-то хорошее появляется и есть смысл в апгрейде...
Ну, я ей-Богу рад за вас. И вместе с тем радостно готов поднять тост за то, чтобы вы быстрее перешли на уровень бизнеса, предполагающий крайнюю необходимость в системах, основанных на Sun/IBM-решениях :))))) С ув., /олег
-- Best regards, Alexander V Soroka http://www.unet.net.ua AS106-RIPE http://www.spacegate.kiev.ua mailto:alex@euro.net.ua
=================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
=================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hrynchuk Oleh wrote:
А "база" доработана так чтобы реактивней работала - и поверьте, нам хватает. И "писюки" просто тупо меняются раз в три года или раньше - если что-то хорошее появляется и есть смысл в апгрейде...
HO> Ну, я ей-Богу рад за вас. HO> И вместе с тем радостно готов поднять тост за то, чтобы вы быстрее перешли на уровень бизнеса, предполагающий крайнюю необходимость в системах, основанных на Sun/IBM-решениях :))))) Вот гугл думает иначе, яха тоже. И любому самом крупному опреатору биллинговой связи тягаться с ними бесполезно. Другое дело - generic тяжелые решения могут влоб пробить любую броню, вопрос в тяжести этого решения. Но мир, как бы мы не поднимали тосты движется в направлении горизонтальной скалируемости и отказоустойчивости, а не к мастодонтам. Нет софта, который бы мог на толпе писюков обеспечивать единую вычислительную среду для generic софта - это факт, но адаптация под такую среду - задача решаемая. -- UKR.NET Postmaster =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Привет ! Wednesday, June 21, 2006, 11:48:34 AM, you wrote:
А вот если насчет "надо Банку" и "деньгу умеют считать" - я тут спорить буду :) кластер на базе 1U писюков - по моему и дешевле и проще получается, к тому-же не понравилось - продал- перепрофилировал
HO> А откуда ты знаешь, что в любой ситуации "дешевле и проще HO> получается"? Олег - я всегда тебя считал вменяемым и образованным :) Не заставляй меня менять мое мнение... Кластер из ДОСТУПНЫХ В ЛЮБОЙ МОМЕНТ на замену компонентов - всегда лучше "тяжелого кирпича" - даже спорить на эту тему не буду. Иначе-бы кино в Голливуде снимали-бы на сверхтяжелых Санах, а не на кластерах - как сейчас. К тому-же опыт Онлайновых игр показывает - что "десятки тысяч клиентов онлайн" - держит почему-то именно кластер, а не супертяжелый Сан... :) ...Олег - не бери пример с МЛМ-щиков - в IT последнее время продажи стали воинствующими - тебе навязывают решения которые тебе в общем-то не нужны в том виде в котором их хотят продать. Технологии идут вперед, и "тяжеловесы" как-то не вписываются - ни по "единичной мощности" ни по прочим параметрам. Хочеш спорить со мной ? Предложи решение для обслуживания EVE-ONLINE (как пример) - вместо их кластера из 73 1U "писюков" - какой мощности Сан ты им предложишь ? Ась ? И какая цена Сана и какая той их кучки писюков - которую, кстати, масштабировать очень легко - докидал еще десяток машин - и полетели - а в Сан чего "докидать" - выбросить старый и купить новый ? HO> Пример? Пожалуйста. Real-time биллинг миллиона ритейловых HO> мобильных, или биллинговых клиентов. Ну и ? :) Онлайн игры как пример подойдут ? почему там идиоты-разработчики не применяют Саны ? :-) HO> Ключевые слова - "у нас кластер небольшой, который все это считает HO> и обслуживает". Круглый дурак бы поспорил. Я - не буду. Совершенно HO> согласен. Вам САНтехники не надо. Бо элементарно задача не HO> предполагает. Задача зато предполагает одновременную обработку аудио вызовов в размерах свыше 100000 вызовов в час, при этом И статистика И работа АВР с каждым вызовом и еще много всего другого :) Так вот "онлайн статистика" - это не самое напряжное во всем этом деле - и не надо лукавить насчет мобильщиков - им тоже саны не нужны :) ... HO> И вместе с тем радостно готов поднять тост за то, чтобы вы HO> быстрее перешли на уровень бизнеса, предполагающий крайнюю HO> необходимость в системах, основанных на Sun/IBM-решениях :))))) не дождетесь. Ибо покупка "тяжелой" уже сейчас просто выбрасывание денег на ветер, без возможности потом "утилизировать"... -- Best regards, Alexander V Soroka http://www.unet.net.ua AS106-RIPE http://www.spacegate.kiev.ua mailto:alex@euro.net.ua =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Wed, Jun 21, 2006 at 16:48:30, alex wrote about "[uanog] Re: [uanog] RE: [uanog] Re: [uanog] RE: [uanog] Re: [uanog] Нужны люди, желающие учиться и работать. Направление - внедрение "тяжелых" RISC-систем (Sun, IBM).": HO>> А откуда ты знаешь, что в любой ситуации "дешевле и проще HO>> получается"?
Олег - я всегда тебя считал вменяемым и образованным :) Не заставляй меня менять мое мнение...
Кластер из ДОСТУПНЫХ В ЛЮБОЙ МОМЕНТ на замену компонентов - всегда лучше "тяжелого кирпича" - даже спорить на эту тему не буду.
А вот поспорьте. Хотя бы для того, чтобы ОТЛИЧАТЬ виды кластеров и потребности их реализации (To all: извините за Caps, ситуация обязывает). Ах, гугль, ах, двадцать тысяч писюков с помойки! Так у гугла и требования к каждому узлу такие же - подумаешь умер диск, подумаешь умер другой, третий - поисковый робот найдёт всё заново. А теперь представим себе такой же подход к финансовой информации... ась? Кластер кластеру рознь. Если задача легко паралеллится - флаг вам в руки! Тогда действительно ставьте стадо писюков, автоналивайку задачи и вперёд. Только вот беда - не получается *все* задачи такими сделать, ну хоть убейся об стену - не получится. А для серьёзных high availability исполнений могут требоваться задачи которые в принципе не решаются писюковым железом - потому что оно не умеет должный уровень самоконтроля и восстановления после ошибок, оно всё работает по принципу "Семь бед - один Reset".
Иначе-бы кино в Голливуде снимали-бы на сверхтяжелых Санах, а не на кластерах - как сейчас. К тому-же опыт Онлайновых игр показывает - что "десятки тысяч клиентов онлайн" - держит почему-то именно кластер, а не супертяжелый Сан... :)
Кино снимать - это ещё один гугль, потому что отдать каждому тазу свой кусок картинки и затем их сложить - и первокурсник сможет. Плохой пример.
...Олег - не бери пример с МЛМ-щиков - в IT последнее время продажи стали воинствующими - тебе навязывают решения которые тебе в общем-то не нужны в том виде в котором их хотят продать. Технологии идут вперед, и "тяжеловесы" как-то не вписываются - ни по "единичной мощности" ни по прочим параметрам. Хочеш спорить со мной ? Предложи решение для обслуживания EVE-ONLINE (как пример) - вместо их кластера из 73 1U "писюков" - какой мощности Сан ты им предложишь ? Ась ? И какая цена Сана и какая той их кучки писюков - которую, кстати, масштабировать очень легко - докидал еще десяток машин - и полетели - а в Сан чего "докидать" - выбросить старый и купить новый ?
EVE-ONLINE, говорите? Заходим на первую страницу: === cut === Мы собираемся поставить новый патч серии Bloodlines во вторник, 6 июня. Всвязи с этим, ДТ начнется в 11.00 по Гринвичу (GMT) и закончится в 15.00. === end cut === в нормальных системах (а не игрушках) downtime подобного типа вообще не бывает (всё меняется на ходу), а если бывает - то сводится к секундам, а не часам. Это азы, и странно что их приходится объяснять. Вместо подобных игрушек лучше посмотрите на систему... мнэээ... бронирования билетов. Общую по стране. Там такой downtime допустим?:)) HO>> Пример? Пожалуйста. Real-time биллинг миллиона ритейловых HO>> мобильных, или биллинговых клиентов.
Ну и ? :) Онлайн игры как пример подойдут ? почему там идиоты-разработчики не применяют Саны ? :-)
Им - действительно не нужно - им и 4 часа проваляться можно, и на стандартной Windows всё строить. Это вам не финансы. HO>> Ключевые слова - "у нас кластер небольшой, который все это считает HO>> и обслуживает". Круглый дурак бы поспорил. Я - не буду. Совершенно HO>> согласен. Вам САНтехники не надо. Бо элементарно задача не HO>> предполагает.
Задача зато предполагает одновременную обработку аудио вызовов в размерах свыше 100000 вызовов в час, при этом И статистика И работа АВР с каждым вызовом и еще много всего другого :) Так вот "онлайн статистика" - это не самое напряжное во всем этом деле - и не надо лукавить насчет мобильщиков - им тоже саны не нужны :) ...
Бедняжки, они этого не знают - что им саны не нужны. Наверно, им даже SCSI (которое SMALL computers system interface) не нужно, а массовые IDE диски которые плюют на контрольные суммы по шине и врут что отключили write-back кэш - самое оно чтобы хранить свои данные и верить в надёжность хранилища баз данных. O tempora... 27 звонков в секунду - кстати, уровень как раз одного хорошего писюка:) и совсем не тот уровень который требует чего-то большего. HO>> И вместе с тем радостно готов поднять тост за то, чтобы вы HO>> быстрее перешли на уровень бизнеса, предполагающий крайнюю HO>> необходимость в системах, основанных на Sun/IBM-решениях :)))))
не дождетесь. Ибо покупка "тяжелой" уже сейчас просто выбрасывание денег на ветер, без возможности потом "утилизировать"...
Ну так всё закономерно - многое из того что раньше решалось _только_ на "тяжёлых" решениях сейчас решается на бытовом писюке. И что, от этого не осталось серьёзных задач? Прц! -netch- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Привет ! Wednesday, June 21, 2006, 6:08:48 PM, you wrote: VN> А вот поспорьте. Хотя бы для того, чтобы ОТЛИЧАТЬ виды кластеров и VN> потребности их реализации (To all: извините за Caps, ситуация VN> обязывает). Ах, гугль, ах, двадцать тысяч писюков с помойки! Так у VN> гугла и требования к каждому узлу такие же - подумаешь умер диск, VN> подумаешь умер другой, третий - поисковый робот найдёт всё заново. VN> А теперь представим себе такой же подход к финансовой VN> информации... ась? РАИД винтов с батарейками - лечит. VN> Кластер кластеру рознь. Если задача легко паралеллится - флаг вам VN> в руки! Тогда действительно ставьте стадо писюков, автоналивайку VN> задачи и вперёд. Только вот беда - не получается *все* задачи VN> такими сделать, ну хоть убейся об стену - не получится. А какие задачи требуют именно СуперСана ? :) Ну - давай - сказал А скажи Б ! VN> А для серьёзных high availability исполнений могут требоваться VN> задачи которые в принципе не решаются писюковым железом - потому что VN> оно не умеет должный уровень самоконтроля и восстановления после VN> ошибок, оно всё работает по принципу "Семь бед - один Reset". Не лукавим, Ок ? :) как раз когда куча всего само за собой следит - это лучше чем "один большой шкаф упал"... VN> EVE-ONLINE, говорите? Заходим на первую страницу: VN> === cut === VN> Мы собираемся поставить новый патч серии Bloodlines во вторник, 6 VN> июня. Всвязи с этим, ДТ начнется в 11.00 по Гринвичу (GMT) и VN> закончится в 15.00. VN> === end cut === VN> в нормальных системах (а не игрушках) downtime подобного типа VN> вообще не бывает (всё меняется на ходу), а если бывает - то VN> сводится к секундам, а не часам. Это азы, и странно что их VN> приходится объяснять. Для тех кто не в курсе - РАССКАЗЫВАЮ - "патчи" в Еве - это не "латание ошибок" в настоящее время, это "развитие мира", и нельзя без прерывания это развитие вводить - проще мир "уронить и переписать" чтобы потом все сразу увидели "новое". Тут и Саны не помогут - это особенность такая вот у Игры... А вот сама игра я что-то не помню чтобы что-то теряла - вещи игроков например, или обьекты какие-то :) VN> Вместо подобных игрушек лучше посмотрите на систему... мнэээ... VN> бронирования билетов. Общую по стране. Там такой downtime VN> допустим?:)) Захожу в Аваль где-то в Мариуполе-Бердянске и т.п. - постоянные проблемы с платежами - то "сеть в Киеве легла" то еще что-то. Я уже молчу про наш любимый "центр обработки транзакций" имени банкоматов - носить с собой карточку - это значит в нужный момент остаться без денег вообще. И там тоже "тяжелые" применяются - не помогает как вижу... Валентин - давайте не лукавить ? :) VN> Им - действительно не нужно - им и 4 часа проваляться можно, и на VN> стандартной Windows всё строить. Это вам не финансы. Пример Аваля и "процессингового центра" - подтверждает крылатую фразу "зачем платить больше ?" :) ...любая СУБД щас поддерживает "откат транзакций" - так что все можно либо откатить либо разобраться что и почему. Винты с батарейками уже серийно выпускаются :) ... VN> Бедняжки, они этого не знают - что им саны не нужны. Наверно, им VN> даже SCSI (которое SMALL computers system interface) не нужно, а VN> массовые IDE диски которые плюют на контрольные суммы по шине и VN> врут что отключили write-back кэш - самое оно чтобы хранить свои VN> данные и верить в надёжность хранилища баз данных. O tempora... Опять лукавство - мобильшики в большинстве "просто купили что предлагается" и все - им никто не дал даже подумать что есть решения которые решат их проблему перегрузок "суперкомпа". Вот Утел у нас в украине самый большой покупатель Циско :) И что с того ? полные склады накупили а как заставить работать "как в книжке" - так до сих пор плющит и колбасит... а в книжках только "ура! все будет работать если вы купите нашу Циску и к ней супер систему управления!" Купили - завели - не помогло :) ... И "руки" тут не при чем - я вникал что "внутри" происходило когда Утел систему разворачивал и пытался заставить работать :) с "тяжелыми" - будет такая-же фигня, только еще море денег на доводку-дописку и поиск багов в софте, который "супернадежен и непадуч" :) ... VN> 27 звонков в секунду - кстати, уровень как раз одного хорошего VN> писюка:) и совсем не тот уровень который требует чего-то большего. 27 каких звонков :) к каждому надо отдельный подход, это не просто "переключил и забыл"... Транзакции, батенька, + куча ресурсов на обработку... -- Best regards, Alexander V Soroka http://www.unet.net.ua AS106-RIPE http://www.spacegate.kiev.ua mailto:alex@euro.net.ua =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hi Valentin,
Вместо подобных игрушек лучше посмотрите на систему... мнэээ... бронирования билетов. Общую по стране. Там такой downtime допустим?:))
Каких билетов? Фирмы Аэросвит? Или про государственную железную дорогу речь, где свободные места заранее резервируются за местами продажи? По-моему все же плохой пример. Вот возьми International Space Station. У русских Sun, у американцев NT, жесткие диски все время сыпятся (у американцев), меняли больше 10 раз уже - вот вам и реклама. Правда downtime в полтора суток здоровью не повредил (повредил финансам). С одной стороны, хочется за примерами идти к опасным и непрерывным процессам реального времени (управление АЭС, например), но с ними надежность заменяется резервированием и параллельностью. Не смог нагуглить, но вот, скажем, http://submarine.id.ru/cp/z38.shtml: "Каким же требованиям должна отвечать микроЭВМ, размещенная на субмарине? Во-первых, повышенная надежность на основе многократного резервирования." Насколько я помню, дублирование доходило до 7-кратного... -- Michael Every time I close the door on reality it comes in through the windows. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Wed, Jun 21, 2006 at 18:37:50, alex wrote about "[uanog] Re: [uanog] Re: Нужны люди, желающие учиться и работать. Направление - внедрение "тяжелых" RISC-систем (Sun, IBM).": VN>> А вот поспорьте. Хотя бы для того, чтобы ОТЛИЧАТЬ виды кластеров и VN>> потребности их реализации (To all: извините за Caps, ситуация VN>> обязывает). Ах, гугль, ах, двадцать тысяч писюков с помойки! Так у VN>> гугла и требования к каждому узлу такие же - подумаешь умер диск, VN>> подумаешь умер другой, третий - поисковый робот найдёт всё заново. VN>> А теперь представим себе такой же подход к финансовой VN>> информации... ась?
РАИД винтов с батарейками - лечит.
Угу. И кластер? Так и представляю себе десять тысяч тазов, у каждого RAID с батарейкой:) Или выделим отдельно хранилище, отдельно процессинг? Ага, NFS между ними:)))) VN>> Кластер кластеру рознь. Если задача легко паралеллится - флаг вам VN>> в руки! Тогда действительно ставьте стадо писюков, автоналивайку VN>> задачи и вперёд. Только вот беда - не получается *все* задачи VN>> такими сделать, ну хоть убейся об стену - не получится.
А какие задачи требуют именно СуперСана ? :) Ну - давай - сказал А скажи Б !
А я не говорил про "СуперСан". Впрочем, можно и определить подобный класс задач, одним простым принципом: сложная ресурсоёмкая обработка непригодная к распараллеливанию. И начинается это с баз данных. (Частично оно, конечно, параллелится. Но несерьёзно предполагать получение на этом серьёзного выигрыша не сделав принципиального разделения ролей между движками.) VN>> А для серьёзных high availability исполнений могут требоваться VN>> задачи которые в принципе не решаются писюковым железом - потому что VN>> оно не умеет должный уровень самоконтроля и восстановления после VN>> ошибок, оно всё работает по принципу "Семь бед - один Reset".
Не лукавим, Ок ? :)
У Вас какие-то претензии к сути изложенного? Не понимаю. Про диски я уже рассказал. Ещё вспомним что у вполне серьёзного производителя можно нарваться на отсутствие _реального_ ECC (несмотря на все репорты планки и наличие 9-го кристалла), а уж качество поставок вообще не выражается словами - нарваться на перемаркированные элементы как раз плюнуть.
как раз когда куча всего само за собой следит - это лучше чем "один большой шкаф упал"...
В этом "одном шкафу" может быть много разного почти независимого друг от друга, но совершенно не обязательно что PC будет выполнять иную роль чем запускалку /usr/bin/tn3270 :) VN>> EVE-ONLINE, говорите? Заходим на первую страницу: VN>> === cut === VN>> Мы собираемся поставить новый патч серии Bloodlines во вторник, 6 VN>> июня. Всвязи с этим, ДТ начнется в 11.00 по Гринвичу (GMT) и VN>> закончится в 15.00. VN>> === end cut === VN>> в нормальных системах (а не игрушках) downtime подобного типа VN>> вообще не бывает (всё меняется на ходу), а если бывает - то VN>> сводится к секундам, а не часам. Это азы, и странно что их VN>> приходится объяснять.
Для тех кто не в курсе - РАССКАЗЫВАЮ - "патчи" в Еве - это не "латание ошибок" в настоящее время, это "развитие мира", и нельзя без прерывания это развитие вводить - проще мир "уронить и переписать" чтобы потом все сразу увидели "новое". Тут и Саны не помогут - это особенность такая вот у Игры... А вот сама игра я что-то не помню чтобы что-то теряла - вещи игроков например, или обьекты какие-то :)
Неважно что они называют словом "патч" - это какое-то изменение функциональности. Так вот на то она и игровая среда что допускает, что ради изменения функциональности всё останавливается. VN>> Вместо подобных игрушек лучше посмотрите на систему... мнэээ... VN>> бронирования билетов. Общую по стране. Там такой downtime VN>> допустим?:))
Захожу в Аваль где-то в Мариуполе-Бердянске и т.п. - постоянные проблемы с платежами - то "сеть в Киеве легла" то еще что-то. Я уже молчу про наш любимый "центр обработки транзакций" имени банкоматов - носить с собой карточку - это значит в нужный момент остаться без денег вообще. И там тоже "тяжелые" применяются - не помогает как вижу... Валентин - давайте не лукавить ? :)
Давайте. Я не про Аваль вспоминал, а несколько про другие структуры и системы. VN>> Им - действительно не нужно - им и 4 часа проваляться можно, и на VN>> стандартной Windows всё строить. Это вам не финансы.
Пример Аваля и "процессингового центра" - подтверждает крылатую фразу "зачем платить больше ?" :) ...любая СУБД щас поддерживает "откат транзакций" - так что все можно либо откатить либо разобраться что и почему. Винты с батарейками уже серийно выпускаются :) ...
Если понимать откат транзакции как новую транзакцию с обратным действием - ну да, но при чём тут это вообще? Это даёт право процессинговому центру валяться? VN>> Бедняжки, они этого не знают - что им саны не нужны. Наверно, им VN>> даже SCSI (которое SMALL computers system interface) не нужно, а VN>> массовые IDE диски которые плюют на контрольные суммы по шине и VN>> врут что отключили write-back кэш - самое оно чтобы хранить свои VN>> данные и верить в надёжность хранилища баз данных. O tempora...
Опять лукавство - мобильшики в большинстве "просто купили что предлагается" и все - им никто не дал даже подумать что есть решения которые решат их проблему перегрузок "суперкомпа". Вот Утел у нас в украине самый большой покупатель Циско :) И что с того ? полные склады накупили а как заставить работать "как в книжке" - так до сих пор плющит и колбасит... а в книжках только "ура! все будет работать если вы купите нашу Циску и к ней супер систему управления!" Купили - завели - не помогло :) ...
Лукавите как раз Вы. Покупатель не думает, позволяет себе впихнуть то что ему не нужно - какое это отношение имеет к реальным нуждам? Ну да, дай дураку в руки нефритовый стебель - он и стебель сломает, и руки порежет. Это избавляет от факта что кому-то реально нужны такие возможности и мощности? Мы вот на LN тоже когда-то покупали саны:) И это было реально полезно - тогда такой уровень не мог обеспечить PC. И сейчас есть применение в которое сколько ни впихивай писюковой мощности - всё будет мало. Другой вопрос, что не больно-то и хотелось - ну дык всем известно что в первой встречной лавке на пять продавцов и одного бухгалтера даже 1Gb/s сеть прогибается:)
И "руки" тут не при чем - я вникал что "внутри" происходило когда Утел систему разворачивал и пытался заставить работать :) с "тяжелыми" - будет такая-же фигня, только еще море денег на доводку-дописку и поиск багов в софте, который "супернадежен и непадуч" :) ...
В конкретном случае - ВЕРЮ. Что купили ненужное, не сумели применить как следует - ВЕРЮ. Опровергает это что-то в моих/Олега словах? НЕТ. VN>> 27 звонков в секунду - кстати, уровень как раз одного хорошего VN>> писюка:) и совсем не тот уровень который требует чего-то большего.
27 каких звонков :) к каждому надо отдельный подход, это не просто "переключил и забыл"... Транзакции, батенька, + куча ресурсов на обработку...
А то я не видел системы которые и бОльший поток авторизуют, биллят и ещё и применяют массу разнообразной обработки. Нет, это всё ещё писюшатина. Вот выйти на 200 звонков в секунду - придётся или упрощать обработку до предела, или уже серьёзно думать о том как это делать - и железо будет играть не последнюю роль. -netch- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hi Valentin,
А я не говорил про "СуперСан". Впрочем, можно и определить подобный класс задач, одним простым принципом: сложная ресурсоёмкая обработка непригодная к распараллеливанию. И начинается это с баз данных. (Частично оно, конечно, параллелится. Но несерьёзно предполагать получение на этом серьёзного выигрыша не сделав принципиального разделения ролей между движками.)
Соотв-но за что же ты в результате больше хвалишь "тяжелые" системы - за качество+надежность или за быстродействие? Соотв-но вопрос, в каких же задачах виден существенный отрыв этого самого быстродействия? -- Michael Наджибулла была со мной любезна. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Valentin Nechayev wrote:
Кластер из ДОСТУПНЫХ В ЛЮБОЙ МОМЕНТ на замену компонентов - всегда лучше "тяжелого кирпича" - даже спорить на эту тему не буду.
VN> А вот поспорьте. Хотя бы для того, чтобы ОТЛИЧАТЬ виды кластеров и VN> потребности их реализации (To all: извините за Caps, ситуация VN> обязывает). Ах, гугль, ах, двадцать тысяч писюков с помойки! Так у VN> гугла и требования к каждому узлу такие же - подумаешь умер диск, VN> подумаешь умер другой, третий - поисковый робот найдёт всё заново. VN> А теперь представим себе такой же подход к финансовой информации... VN> ась? То же самое. С точки зрения философии - это система хранения информации. Вопрос в том, что SAN'ы со всеми фичами онлайновых снапшотов и multipath уже есть, а вот в случа гугла писать надо *всё* руками, вобще всё. VN> Кластер кластеру рознь. Если задача легко паралеллится - флаг вам в VN> руки! Тогда действительно ставьте стадо писюков, автоналивайку VN> задачи и вперёд. Только вот беда - не получается *все* задачи такими VN> сделать, ну хоть убейся об стену - не получится. Покажи что нельзя параллелить в концепте системы массового обслуживания, для которых кластера и делаются. VN> А для серьёзных high availability исполнений могут требоваться VN> задачи которые в принципе не решаются писюковым железом - потому что VN> оно не умеет должный уровень самоконтроля и восстановления после VN> ошибок, оно всё работает по принципу "Семь бед - один Reset". А оно работает по стандартному ACID механизму: не сработала транзакция, откат, выкинули писюк из пула.
Иначе-бы кино в Голливуде снимали-бы на сверхтяжелых Санах, а не на кластерах - как сейчас. К тому-же опыт Онлайновых игр показывает - что "десятки тысяч клиентов онлайн" - держит почему-то именно кластер, а не супертяжелый Сан... :)
VN> Кино снимать - это ещё один гугль, потому что отдать каждому тазу VN> свой кусок картинки и затем их сложить - и первокурсник сможет. VN> Плохой пример. Та не, это в концепте голливуда - плохой пример, с точки зрения гугля - это задача, извините, нiiб@цца. Гугл - это система менеджмента информации со своим архетипом. Система банкинга, биллинга, короче любая система работающая по принципу клиент->API->бизнес_логика->система_хранения подчиняются правилу гугл-лайк. Софт, работающий в режиме атомарных коротких операций уже подчиняется этому правилу. VN> EVE-ONLINE, говорите? Заходим на первую страницу: VN> === cut === VN> Мы собираемся поставить новый патч серии Bloodlines во вторник, 6 VN> июня. Всвязи с этим, ДТ начнется в 11.00 по Гринвичу (GMT) и VN> закончится в 15.00. VN> === end cut === VN> в нормальных системах (а не игрушках) downtime подобного типа вообще VN> не бывает (всё меняется на ходу), а если бывает - то сводится к Еще и как бывает. Load testing можно провести только на живой системе, причем если у тебя меняется API внутри, то без "все встали, потом сели" не получится. Другое дело, что планируемый downtime может быть между 11 и 15-ю часами, а собственно сам downtime может быть незаметен. С точки зрения аппликух tcp'шного типа произойдёт разрыв сессии с конкретным фронтендом со всеми вытекающими. VN> секундам, а не часам. Это азы, и странно что их приходится VN> объяснять. VN> Вместо подобных игрушек лучше посмотрите на систему... мнэээ... VN> бронирования билетов. Общую по стране. Там такой downtime VN> допустим?:)) Ты на наши банки посмотри ;-) -- UKR.NET Postmaster =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Привет ! Wednesday, June 21, 2006, 7:04:01 PM, you wrote: MP> С одной стороны, хочется за примерами идти к опасным и непрерывным MP> процессам реального времени (управление АЭС, например), но с ними MP> надежность заменяется резервированием и параллельностью. Не смог MP> нагуглить, но вот, скажем, http://submarine.id.ru/cp/z38.shtml: MP> "Каким же требованиям должна отвечать микроЭВМ, размещенная на MP> субмарине? Во-первых, повышенная надежность на основе MP> многократного резервирования." Насколько я помню, дублирование MP> доходило до 7-кратного... Вот только НЕ НАДО мне, старому подводнику :) рассказывать сказок про "7-и кратное резервирование" и вообще про "ЭВМ на подводной лодке" Ок? Шоб вы знали - в системах управления реакторами ЭВМ вообще нет - там спец.комплексы вообще на магнитных усилителях и реле - ПОЧЕМУ ? А просто потому что при повышенной радиации ОНО РАБОТАЕТ, в отличие от полупроводников, которым крышу сносит. В свою бытность курсантом изучал "почему так" - так вот я был лично знаком с контр-адмиралом (лекции нам читал по реакторам) из-за докторской диссертации которого наш флот, и не начиная, перестал применять "ЭВМ" в контурах управления реактором - весьма поучительная дисертация была - все на базе реальных испытаних полупроводниковых схем при разном уровне облучения... Да и то что лепят на "гражданские реакторы" - тоже весьма условно можно назвать "ЭВМ"... Насчет подводных лодок :) Там единственная "ЭВМ" - это БИУС (боевая информационная управляющая система) которая считает данные для запуска ракет, на основе данных от навигационного комплекса. Так вот - несмотря на ДВУКРАТНОЕ РЕЗЕРВИРОВАНИЕ ПО ПИТАНИЮ :) она бывало не нарабатывала свои 18 часов "холодного старта" - приходилось все заново... И новые комплексы хоть и поправили немного но тоже всего-то двукратного резервирования, т.е. когда одно сломалось - то второе можно ввести вместо него :) -- Best regards, Alexander V Soroka http://www.unet.net.ua AS106-RIPE http://www.spacegate.kiev.ua mailto:alex@euro.net.ua =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Привет ! Wednesday, June 21, 2006, 7:13:49 PM, you wrote:
РАИД винтов с батарейками - лечит. VN> Угу. И кластер? Так и представляю себе десять тысяч тазов, у VN> каждого RAID с батарейкой:) Или выделим отдельно хранилище, VN> отдельно процессинг? Ага, NFS между ними:))))
Я уже давал эту ссылку на "винты с батарейками" : http://www-03.ibm.com/servers/storage/disk/ds4000/ds4300/index.html http://www.superwarehouse.com/IBM_TotalStorage_FASt_EXP700_Storage_Cabinet/2... ...и еще было на имени Техас Инструменстс - там самые быстрые сборки винтов в мире :) - все для кластеров :) VN> А я не говорил про "СуперСан". Впрочем, можно и определить подобный VN> класс задач, одним простым принципом: сложная ресурсоёмкая обработка VN> непригодная к распараллеливанию. И начинается это с баз данных. Ок - твой "слив" защитан :)
носить с собой карточку - это значит в нужный момент остаться без денег вообще. И там тоже "тяжелые" применяются - не помогает как вижу... Валентин - давайте не лукавить ? :)
VN> Давайте. Я не про Аваль вспоминал, а несколько про другие структуры VN> и системы. Например какие ? :) Ну давайте - пример где стоит "кирпич" и от этого всем тепло сухо и комфортно, да еще и при отвале частей задачи все не падает и ТСП сессии не рвутся - я хочу услышать РЕАЛЬНЫЙ пример. VN> Если понимать откат транзакции как новую транзакцию с обратным VN> действием - ну да, но при чём тут это вообще? Это даёт право VN> процессинговому центру валяться? Надо лечить от лукавства :) ... Переиначу вопрос: "А что, применение "кирпича" НЕ ПОЗВОЛИТ процессинговому центру валяться ???" Зачем тогда платить больше ? :) ...Вот у меня, например, Цисок в провайдинге вообще нет :) раутинг на мощном писюке и Зебре - и ниче - работает месяцами без падучей и прочих проблем, несколько полных таблиц при этом держит :) Даже при том что я провожу плановую замену этого писюка раз в 1.5 года он мне окупается многократно, если сравнивать сколько бабла я должен был потратить на циску аналогичной сетевой производительности :)
накупили а как заставить работать "как в книжке" - так до сих пор плющит и колбасит... а в книжках только "ура! все будет работать если вы купите нашу Циску и к ней супер систему управления!" Купили - завели - не помогло :) ...
VN> Лукавите как раз Вы. Покупатель не думает, позволяет себе впихнуть VN> то что ему не нужно - какое это отношение имеет к реальным нуждам? Прямое - тут людей набирают чтобы "впихнуть" кирпичи, потому что Продавцу НАДО ПРОДАТЬ, а не Покупателю купить. Разницу видите ? ...теперь продажа кирпичей, на думку Продавца, будет идти лучше, потому что "спецы" должны придумывать новые наукообразные методы "втюхивания" кирпичей, пользуясь своим опытом и Именем :) Вот Вы все так и не смогли мне Сан продать :) как не старались :) мало того - только утвердили в мысли что проблемы можно и нужно решать головой и простыми средствами. :) Низачот вообщем :) VN> Мы вот на LN тоже когда-то покупали саны:) И это было реально VN> полезно - тогда такой уровень не мог обеспечить PC. И сейчас есть VN> применение в которое сколько ни впихивай писюковой мощности - всё VN> будет мало "Когда-то" - покупали, потому что денег на это вам не жалели и не спрашивали за эффективность таковых решений. :) Если просто все отдать на откуп "технарям" и не контролировать что куда и ЗАЧЕМ - то контора скоро весь свой доход будет тратить на "суперсовременные железки" которые покупать будет постоянно, не зависимо от цели и необходимости - просто потому что "технарям" захотелось новую игрушку, а подумать и оптимизировать процесс - им влом, им надо крутизну свою среди таких-же показывать - вот мы каие "модные и современные" - не успел Сан выпустит железку - а у нас уже стоит :) ...помню я Лаки старых времен и слабость некоторых прошлых руководителей :) к Санам и крутым Цискам :) деньги при этом были далеко не главным фактором вообще... VN> Вот выйти на 200 звонков в секунду - придётся или упрощать VN> обработку до предела, или уже серьёзно думать о том как это делать VN> - и железо будет играть не последнюю роль. Угу - сразу видно что вы не в теме :) Кластер такое решает легко, а "упрощать" - не всегда получается, там есть свои фичи без которых нельзя. -- Best regards, Alexander V Soroka http://www.unet.net.ua AS106-RIPE http://www.spacegate.kiev.ua mailto:alex@euro.net.ua =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Привет всем ! По-моему пора подводить итог темы :) 1) слив любителей "кирпичей" - защитан :) меня никто не переубедил. 2) мне так до сих пор и не посчитали (хоть-бы примерно) какой крутизны Сан я должен поставить на обслуживание Игрового сервера для ММОРПГ с проектной производительностью примерно в 20000 игроков одновременно. А это зря - осень-зима у меня стартует свой проект, так что я как раз внимательно рассматриваю все варианты Серверной части, потому что грабли надо откапывать заранее :) чтобы потом по ним не ходить. 3) Вызывает удивление "виток истории" когда именитая компания повторяет ошибки 90-х годов и еще при этом применяет методы массового давления на психику покупателей... Видать не все в порядке в датском королевстве, раз такие методы применять начинают... Не всем выборы пошли на пользу... :) -- Best regards, Alexander V Soroka http://www.unet.net.ua AS106-RIPE http://www.spacegate.kiev.ua mailto:alex@euro.net.ua =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Thu, Jun 22, 2006 at 09:21:16, alex wrote about "[uanog] Re: [uanog] Re: [uanog] Re: Нужны люди, желающие учиться и работать. Направление - внедрение "тяжелых" RISC-систем (Sun, IBM).":
По-моему пора подводить итог темы :) 1) слив любителей "кирпичей" - защитан :) меня никто не переубедил.
Как и в обратном - Вы не переубедили что ниша для "кирпичей" есть. Если есть Ваше мнение, почему бы не быть другому?;)) ... я уж не говорю что утверждать "никто не переубедил" после 1 (прописью: одной) нерабочей ночи - высший пилотаж дискуссии, на уровне - заткнуть собеседнику рот и сказать "вот видите, возражений нет"
2) мне так до сих пор и не посчитали (хоть-бы примерно) какой крутизны Сан я должен поставить на обслуживание Игрового сервера для ММОРПГ с проектной производительностью примерно в 20000 игроков одновременно. А
А давайте вначале определим _почему_ кто-то из оппонентов должен это считать (по данным, которые Вы НЕ ПРЕДОСТАВИЛИ)? По такой "спецификации" как "20000 игроков" нагрузки могут отличаться на три порядка.
это зря - осень-зима у меня стартует свой проект, так что я как раз внимательно рассматриваю все варианты Серверной части, потому что
Кидая пальцы в UANOG "у меня 20000 игроков!!!" и не сказав про них совершенно ничего конкретного. Да, действительно "слив защитан"
грабли надо откапывать заранее :) чтобы потом по ним не ходить.
3) Вызывает удивление "виток истории" когда именитая компания повторяет ошибки 90-х годов и еще при этом применяет методы массового давления на психику покупателей... Видать не все в порядке в датском королевстве, раз такие методы применять начинают... Не всем выборы пошли на пользу... :)
Кто на кого давит-то? Судя по плотности текстов и эмоций давление идёт строго с противоположной стороны. -netch- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Thu, Jun 22, 2006 at 09:10:49, alex wrote about "[uanog] Re: [uanog] Re: Нужны люди, желающие учиться и работать. Направление - внедрение "тяжелых" RISC-систем (Sun, IBM).":
РАИД винтов с батарейками - лечит. VN> Угу. И кластер? Так и представляю себе десять тысяч тазов, у VN> каждого RAID с батарейкой:) Или выделим отдельно хранилище, VN> отдельно процессинг? Ага, NFS между ними:))))
Я уже давал эту ссылку на "винты с батарейками" : http://www-03.ibm.com/servers/storage/disk/ds4000/ds4300/index.html http://www.superwarehouse.com/IBM_TotalStorage_FASt_EXP700_Storage_Cabinet/2...
Ну и? Что такое существуют - не надо мне рассказывать, сам настраивал (не такую модель, но того же типа). Что оно даст для данного случая? Во втором - FC/2G, спасибо - значит, если один backend работает с диском - он точка отказа, а если два - между ними возникает HAC весьма непростой организации (корректный одновременный доступ в БД и вообще на диск - задача ой нетривиальная). Гуглевое решение и то принципиально лучше с точки зрения кластеризации - потому что у них одни данные лежат на трёх хостах (если рекламные статьи не врут). Но у них слишком легко всё параллелится. VN> А я не говорил про "СуперСан". Впрочем, можно и определить подобный VN> класс задач, одним простым принципом: сложная ресурсоёмкая обработка VN> непригодная к распараллеливанию. И начинается это с баз данных.
Ок - твой "слив" защитан :)
Нет, не защитан. Вы не знаете подобных задач? Не ваша задача? Верю. VN> Давайте. Я не про Аваль вспоминал, а несколько про другие структуры VN> и системы.
Например какие ? :) Ну давайте - пример где стоит "кирпич" и от этого всем тепло сухо и комфортно, да еще и при отвале частей задачи все не падает и ТСП сессии не рвутся - я хочу услышать РЕАЛЬНЫЙ пример.
"TCP сессии не рвутся" - я уже пояснил почему не считаю это аргументом и вообще необходимостью. А места где стоит "кирпич" - извините, не могу выдавать. Да, это повод к Вашему очередному "слив защитан". Извините-с, если предыдущая работа разрешит - расскажу. Сами вендоры (вроде той же IBM) позволяют себе называть клиентов, смотрите у них. VN> Если понимать откат транзакции как новую транзакцию с обратным VN> действием - ну да, но при чём тут это вообще? Это даёт право VN> процессинговому центру валяться?
Надо лечить от лукавства :) ... Переиначу вопрос: "А что, применение "кирпича" НЕ ПОЗВОЛИТ процессинговому центру валяться ???" Зачем тогда платить больше ? :)
Нет, корректно сформулировать так: "чтобы не валялся" - задача требующая особой организации системы, и для определённых задач и начиная с некоторых требуемых уровней надёжности это может быть решено _только_ на так называемых "кирпичах". (Что составляет малую часть от всех решений класса "чтобы не валялся", с этим я никогда и не спорил.) Причина этому - по-настоящему качественное железо (в котором ситуации типа "ECC генерируется, но не проверяется") не может быть в принципе), другие средства организации уже на аппаратном уровне (позволяющие определить и локализовать сбой уже на этапе возникновения, а не когда вся система начинает идти вразнос), оптимизация архитектуры под масштабирование нагрузки и под её кластеризацию (ни того не другого у x86 никогда не было). И как следствие аппаратных возможностей - ПО которое пишется только или почти только под такое железо (и объедки которого уже достаются писюкам).
...Вот у меня, например, Цисок в провайдинге вообще нет :) раутинг на мощном писюке и Зебре - и ниче - работает месяцами без падучей и прочих проблем, несколько полных таблиц при этом держит :)
Угу, зебра умеет. А вот чуть за пределы держания трёх fullview выйти - и начинает сосать по полной, потому что полной фичастости BGP у неё не было и нет. Посему для ISP она применима только для мелкого.
Даже при том что я провожу плановую замену этого писюка раз в 1.5 года он мне окупается многократно, если сравнивать сколько бабла я должен был потратить на циску аналогичной сетевой производительности :)
Я рад за Вас:) VN> Лукавите как раз Вы. Покупатель не думает, позволяет себе впихнуть VN> то что ему не нужно - какое это отношение имеет к реальным нуждам?
Прямое - тут людей набирают чтобы "впихнуть" кирпичи, потому что Продавцу НАДО ПРОДАТЬ, а не Покупателю купить. Разницу видите ?
Разницу вижу, логики в данном аргументе - нет, по причине её отсутствия. Покупателю - если он вообще пришёл к такому продавцу - нужно нечто уровня явно выше чем два писюка. И тут действительно начинается в том числе и маркетинговая игра. А теперь смотрим исходное письмо и видим что нужны люди на ВНЕДРЕНИЕ систем. То есть ТЕХНАРИ. Итак, кто тут лукавит? По-моему - некто А.В.С.
...теперь продажа кирпичей, на думку Продавца, будет идти лучше, потому что "спецы" должны придумывать новые наукообразные методы "втюхивания" кирпичей, пользуясь своим опытом и Именем :)
Не путаете маркетоедов и технарей? По-моему - путаете:)
Вот Вы все так и не смогли мне Сан продать :) как не старались :)
Я? Не старался. Вам он действительно не нужен, я это вижу уже по постановке задачи.
VN> Мы вот на LN тоже когда-то покупали саны:) И это было реально VN> полезно - тогда такой уровень не мог обеспечить PC. И сейчас есть VN> применение в которое сколько ни впихивай писюковой мощности - всё VN> будет мало "Когда-то" - покупали, потому что денег на это вам не жалели и не спрашивали за эффективность таковых решений. :)
Потому что в 99-м PC РЕАЛЬНО не тянул то что нам надо было (а если тянул то стоил больше того Сана). И покупка оправдалась.
...помню я Лаки старых времен и слабость некоторых прошлых руководителей :) к Санам и крутым Цискам :) деньги при этом были далеко не главным фактором вообще...
Васильич, ВСЕ тогдашние вложения в железо - окупились и очень быстро. Это я Вам как достаточно беспристрастный ко всем этим переворотам внутренний наблюдатель говорю. VN> Вот выйти на 200 звонков в секунду - придётся или упрощать VN> обработку до предела, или уже серьёзно думать о том как это делать VN> - и железо будет играть не последнюю роль.
Угу - сразу видно что вы не в теме :) Кластер такое решает легко, а "упрощать" - не всегда получается, там есть свои фичи без которых нельзя.
Да, вашу систему я не видел. А кластер - вот у вас трансферы (хотя бы blind) между внутренними endpoint'ами бывают? -netch- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hi Alexander,
Вот только НЕ НАДО мне, старому подводнику :) рассказывать сказок про "7-и кратное резервирование" и вообще про "ЭВМ на подводной лодке" Ок?
Шоб вы знали - в системах управления реакторами ЭВМ вообще нет - там спец.комплексы вообще на магнитных усилителях и реле - ПОЧЕМУ ?
ЭВМ вполне можно сделать и на лампах и на реле, разве не так? :) И действительно полупроводники гораздо менее надежны.
Насчет подводных лодок :) Там единственная "ЭВМ" - это БИУС (боевая информационная управляющая система) которая считает данные для запуска
Я так понимаю, что слово "ЭВМ" не к месту? Глядя, скажем, на http://www.milparade.ru/docs/upload/036-037_04.pdf действительно слово "ЭВМ" не используется, так что извините. Пусть будет "вычислительная система" - так вроде правильно?
ракет, на основе данных от навигационного комплекса. Так вот - несмотря на ДВУКРАТНОЕ РЕЗЕРВИРОВАНИЕ ПО ПИТАНИЮ :) она бывало не нарабатывала свои 18 часов "холодного старта" - приходилось все заново... И новые комплексы хоть и поправили немного но тоже всего-то двукратного резервирования, т.е. когда одно сломалось - то второе можно ввести вместо него :)
Не-не, дело не в резервировании по питанию, а именно в параллельных цепях, считающих одно и тоже. Мне так рассказывали :) -- Michael Hе пpощают ошибок женщины и тетpис на 9-й скоpости. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Привет ! Thursday, June 22, 2006, 11:26:52 AM, you wrote:
Шоб вы знали - в системах управления реакторами ЭВМ вообще нет - там спец.комплексы вообще на магнитных усилителях и реле - ПОЧЕМУ ? MP> ЭВМ вполне можно сделать и на лампах и на реле, разве не так? :) MP> И действительно полупроводники гораздо менее надежны.
Нет - в понимании общем - "вычислитель" на флоте - это диапазон от схемки узкого профиля на "шестеренках" или магнитных усилителях до цифровой ЭВМ :) Это вам для общей эрудиции. В ректорах никогда не использовалась именно ЭВМ (цифра) - только схемы управления имеющие аналоговый принцип управления - и не на полупроводниках - так гораздо надежнее.
Насчет подводных лодок :) Там единственная "ЭВМ" - это БИУС (боевая информационная управляющая система) которая считает данные для запуска
MP> Я так понимаю, что слово "ЭВМ" не к месту? Глядя, скажем, на MP> http://www.milparade.ru/docs/upload/036-037_04.pdf MP> действительно слово "ЭВМ" не используется, так что извините. MP> Пусть будет "вычислительная система" - так вроде правильно? "Вычислитель" - это понятие от "феликса на шестеренках" до микроЭВМ на ЧИПах - Флот это флот :) а по ссылках - да, речь идет о тренажерах и таки комплексах управления ракет - там вообще сложно говорить о "цифровой ЭВМ" в том толковании как это мы привыкли :) я видел эти комплексы и видел как это собирают на заводе - там понятие "процессор" - это плата или набор плат :) на "рассыпухе", причем "архитектура" весьма интересная :) но заточенная на решение 1-2 задач, так что "писать программы" и прочие голливудские извраты типа "перехвата управления" :) - просто вызывают смех у тех кто в курсе :) Кстати - "сеть тренажеров" - я участвовал в работах в Севастополе по тренажеру на 12 мест - тогда(1988) это было вообще круче вареных яиц - особенно то что в каждом тренажере было по 2 машины на 580 проце :) MP> Не-не, дело не в резервировании по питанию, а именно в MP> параллельных цепях, считающих одно и тоже. Мне так рассказывали :) Может быть :) но вот если ему питание рубануть (бывает в автономке) то ему 18 часов(!) надо чтобы опять выйти на уровень готовности к старту... (данные на 1986-90 годы). -- Best regards, Alexander V Soroka http://www.unet.net.ua AS106-RIPE http://www.spacegate.kiev.ua mailto:alex@euro.net.ua =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
participants (5)
-
Alexander V Soroka -
Hrynchuk Oleh -
Michael Petuschak -
Valentin Nechayev -
vladimir.sharun＠ukr.net