форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[Проследить за развитием треда]

"OpenNews: NASA тестирует систему управления космическим кора..."

Сообщение от opennews (??) on 19-Июн-07, 18:42

Агентство NASA выбрало (http://www.linuxdevices.com/news/NS5714800202.html) Linux как основную ОС для экспериментального проекта "Dependable Multiprocessor" разрабатываемого в рамках миссии "New Millennium Program Space Technology 8 (ST8)". Благодаря проекту будет создано программное окружение, уже знакомое научным работникам, что позволит им без труда портировать научные приложения, которые можно будет использовать для управления оборудованием и проведения расчетов непосредственно на космических аппаратах. URL: http://www.linuxdevices.com/news/NS5714800202.html Новость: http://www.opennet.dev/opennews/art.shtml?num=11133

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Сообщения по теме

[Сортировка по времени, UBB]

1. "NASA тестирует систему управления космическим кораблем на ба..."

Сообщение от _Nick_ (??) on 19-Июн-07, 18:42

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "NASA тестирует систему управления космическим кораблем на ба..."

Сообщение от _Nick_ (??) on 19-Июн-07, 21:31

> p0vlinugz: Ещё один спИцЫалист по космическим жЫвотным... ну так, специалист :) а че ТАМ слишком страшно надеяццо на ребут. Даже с пачкой резервов. Все должно отрабатывать как по нотам, даже если свеже'included модуль - глючноватый...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "NASA тестирует систему управления космическим кораблем на ба..."

Сообщение от www.andr.ru on 19-Июн-07, 22:41

Я - специалист. Занимаются ребята хернёй однозначно. Когда-нибудь эпоху Гейтса-Линукса будут именовать и изучать в школах как эпоху всеобщей компьютерной безграмотности и безалаберности. У этих просто ещё 6 компьютеров не висли намертво на несколько часов, как у русских на МКС. Жареный петух клюнет.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "NASA тестирует систему управления космическим кораблем на ба..."
	Сообщение от _Nick_ (??) on 19-Июн-07, 22:46
	>Я - специалист. Занимаются ребята хернёй однозначно. Когда-нибудь эпоху Гейтса-Линукса будут именовать >и изучать в школах как эпоху всеобщей компьютерной безграмотности и безалаберности. Опа-опа... Типа придет велика бздя на всия МирЪ и укажет великий свет на будуще? Тока все по той же истории она будет на предыдущем от Линуха этапе развития - раз уж они тока щас tmpfs "изобрели" %)) Мож монолитному линуху и не совсем место на обрите пока что - но пробовать то надо когда-нить. И кто как ни NASA - у них то деньжат есть чуток. >У этих просто ещё 6 компьютеров не висли намертво на несколько >часов, как у русских на МКС. Жареный петух клюнет. если этого петуха ремонтировать так же часто и своевременно как на МКСе - то, ессьно будет клевать ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "NASA тестирует систему управления космическим кораблем на ба..."
	Сообщение от Лимуриец on 20-Июн-07, 08:19
	Ты специалист по словесному ананизму.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "NASA тестирует систему управления космическим кораблем на ба..."
	Сообщение от Хелагар on 20-Июн-07, 11:55
	Угу. Специалист. С сайтом, не побоюся этого слова. ufolog.ru по таким "специалистам" плачет. Суда по статье... ГыГ. Ты бы, "специалист" ты этакий врубился, что на МКС произошло, ради интереса, хотябы. а потом говорил. Клоун.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	92. "NASA тестирует систему управления космическим кораблем на ба..."
	Сообщение от R007 on 26-Июн-07, 19:40
	>Я - специалист. По словоблудию? > Занимаются ребята хернёй однозначно. Дядьку, а вы Жириновским не работаете во внеурочное время? :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "не совсем так"

Сообщение от Michael Shigorin on 20-Июн-07, 08:08

NASA тестирует систему управления на базе "обычного" железа и софта, в смысле доступного коммерчески, а не вышитого строго под заказ.  Судя по названию программы, HA предполагается обеспечить резервированием систем. При этом выбор делало не NASA (которое достаточно давно определилось с линуксом), а их контрактор Honeywell, который в линукс для аэрокосмоса залез на моей памяти впервые.  Соответственно те выбрали субподрядчиком Wind River. Заметка для думающих, что специалисты: в Wind River несколько лет тому орали, что линукс сакс (поскольку он выносил с рынка их проприетарную BSD, какая досада).  Кушать продолжать захотели -- решили сменить пластинку и заняться делом, а не истерикой.  Начали с покупки технологии RTLinux у FSMLabs. "Добрым молодцам урок". 2 _Nick_: сделайте одолжение, погуглите "NASA Linux", прежде чем и сюда с микроядрами.  А ещё лучше -- попользуйтесь этими самыми микроядрами да поразрабатывайте под них модули.  Потом вернёмся к надёжности суммы кода.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "не совсем так"
	Сообщение от _Nick_ (??) on 20-Июн-07, 10:26
	>2 _Nick_: сделайте одолжение, погуглите "NASA Linux", прежде чем и сюда с >микроядрами.  А ещё лучше -- попользуйтесь этими самыми микроядрами да я бы с удовольствием - да вот нет в миру такого линуха (остальные ядра не интересны - не GPL), а его создание -  пока для меня неподьемная задача >да поразрабатывайте под них модули.  Потом вернёмся к надёжности суммы кода. ну, писать модули поверх готового API - дело не такое уж и сложное. Другое дело создание этого самого интерфейса... Ну а насчет надежности - неужели сложность создания внутреннего интерфейса негативно скажеться на суммарной надежности? Чисто теоретически. Или ты именно о том, что _практически_ получиться ерунда? ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "не совсем так"
	Сообщение от Michael Shigorin on 20-Июн-07, 14:20
	>>2 _Nick_: сделайте одолжение, погуглите "NASA Linux", прежде чем и сюда с >>микроядрами.  А ещё лучше -- попользуйтесь этими самыми микроядрами >да я бы с удовольствием Погуглили уже? >- да вот нет в миру такого линуха (остальные ядра не интересны - не GPL), Да полно GPL'ных ядер.  Вон недавно ещё что-то проскакивало по freshmeat. >>да поразрабатывайте под них модули.  Потом вернёмся к надёжности суммы кода. >ну, писать модули поверх готового API - дело не такое уж и >сложное. Другое дело создание этого самого интерфейса... Всё-таки почитайте документацию того же Minix или спросите профессора, как модуль-то написать.  Hint: есть ещё такая штука как проблема взаимодействия N объектов.  Сама их функциональность может делаться просто, но сложность взаимодействия слишком быстро растёт. >Чисто теоретически. Я собсно намекал на то, что Ваши теоретические изыски стоят ещё меньше, чем мои теоретические изыски (которые хотя бы задевают документацию и анализы всякие) -- а мои и так почти ничего не стоят.  Смысл фантазировать вслух и особенно делать уверенный вид при этом?  Молодёжь на такое может купиться, будет потом бегать пару лет с пузырями про микроядра, пока не отойдёт. >Или ты именно о том, что _практически_ получиться ерунда? ;) Я о том, что практически почти у всех именно она и получается.  Хорошие реализации весьма специфичны (наложенные ограничения вроде i386 only и узкой нишевости позволяют сфокусироваться на вылизывании).  Для общей же, судя по NT3.51 и Minix, это не работает.  Макось разве, но она тоже относительно нишевая.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "не совсем так"
	Сообщение от _Nick_ (??) on 20-Июн-07, 15:00
	>Погуглили уже? это мое перманентное состояние :) >>- да вот нет в миру такого линуха (остальные ядра не интересны - не GPL), >Да полно GPL'ных ядер.  Вон недавно ещё что-то проскакивало по freshmeat. Хоть один линк в студию, плз! (Просьба не путать например микроядро L4 с микроядерным Линухом). Сложность случая пингвинов - именно в том, что портирование всего его функционала на какое-либо микроядро - самая большая проблема. >Всё-таки почитайте документацию того же Minix или спросите профессора, как модуль-то написать. > Hint: есть ещё такая штука как проблема взаимодействия N объектов. > Сама их функциональность может делаться просто, но сложность взаимодействия слишком >быстро растёт. Мои же слова сказанные по-другому: сложно создать API для этого самого взаимодействия. И документацию миникса я читал. Все так же готов утверждать: написание модуля для готового микроядра - задача в разы проще, чем создание этого самого ядра. >Я собсно намекал на то, что Ваши теоретические изыски стоят ещё меньше, >чем мои теоретические изыски (которые хотя бы задевают документацию и анализы >всякие) -- а мои и так почти ничего не стоят.   >Смысл фантазировать вслух и особенно делать уверенный вид при этом? >Молодёжь на такое может купиться, будет потом бегать пару лет с >пузырями про микроядра, пока не отойдёт. Мои пузыри были именно о том, что микроядро (именно ядро с защитой каждого модуля путем помещения в свое адресное пространство - т.е. в отдельный процесс) предоставляет большую надежность в сравнении с монолитом. О сложности его создания начали вы и пытаетесь смешать мои высказывания с гразью... Хотя, я и не отрицал бОльшую сложность разработки микроядра. >>Или ты именно о том, что _практически_ получиться ерунда? ;) >Я о том, что практически почти у всех именно она и получается. Это еще не говорит о том, что сама идея гумно. >Хорошие реализации весьма специфичны (наложенные ограничения вроде i386 only и >узкой нишевости позволяют сфокусироваться на вылизывании).  Для общей же, судя >по NT3.51 в этом чуде не было защиты адресным пространством (загрузки модулей в разные процессы) >и Minix, это не работает.  Макось разве, но >она тоже относительно нишевая.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	22. "не совсем так"
	Сообщение от Michael Shigorin on 20-Июн-07, 15:34
	>>>- да вот нет в миру такого линуха (остальные ядра не интересны - не GPL), >>Да полно GPL'ных ядер. >Хоть один линк в студию, плз! Из того, на что может иметь смысл ссылаться -- http://atheos.syllable-norden.info/ (вчера, что ли, рядом упоминал). >О сложности его создания начали вы Понимаете, сложность создания выливается в стоимость*надёжность.  А сложность создания взаимодействующей внутри себя системы легко недооценить. >и пытаетесь смешать мои высказывания с гразью... М-да, наверное, действительно на это похоже.  Извините.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	23. "не совсем так"
	Сообщение от _Nick_ (??) on 20-Июн-07, 15:57
	>Из того, на что может иметь смысл ссылаться -- http://atheos.syllable-norden.info не нашел и слова об адресной защите или микроядерности. Плохо читал список фич?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	27. "не микроядерное"
	Сообщение от Michael Shigorin on 20-Июн-07, 16:54
	>>[AtheOS] >не нашел и слова об адресной защите или микроядерности. >Плохо читал список фич? Вы вроде интересовались живыми GPL'ными ядрами, а не микро-.  Я и ответил.  И того, и другого сходу не припомню (ну не Hurd же).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	28. "не микроядерное"
	Сообщение от _Nick_ (??) on 20-Июн-07, 17:13
	>Вы вроде интересовались живыми GPL'ными ядрами, а не микро-.  Я и >ответил.  И того, и другого сходу не припомню (ну не >Hurd же). пока есть Линух - просто GPLные другие ядра не представляют интереса. Интересны именно GPL микроядра.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	33. "QNX"
	Сообщение от gmm20 (??) on 20-Июн-07, 21:22
	> Всё-таки почитайте документацию того же Minix или спросите профессора, > как модуль-то написать. Hint: есть ещё такая штука как проблема > взаимодействия N объектов. Сама их функциональность может делаться > просто, но сложность взаимодействия слишком быстро растёт. сложность растет, но надежность получаемого в результате решения растет еще быстрее. и это единственная причина, почему используют более сложное и дорогое в создании/обслуживании решение, чем Linux. тот же самый Linux - также намного сложнее, чем например, MS-DOS 3.3 но ни ты, ни кто-либо другой из современных пользователей Linux`а почему-то не горят желанием все бросить и вернуться обратно в DOS. то расстояние, которое разделяет Linux 2.6 и MS-DOS 3.3 ты можешь себе представить. вот примерно такая же разница между Linux и QNX. и по сложности создания OS и по надежности работы приложений... > Смысл фантазировать вслух и особенно делать уверенный вид при этом?   > Молодёжь на такое может купиться, будет потом бегать пару лет > с пузырями про микроядра, пока не отойдёт. QNX используют только там где действительно нужна высокая надежность. Linux - это операционная система, которую можно использовать бесплатно. это разные системы, разные цели, разные архитектуры. что тут сравнивать? > Для общей же, судя по NT3.51 и Minix, это не работает.   для desktop`а - это не работало в 1985, 1995 и 2005 году. но кто точно знает, что именно будет в 2015-м, 2025 и 2035-м? посмотри какие были hardware и ОС 20-30 лет тому назад, на основании этого примерно можно представить что будет через 20-30 лет в будущем.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	37. "DOS"
	Сообщение от Michael Shigorin on 20-Июн-07, 22:47
	>> сложность взаимодействия слишком быстро растёт. >сложность растет, но надежность получаемого в результате решения >растет еще быстрее. Надёжность не растёт со сложностью. >тот же самый Linux - также намного сложнее, чем например, MS-DOS 3.3 И много где DOS до сих пор и используется. >QNX используют только там где действительно нужна высокая надежность. >Linux - это операционная система, которую можно использовать бесплатно. >это разные системы, разные цели, разные архитектуры. что тут сравнивать? Именно это и хотел сказать. >посмотри какие были hardware и ОС 20-30 лет тому назад, на основании >этого примерно можно представить что будет через 20-30 лет в будущем. Мне -- не получается, как и 20-30 лет тому вряд ли можно было представить суперкомпьютер под кухаркиным столом. :) [косясь на свой аж одноядерный 3700+ с целым гигом]
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	39. "QNX"
	Сообщение от gmm20 (??) on 20-Июн-07, 23:41
	>>> сложность взаимодействия слишком быстро растёт. >> сложность растет, но надежность получаемого в результате решения растет еще быстрее. > Надёжность не растёт со сложностью. разве QNX (микроядро)- это менее надежная операционная система, чем Linux (монолитное ядро)? Cisco IOS XR (микроядро) - это менее надежная операционная система, чем Cisco IOS (монолитное ядро)? сложность растет при переходе с монолитного ядра на микроядро. но "надежность" получаемого решения при этом растет еще больше. >> тот же самый Linux - также намного сложнее, чем например, MS-DOS 3.3 > И много где DOS до сих пор и используется. используется, но только не по той причине, что MS-DOS 3.3 - это более качественное или более надежное решение, чем [RT]Linux. а только лишь потому что более дешевое. аналогично и NASA сейчас испытывает дефицит финансирования (ведь все деньги америки ушли на военные расходы, в том числе и на "антитеррористические" операции в Ираке/Афганистане) не так давно проскакивала новость, что большое количество телескопов NASA находится в аварийном состоянии, и требуют срочного ремонта. но денег на это нет. >> QNX используют только там где действительно нужна высокая надежность. >> Linux - это операционная система, которую можно использовать бесплатно. >> это разные системы, разные цели, разные архитектуры. что тут сравнивать? > Именно это и хотел сказать. а мне показалось(?), что ты обсуждал недостатки микроядерного подхода построения ОС... >> посмотри какие были hardware и ОС 20-30 лет тому назад, на основании >> этого примерно можно представить что будет через 20-30 лет в будущем. > Мне -- не получается, как и 20-30 лет тому вряд ли можно > было представить суперкомпьютер под кухаркиным столом. :) > [косясь на свой аж одноядерный 3700+ с целым гигом] я сейчас обычно использую две-три операционки одновременно на своем компе, это WinNT 5.2 + CentOS 4.x + FreeDOS 1.x: host OS + inside VMware Server. и железо самое обычное - 2GB RAM, CPU P4 3.2 GHz. в 1995 году я о таком workplace и мечтать даже не мог. а ведь прошло всего 10 лет с тех пор... в 1985 году только появился 386 процессор с аппаратной защитой памяти, это был огромный шаг вперед по сравнению с 286 процессором. "leap ahead". сейчас - уже полным ходом идет переход на 64-разрядные процессоры, внедряются технологии аппаратной виртуализации и паравиртуализации. за 10-15 лет переход от 16-разрядных до 64-разрядных процессоров - такие темпы развития hardware - впечетляют. я уж не говорю о том, как выросли быстродействие CPU, (а также объемы) RAM и HDD.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	40. "mono vs? micro"
	Сообщение от Michael Shigorin on 20-Июн-07, 23:55
	>>>> сложность взаимодействия слишком быстро растёт. >>> сложность растет, но надежность получаемого в результате решения растет еще быстрее. >> Надёжность не растёт со сложностью. >разве QNX (микроядро)- это менее надежная >операционная система, чем Linux (монолитное ядро)? >Cisco IOS XR (микроядро) - это менее надежная >операционная система, чем Cisco IOS (монолитное ядро)? У меня не было возможности сравнивать QNX с Linux по надёжности и IOS XR -- вообще.  Оценки SLOC собственно ядра (+/- основные серверы), не считая драйверов -- по ним у меня тоже нет.  Поэтому остаётся близкое к голословному утверждение, что эти специализированные ОС жертвуют пригодностью для гораздо большего ареала, на котором водится линукс, для большей надёжности в своей нише. Что и говорил, опять же. >сложность растет при переходе с монолитного ядра на микроядро. >но "надежность" получаемого решения при этом растет еще больше. У Вас есть на чём сравнивать, бишь микроядерные и монолитные (тем более модульно-ктредовые) ядра сопоставимой функциональности и трудоёмкости?  У меня -- нет. >используется, но только не по той причине, что MS-DOS 3.3 - это более качественное >или более надежное решение, чем [RT]Linux. а только лишь потому что более >дешевое. Помните такое слово -- good enough? >>> это разные системы, разные цели, разные архитектуры. что тут сравнивать? >> Именно это и хотел сказать. >а мне показалось(?), что ты обсуждал недостатки микроядерного подхода построения ОС... Я скорее пытался подсказать недостатки некорректного сравнения камаза со свадебным фаэтоном.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	43. "DOS"
	Сообщение от _Nick_ (??) on 21-Июн-07, 09:50
	>>QNX используют только там где действительно нужна высокая надежность. >>Linux - это операционная система, которую можно использовать бесплатно. >>это разные системы, разные цели, разные архитектуры. что тут сравнивать? Linux последнее время имеет все шансы заменить QNX в некоторых отраслях (встраиваемые устройства - как минимум). Причем по 2 параметрам, где QNX не сможет уже обойти Линух пока сам не измениться: открытость исходников и бесплатность (как пива). >>посмотри какие были hardware и ОС 20-30 лет тому назад, на основании >>этого примерно можно представить что будет через 20-30 лет в будущем. >Мне -- не получается, как и 20-30 лет тому вряд ли можно >было представить суперкомпьютер под кухаркиным столом. :) да, просто так представить невозможно куда заведет прогресс через 20-30 лет... >[косясь на свой аж одноядерный 3700+ с целым гигом] у мсье кухарский стол по долгу службы? ;) (шутко)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	93. "DOS"
	Сообщение от R007 on 26-Июн-07, 19:58
	О надежности.Надежен код.А микроядро там или нет - вопрос 10-й.Микроядро лучше в плане failure recovery.Однако в космосе не должно быть ошибок.Радости то если в ответственный момент бахнется драйвер периферии?При этом может быть до 3.14... - упала вся система или нет.Дальнейшее поведение железки которой рулили не особо достоверно.Поэтому вещей типа упавшего драйвера быть просто не должно.Ни с микроядром ни без.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	94. "DOS"
	Сообщение от _Nick_ (??) on 26-Июн-07, 20:54
	>О надежности.Надежен код.А микроядро там или нет - вопрос 10-й.Микроядро лучше в >плане failure recovery.Однако в космосе не должно быть ошибок.Радости то если >в ответственный момент бахнется драйвер периферии?При этом может быть до 3.14... >- упала вся система или нет.Дальнейшее поведение железки которой рулили не >особо достоверно.Поэтому вещей типа упавшего драйвера быть просто не должно.Ни с >микроядром ни без. несколько неверное мнение по поводу failures. Они _могут_ быть, хоть ты крабом стань. Но т.к. отловить их полностью крайне сложно - то тут уже идет счет на процент вероятности возникновения ошибок и риски связанные с этим. И вот для микроядра такая вероятность критической (невосстановимой) ошибки радикально меньше. Про драйвер периферии. Даже если он упал и корабль выжил (допустим, это был драйвер управления солнечной батареей всего-лишь) то перезагрузка этого драйвера продолжит работу всего корабля (драйверов, отвечающих за остальные узлы) в _определенном_ состоянии, без опасений, что во время падения драйвера солнца не был переписан какой-либо участок памяти другого модуля. Т.е. о дальнейшей работоспособности корабля _можно_ говорить. Ну и, ессьно, образ упавшего можуля уже через пару секунд после этого события находиться на Земле, в дебаггерах пачки девелоперов, с тем чтобы быть пофикшенным и залитым опять на корабль. Вот такая маленькая фантастика :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "не совсем так"
	Сообщение от belkin on 20-Июн-07, 11:01
	Мнение программиста RTS: "Когда меня подряжают на контроллеры с Linux меня ничинает мутить: опираться в отладке на это скользкое как желе падучее Linux kernel нет никакой возможности, убогие средства отладки. Другое дело QNX: непоколебимая стойкость ко всему, хорошие инструменты для отладки."
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "не совсем так"
	Сообщение от _Nick_ (??) on 20-Июн-07, 11:17
	>Мнение программиста RTS: >"Когда меня подряжают на контроллеры с Linux меня ничинает мутить: опираться в >отладке на это скользкое как желе падучее Linux kernel нет никакой >возможности, убогие средства отладки. Ну, это перегиб конечно. И "желе падучее" и "убогие средства отладки". >Другое дело QNX: непоколебимая стойкость ко всему, ну ессьно, если ваш кривой драйвер живет в отдельном процессе - ессьно будет стойкость :) >хорошие инструменты для отладки." про это не знаю ничего, увы. Но даже со всем этим у QNXа есть весьма заметный минус по сравнению с линухом - он не под GPL. Отсюда ограничения при внедрении (деньги/лицензии) и заточка под свои задачи (нет исходников с правом изменения). Мир неидеален....
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "не совсем так"
	Сообщение от Хелагар on 20-Июн-07, 11:58
	>Мнение программиста RTS: >"Когда меня подряжают на контроллеры с Linux меня ничинает мутить: опираться в >отладке на это скользкое как желе падучее Linux kernel нет никакой >возможности, убогие средства отладки. Другое дело QNX: непоколебимая стойкость ко всему, >хорошие инструменты для отладки." Мнение прогамиста RTS опять-таки. Живу под RTLinux и в ус не дую. С отладкой всё вполне хорошо. Ничего не глючит и не падает. Скажите, пожалуйсто, что я не так делаю? Под QNX тоже писал, бывало. Тоже не глючит.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "не совсем так"
	Сообщение от belkin on 20-Июн-07, 13:08
	Этот RTLinux какой-то сильно другой что ошибки в модулях не приводят к падению ядра ?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "не совсем так"
	Сообщение от _Nick_ (??) on 20-Июн-07, 13:22
	>Этот RTLinux какой-то сильно другой что ошибки в модулях не приводят к >падению ядра ? думаю, деление на ноль в коде любого ядра принесет массу удовольствия ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "не совсем так"
	Сообщение от belkin on 20-Июн-07, 13:34
	Вероятность ошибки в ядре размером 65KB очень мала. При малом размере алгоритм и код можно тщательно написать и тщательно протестировать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "не совсем так"
	Сообщение от _Nick_ (??) on 20-Июн-07, 13:40
	>Вероятность ошибки в ядре размером 65KB очень мала. При малом размере алгоритм >и код можно тщательно написать и тщательно протестировать. это уже сравнение микроядра и монолита. Их плюсы/минусы всем уже известны. Но вот фича в том, что даже при такой большой теоретической разнице в стабильности QNX и Линуха - последний работает достаточно надежно, и сравнимо с QNXом.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	17. "совсем не так"
	Сообщение от Michael Shigorin on 20-Июн-07, 13:52
	>Этот RTLinux какой-то сильно другой что ошибки в модулях не приводят к >падению ядра ? Этот RTLinux какой-то сильно другой, что делает hard realtime.  Если Вам очень интересно, как именно -- почитайте описание, может, окажется интересней, чем на первый взгляд (как для убеждённого сторонника мелкоядер). Вообще же сравнивать тёплое с мягким не работает.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "совсем не так"
	Сообщение от belkin on 20-Июн-07, 14:37
	До того как какие-то обезьяны (MS?) попытались продвинуть свою обычную ОС в автомобильную промышленность (управление двигателем и системами автомобиля) классифицировав её как "Soft RTS", никому не нужно было добавлять "Hard". RTS либо Real Time, либо фуфло с этикеткой, а добавка "Hard" появилась по недоразумению. Нужны было добавлять не "Hard", а "True". Так каким образом наличие поддержки True RT процессов убрало зависимость целостности ядра от драйверов ? Никаким. Когда количество процессорных ядер в настольных компьютерах перевалит число 10 и монолитные ядра станут захлёбываться от попыток синронизировать большое количество одновременно выполняемых потоков в рамках одного процесса в критических секциях без катастрофического падения коэффициента использования процессора, может быть вы наконец-то поймёте, что у нас нет друго пути кроме национал-социализма. Сегодняшнее поколение для нас потеряно. Оно не простит нам голода и бомбардировок. А вот молодые, те, которым сейчас 5-6 лет это прейдётся по душе. И вот тогда-то и понадобится концепция микроядра. Достаточно будет вскинуть руку, крикнуть "Хайль" и к вам потянутся страждущие порядка и мощи.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "совсем не так"
	Сообщение от _Nick_ (??) on 20-Июн-07, 15:06
	>Когда количество процессорных ядер в настольных компьютерах перевалит число 10 и монолитные >ядра станут захлёбываться от попыток синронизировать большое количество одновременно выполняемых потоков >в рамках одного процесса в критических секциях без катастрофического падения коэффициента >использования процессора, может быть вы наконец-то поймёте, Читай новости. Линух (есьно монолит, другого пока нет) уже давно успешно шедулит тисячи процов. В разных они корпусах или на одном кристалле - не особо влияет на логику работы (хотя для обоих случаев есть свои методы оптимизаций). Так что, линух УЖЕ готов бегать твои 10 ядер на настольном компе и не только. >что у нас нет >друго пути кроме национал-социализма. Сегодняшнее поколение для нас потеряно. Оно не >простит нам голода и бомбардировок. А вот молодые, те, которым сейчас >5-6 лет это прейдётся по душе. И вот тогда-то и понадобится >концепция микроядра. Достаточно будет вскинуть руку, крикнуть "Хайль" и к вам >потянутся страждущие порядка и мощи. хороша у тя трава :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	24. "совсем не так"
	Сообщение от belkin on 20-Июн-07, 16:21
	Никакого понимания. >Читай новости. Линух (есьно монолит, другого пока нет) уже давно успешно шедулит >тисячи процов. В разных они корпусах или на одном кристалле - Тысячи процов ? В тысячах компьютеров - по одному процессору на коробку ? >не особо влияет на логику работы >(хотя для обоих случаев есть свои методы оптимизаций). >Так что, линух УЖЕ готов бегать твои 10 ядер на настольном компе >и не только. Планировать не означает эффективно использовать. Системщики смотрели код ядра, а потом другая группа подтвердила это на стенде с 16-ью процессорами: потоки стоят и нервно куря ждут своей очереди чтобы пролезть в замочную скважину. Это всем известная проблема SMP, но с монолитными ядрами она выпячивается больше.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	25. "совсем не так"
	Сообщение от _Nick_ (??) on 20-Июн-07, 16:45
	>Никакого понимания. да тут гении на опеннете пропадают... :) >Планировать не означает эффективно использовать. Ты из какого зоопарка сбежал? :) Эффективность использования процов в SPM системе лишь отчасти на плечах ядра. И его задача - именно сказать кто и наком проце в каждый момент должен работать. И Лимнух это делает чудно. А вот уже создание алгоритма например для распредленных вычислений чтобы минимизировать простои в ожидании шины - это талант архитектора программулины, которую будет бегать ядро. Ну, а если же есть примеры _более_ эффективаного использования SMP системы ядром, чем у Линуха - то в студию их, плз :) Можно на примерах этих же N-ядерных кластеров, где живут почти лишь только пингвины ;) >Системщики смотрели код ядра, а потом другая группа подтвердила это на стенде >с 16-ью процессорами: потоки стоят и нервно куря ждут своей очереди >чтобы пролезть в замочную скважину. Это всем известная проблема SMP, но >с монолитными ядрами она выпячивается больше. А вот с этого места поподробнее, плз ;) Каким же это образом принцип размещения кода модулей (в адрессном пространстве ядра или в одтельном для каждого модуля) так вот резко и главное однозначно(!!) влияет на SMP способности ядра? :) (Это если даже забыть, что на эффективность влияет и сам пользовательский процесс не меньше ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	29. "совсем не так"
	Сообщение от belkin on 20-Июн-07, 17:20
	Мы из разных миров. Я из тех, для кого SM в абревиатуре SMP означает Shared Memory а не Symmetrical Multi. >Эффективность использования процов в SPM системе лишь отчасти >на плечах ядра. И его задача - именно сказать кто и наком >проце в каждый момент должен работать. И Лимнух это делает чудно. Проблема SMP - одновременный доступ процессоров по одному адресу. Когда на процесоры планируется выполнение кода из разных процессов это не страшно так как у каждого процесса свой участок памяти. А когда нити на процессорах проходят через один процесс, то... Если не понятно, читайте о механизмах синхронизации процессов. >А вот уже создание алгоритма например для распредленных вычислений чтобы >минимизировать простои в ожидании шины - это талант архитектора программулины, >которую будет бегать ядро. Кластеры и распределённые вычисления это из вашего мира. >Ну, а если же есть примеры _более_ эффективаного использования SMP системы ядром, > >чем у Линуха - то в студию их, плз :) Имейте систему из многих малозависимых друг от друга процессов и проблемы блокировок и конфликтов исчезнут. >Можно на примерах этих же N-ядерных кластеров, где живут почти лишь только >пингвины ;) Кластеры и распределённые вычисления вам показались. Меня учили, что распределённые вычисления это когда есть сеть вычислительных машин. Я говорю про одну ВМ с одной ОС. >>Системщики смотрели код ядра, а потом другая группа подтвердила это на стенде >>с 16-ью процессорами: потоки стоят и нервно куря ждут своей очереди >>чтобы пролезть в замочную скважину. Это всем известная проблема SMP, но >>с монолитными ядрами она выпячивается больше. >А вот с этого места поподробнее, плз ;) >Каким же это образом принцип размещения кода модулей (в адрессном пространстве ядра >или в одтельном для каждого модуля) так вот резко и главное >однозначно(!!) влияет на >SMP способности ядра? :) (Это если даже забыть, что на эффективность влияет >и сам пользовательский процесс не меньше ;) "SMP способности ядра". Да, можно так сказать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	31. "совсем не так"
	Сообщение от _Nick_ (??) on 20-Июн-07, 18:28
	>Проблема SMP - одновременный доступ процессоров по одному адресу. Когда на процесоры >планируется выполнение кода из разных процессов это не страшно так как >у каждого процесса свой участок памяти. А когда нити на процессорах >проходят через один процесс, то... >Если не понятно, читайте о механизмах синхронизации процессов. Не нужно считать себя умнее других. Проблемы SMP систем не государственный секрет. И другие тоже умеют читать, а может и сделали это уже и давно. >Имейте систему из многих малозависимых друг от друга процессов и проблемы блокировок >и конфликтов исчезнут. блин... так а при чем тут ЯДРО?? Судя по вашим словам его проблемы решаються правильным выбором юзер-левел процессов %)))) >Кластеры и распределённые вычисления вам показались. Меня учили, что распределённые вычисления это >когда есть сеть вычислительных машин. а меня учили, что Земля - треугольная. Есть определение таких вычислений и в нем нет и слова и железной платформе. Множестом исполнителей может быть как набор нодов кластера, так и ядра SMP системы. >Я говорю про одну ВМ с одной ОС. Как видишь - неважно. Принципы те же. >"SMP способности ядра". >Да, можно так сказать. что "да"? :) Вопрос был: как принцип защиты памяти модулей может влиять на эффективность работы SMP системы? :) Тем более, что мы выяснили, что эффективность все-таки зависит львиной частью от архитектуры пользовательских процессов.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	46. "совсем не так"
	Сообщение от belkin on 21-Июн-07, 11:58
	>>Имейте систему из многих малозависимых друг от друга процессов и проблемы блокировок >>и конфликтов исчезнут. >блин... >так а при чем тут ЯДРО?? >Судя по вашим словам его проблемы решаються правильным выбором юзер-левел процессов %)))) Эх, ма. О ядерных процессах речь. Ладно, разжовываю: "сделайте ядро ОС не одним большим куском, а состоящее из небольших, но функционально законченных процессов, способных безопасно параллельно выполнятся на процессорах в системах SMP и проблемы блокировок и конфликтов будут более редкими". >>Кластеры и распределённые вычисления вам показались. Меня учили, что распределённые вычисления это >Множестом исполнителей может быть как набор нодов кластера, так и ядра SMP >системы. SMP - архитектура вычислительной системы, а распределённые вычисления подразумевают сеть из слабосвязанных вычислительных машин или мы с тобой по разным учебникам учились. Параллельные вычисления не обязательно распределённые.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	48. "RTFS! :-/"
	Сообщение от Michael Shigorin on 21-Июн-07, 12:10
	>Эх, ма. О ядерных процессах речь. Ладно, разжовываю: "сделайте ядро ОС не >одним большим куском, а состоящее из небольших, но функционально законченных процессов, >способных безопасно параллельно выполнятся на процессорах в системах SMP и проблемы >блокировок и конфликтов будут более редкими". Уважаемый Белкин, будьте добры перед дальнейшими глубокомысленными теоретизированиями ознакомиться-таки с предметом оных. Если Вы до сих пор полагаете, что линуксовое ядро исполняется одним процессом на одном процессоре, будьте добры, вылазьте из десятилетней как минимум давности.  Вот древнее 2.4 на 4-way за вычетом несущественного userspace в основной системе vserver: init-+-bdflush [...]      |-keventd      |-kinoded      |-kjournald      |-klogd      |-ksoftirqd_CPU0      |-ksoftirqd_CPU1      |-ksoftirqd_CPU2      |-ksoftirqd_CPU3      |-kswapd      |-kupdated      |-mdrecoveryd [...]      |-xfsbufd      |-xfsdatad/0      |-xfsdatad/1      |-xfsdatad/2      |-xfsdatad/3      |-xfslogd/0      |-xfslogd/1      |-xfslogd/2      |-xfslogd/3      `-4*[xfssyncd] Калькулятор спонсировать или сами с подсчётами справитесь?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	53. "RTFS! :-/"
	Сообщение от belkin on 21-Июн-07, 12:43
	>>Эх, ма. О ядерных процессах речь. Ладно, разжовываю: "сделайте ядро ОС не >>одним большим куском, а состоящее из небольших, но функционально законченных процессов, >>способных безопасно параллельно выполнятся на процессорах в системах SMP и проблемы >>блокировок и конфликтов будут более редкими". >Уважаемый Белкин, будьте добры перед дальнейшими глубокомысленными теоретизированиями ознакомиться-таки с предметом оных. > > >Если Вы до сих пор полагаете, что линуксовое ядро исполняется одним процессом >на одном процессоре, будьте добры, вылазьте из десятилетней как минимум давности. > Вот древнее 2.4 на 4-way за вычетом несущественного userspace в >основной системе vserver: > >init-+-bdflush >[...] >     |-keventd >     |-kinoded >     |-kjournald >     |-klogd >     |-ksoftirqd_CPU0 >     |-ksoftirqd_CPU1 >     |-ksoftirqd_CPU2 >     |-ksoftirqd_CPU3 >     |-kswapd >     |-kupdated >     |-mdrecoveryd >[...] >     |-xfsbufd >     |-xfsdatad/0 >     |-xfsdatad/1 >     |-xfsdatad/2 >     |-xfsdatad/3 >     |-xfslogd/0 >     |-xfslogd/1 >     |-xfslogd/2 >     |-xfslogd/3 >     `-4*[xfssyncd] > >Калькулятор спонсировать или сами с подсчётами справитесь? Эх, ма. Смотрите первое сообщение. Критические секции ! Там где запрещён параллельный доступ к внутренним структурам ядра.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	54. "RTFS! :-/"
	Сообщение от Michael Shigorin on 21-Июн-07, 12:57
	>Эх, ма. Смотрите первое сообщение. Смотрел.  Тут Вы вообще про процессы говорили. >Критические секции ! Там где запрещён параллельный >доступ к внутренним структурам ядра. Рекомендую: google://"big kernel lock"+linux google://"giant kernel lock"+freebsd по вкусу +history
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	60. "RTFS! :-/"
	Сообщение от belkin on 21-Июн-07, 15:51
	Отлично ! А я боялся, что так останусь для вас болтуном-идиотом. И теперь переносимся в ОС с микроядром, где количество и размер таких критических секций очень мало так как взаимодействие между частями ОС выполняются на более высоком уровне и есть другие, более подходящие для параллельного выполнения механизмы IPC.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	61. "RTFS! :-/"
	Сообщение от _Nick_ (??) on 21-Июн-07, 17:24
	>Отлично ! А я боялся, что так останусь для вас болтуном-идиотом. И >теперь переносимся в ОС с микроядром, где количество и размер таких >критических секций очень мало так как взаимодействие между частями ОС выполняются >на более высоком уровне и есть другие, более подходящие для параллельного >выполнения механизмы IPC. ты будешь удивлен, но эти "другие, более подходящие для параллельного выполнения механизмы IPC" будут требовать НЕ МЕНЬШЕ локов для обеспечения ТОГО же уровня функционала/гибкости/скорости_реакции_системы/производительности :) чисто по логике ;) ну а если логика страдает и ты веришь в эти светлые и непорочные "механизмы IPC" (которыми, кстати, являюццо очередя сообдещий), то смотри. Если будет одна очередь сообщений не-взирая сколько процов в системе - то будет затык ввиду того, что все 3 проца _могут_ быть в состоянии ожидания пока один работает с очередью (добавляет/удаляет/читает сообщение). Локов мало, но потеряна скорость реакции. Чтоб поправить ситуацию - делаем, например, 2 очереди сообщений: одна общая, допустим, а другая, допустим, для сетевых операций. И тут уже развязка будет получше: посылка пакета и системный вызов fork() уже могут друг другу не мешать. Но все равно, до оригинальных параметров системы далеко. И мы создаем еще и еще очередя...  А на каждую нужен свой лок... В результате - будет просто микроядро :), но с тем же количеством локов (или большим даже, ввиду заведомо большего числа процессов в системе). Так что... как бы твоя гипотеза не доказывала бы обратное ;) Что в микроядре БОЛЬШЕ локов, чем в монолите. (или мы теряем один/больше параметров ядра)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	64. "RTFS! :-/"
	Сообщение от belkin on 22-Июн-07, 10:25
	>Если будет одна очередь сообщений не-взирая сколько процов в системе - то >будет затык >ввиду того, что все 3 проца _могут_ быть в состоянии ожидания пока >один работает с очередью (добавляет/удаляет/читает сообщение). Локов мало, но потеряна скорость >реакции. :-) Я знал что вы мне это скажите. Всё это верно, но с небольшой добавочкой... Механизм сообщений обслуживает ядро, а так как оно является самостоятельным процессом и очень маленьким, то оно может просто сидеть (если его жёстко привязать к конкретному процессору) на одном из процессоров и не выгружаясь и не приостанавливаясь на блокировки, быстро выполнять свою работу. Это возможно из-за того, что никто не лезет внутрь ядра боковыми путями, а взаимодействуют через внешний интерфейс. Более того. Это только то, что есть сейчас, а концепция микроядерных ОС позволяет иметь более одного обработчика сообщений или даже более одного ядра в системе, хотя я это ещё нигде не видел и не продумывал сам.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	66. "RTFS! :-/"
	Сообщение от _Nick_ (??) on 22-Июн-07, 14:23
	>:-) Я знал что вы мне это скажите. Всё это верно, но >с небольшой добавочкой... Механизм сообщений обслуживает ядро, а так как оно >является самостоятельным процессом и очень маленьким, то оно может просто сидеть >(если его жёстко привязать к конкретному процессору) на одном из процессоров >и не выгружаясь и не приостанавливаясь на блокировки, быстро выполнять свою >работу. Это возможно из-за того, что никто не лезет внутрь ядра >боковыми путями, а взаимодействуют через внешний интерфейс. Более того. Это только >то, что есть сейчас, а концепция микроядерных ОС позволяет иметь более >одного обработчика сообщений или даже более одного ядра в системе, хотя >я это ещё нигде не видел и не продумывал сам. ну шо тебе сказать :) Хороший ты человек, Белкин, и даже в микроядро веришь (как и я ;) Но вот то как ты описал работу обработчика очереди сообщений - так не бывает :) Он не может быть "маленьким" :) Он будет таким как нужно, и должен уметь хранить очень много сообщений в очереди (на всякий случай каких-то затыков в других модулях) Его _нельзя_ привязывать к одному/двум/не_всем процессорам - будет потеря скорости реакции :) Ну вот если есть простаивающий проц и нужно какому-то модулю поставить сообщение в очередь и никто больше в данный момент подобного делать не хочет (не лочит очередь) - ну неужели ты бы этого не сделал на свободном проце? :) Лезть "внутрь ядра" конечно же никто не будет и трогать эту очередь "своими грязными модульными руками" - ессьно все будет через интерфейс системных вызовов к этому самому обработчику очереди. Но все равно, хоть ты трижды герой компартии - любая постановка в очередь - это лок этой очереди на небольшое время. Ну и отсюда - все шо я написал ранее. Ну а про "много ядер в системе" - это уже виртуализация. Это тоже может быть, но я тоже пока о таком не слышал :) (тут бы нормальное микроядро с адресной защитой увидеть в жизни, не то что виртуалить его)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	68. "lockless"
	Сообщение от gmm20 (??) on 22-Июн-07, 15:57
	> любая постановка в очередь - это лок этой очереди на небольшое время. lockless queues - это отсутствие блокировок при работе с очередями.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	67. "QNX"
	Сообщение от gmm20 (??) on 22-Июн-07, 14:40
	>> Если будет одна очередь сообщений не-взирая сколько процов в системе - >> то будет затык ввиду того, что все 3 проца _могут_ быть в состоянии ожидания пока >> один работает с очередью (добавляет/удаляет/читает сообщение). >> Локов мало, но потеряна скорость реакции. > :-) Я знал что вы мне это скажите. Всё это верно, но с небольшой добавочкой... вышеприведенное утверждение очень далеко от действительности. посмотри например, на патент CA 2536037, An asynchronous message passing mechanism that allows for multiple messages to be batched for delivery between processes, while allowing for full memory protection during data. transfers and a lockless mechanism for speeding up queue operation and queuing and delivering messages simultaneously. http://patents1.ic.gc.ca/details?patent_number=2536037 я почему-то совсем не удивляюсь, что владельцем этого патента является QNX SOFTWARE SYSTEMS. PS какие там могут быть состояния ожидания и взаимные блокировки??? QNX - это RTOS. PPS ключевые слова "lockless" и "real time" - если твои собеседники не понимают смысла этих терминов, что-либо доказывать им - это будет практически пустая трата времени и сил.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	69. "QNX"
	Сообщение от _Nick_ (??) on 22-Июн-07, 17:27
	>An asynchronous message passing mechanism that allows for multiple messages to be >batched for delivery between processes, while allowing for full memory protection >during data. transfers and a lockless mechanism for speeding up queue >operation and queuing and delivering messages simultaneously. > >http://patents1.ic.gc.ca/details?patent_number=2536037 Ок, я описывал не оптимальный метод взаимодействия. Но описанный метод передачи сообщений используеться и в RTLinux'е. А он - монолит. Суть спора все та же: микроядро ничем не лучше монолита в управлении SMP системой. >PS какие там могут быть состояния ожидания и взаимные блокировки??? QNX - >это RTOS. ну а тут Вы перегнули. Такого бреда я сказать не мог. "Взаимные блокировки". Это ж dealdock! Даже определение для Вас нашел (http://ru.wikipedia.org/wiki/Взаимная_блокировка): "Взаимная блокировка (англ. deadlock) — ситуация в многозадачной среде, при которой несколько процессов находятся в состоянии бесконечного ожидания ресурсов, захваченных самими этими процессами." И будьте уверены, что в данном треде не только Вы понимаете значения слов "realtime" и "lockless"...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	70. "QNX"
	Сообщение от _Nick_ (??) on 22-Июн-07, 17:29
	>Но описанный метод передачи сообщений используеться и в RTLinux'е. Имееццо ввиду асинхронный метод передачи, не тот что я описал.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	71. "QNX"
	Сообщение от gmm20 (??) on 22-Июн-07, 18:56
	> Суть спора все та же: микроядро ничем не лучше монолита в управлении SMP системой. наивный вопрос: почему тогда Cisco купили лиценизю на QNX и делали с нуля новую систему IOS XR вместо того, чтобы использовать свое собственное монолитное ядро IOS? а что такое "управление SMP системой" ? эфективное использование ресурсов всех CPU ? SMP kernels плохо масштабируются на количество cores больше восьми, это общеизвестный факт. в системах, где больше 8 cores - используют не SMP Linux kernels, а NUMA Linux kernels. я не уверен, что QNX будет так же неэффективно использовать cores, как и SMP Linux kernels. > И будьте уверены, что в данном треде > не только Вы понимаете значения слов "realtime" и "lockless"... я очень надеюсь на это.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	73. "QNX"
	Сообщение от _Nick_ (??) on 22-Июн-07, 20:19
	>наивный вопрос: почему тогда Cisco купили лиценизю на QNX и делали с >нуля новую >систему IOS XR вместо того, чтобы использовать свое собственное монолитное ядро IOS? Манагеры посчитали сколько будет стоить своя разработка и цену QNX. Выиграли не свои девелоперы всего-то >а что такое "управление SMP системой" ? эфективное использование ресурсов всех CPU >? >SMP kernels плохо масштабируются на количество cores больше восьми, это общеизвестный факт. Расскажи это инженеру этой системы. Чтоб он не SMP, а NUMA делал в таком случае. Тока непонятно зачем мне это говорить, если ДАНА SMP система. Хорошая или плохая. И мы ведем речь об управлении ею. Если тебе не нравяццо SMP, а ты любитель NUMA - ну не буду я тебя переубеждать. Но все же призову НЕ путать железо и софт. Мы сейчас говорим об SMP и ПРОГРАММНЫМИ методами управления. Кому нужны тут твои заключения, что это неудачная аппаратная конфигурация? Какая есть такая есть. >в системах, где больше 8 cores - используют не SMP Linux kernels, >а NUMA Linux kernels. замечательно. У нас разговор об "обычных" SMP на 4 проца. >я не уверен, что QNX будет так же неэффективно использовать cores, как >и SMP Linux kernels. ну так есть же NUMAв Линухе. Ессьно он будет работать на NUMA системах. Какой идиот туда будет ставить SMP ядро и потом сравнивать это с QNX (кроме QNX манагеров...)?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	75. "QNX vs Linux at SMP/ccNUMA"
	Сообщение от gmm20 (??) on 22-Июн-07, 21:56
	> инженеру этой системы. Чтоб он не SMP, а NUMA делал в таком случае. > Тока непонятно зачем мне это говорить, если ДАНА SMP система. посмотри сообщение belkin #19 и свой ответ #21, SMP очень неэффективна при большом количестве ядер. > И мы ведем речь об управлении ею. Если тебе не нравяццо SMP, > а ты любитель NUMA - ну не буду я тебя переубеждать. > Но все же призову НЕ путать железо и софт. AMD Opteron имеет контролер памяти встроенный в процессор, причем каждый процессор имеет свою собственную память. такая аппаратная конфигурация - это и есть cache coherent NUMA. а уж каким способом ты будешь пытаться ее использовать, в качестве SMP, или NUMA - железо тебя не ограничивает. >> в системах, где больше 8 cores - используют не SMP Linux kernels, а NUMA Linux kernels. > замечательно. У нас разговор об "обычных" SMP на 4 проца. уже SMP на четыре? как быстро же ты сдулся... совсем недавно говорил о тысячах процов, которые успешно шедулит линукс-монолит ядро. пытаешься создать видимость своей правоты? >> я не уверен, что QNX будет так же неэффективно >> использовать cores, как и SMP Linux kernels. > ну так есть же NUMAв Линухе. Ессьно он будет работать на NUMA системах. > Какой идиот туда будет ставить SMP ядро и потом сравнивать это с QNX ccNUMA - это есть обычная SMP, но с разной скоростью доступа к разным участкам памяти. кстати, в обычной SMP скорость доступа также не всегда одинаковая из-за сache locality.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	76. "QNX vs Linux at SMP/ccNUMA"
	Сообщение от _Nick_ (??) on 22-Июн-07, 22:06
	>уже SMP на четыре? как быстро же ты сдулся... совсем недавно говорил >о тысячах процов, >которые успешно шедулит линукс-монолит ядро. пытаешься создать видимость своей правоты? ладно. Сколько бы ни было процов: суть спора была в том, что принцип защиты памяти ядра (монолит или микроядро) не влияет на качество управления этими процами.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	80. "QNX vs Linux at SMP/ccNUMA"
	Сообщение от gmm20 (??) on 22-Июн-07, 22:40
	> Сколько бы ни было процов: суть спора была в том, что принцип защиты памяти > ядра (монолит или микроядро) не влияет на качество управления этими процами. в результате выяснилось, что чем больше cores, тем больше монолитное kernel тратит времени на синхронизацию доступа к критическим секциям, семафоры, и т.п. фигню. не говоря уже о том, что написать нетривиальное SMP-приложение - это очень сложная задача. при переходе FreeBSD с 4.х на 6.х - вся 5-я ветка гораздо хуже 4-й и по производительности и по надежности. такая вот цена одновременного использования нескольких cores системой FreeBSD. не зря ведь откололась DragonFly BSD, потому что Matthew Dillon правильно считал и считает SMP тупиковой веткой развития мультипроцессорных операционных систем. 2, 4 ядра было вчера, сегодня это уже 4, 8 ядер. через год-два наступит светлое будущее, и все быстрые сегодня, тормозные и глючные завтра SMP kernels больше никому не будут нужны при большом количестве cores. и только во фре завершится переход UP => SMP, как нужно будет начинать новый: SMP => NUMA.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	82. "QNX vs Linux at SMP/ccNUMA"
	Сообщение от _Nick_ (??) on 22-Июн-07, 23:08
	>в результате выяснилось, что чем больше cores, тем больше монолитное kernel тратит > >времени на синхронизацию доступа к критическим секциям, семафоры, и т.п. фигню. нихрена подобного не выяснялось. RTLinux весьма монолит но на любой чих там свой ядреный процесс. То же самое происходит и в микроядре. Вся разница между ними - это ЛИШЬ способ защиты памяти ядра: в монолите один на всех, а в микроядре у каждого потока свое пространство. >не говоря уже о том, что написать нетривиальное SMP-приложение - это очень >сложная задача. >при переходе FreeBSD и только в этом месте стало примерно понятно почему Вы не любите монолит. Но почему бы не обратить внимание на то, что линух это не ядро BSD? Там до сих пор наводит страх giantLock. Линух же еще с прошлого мажора весьма культурен в многопроцессорной системе. Как сказал на днях Михаил о Линуксе и федоре - можно примено также выразиться и о монолите и BSD :) "Не нужно судить о монолите по BSD ядру" (ц)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	85. "."
	Сообщение от gmm20 (??) on 22-Июн-07, 23:29
	>> в результате выяснилось, что чем больше cores, тем больше монолитное kernel тратит >> времени на синхронизацию доступа к критическим секциям, семафоры, и т.п. фигню. > RTLinux весьма монолит но на любой чих там свой > ядреный процесс. То же самое происходит и в микроядре. > Вся разница между ними - это ЛИШЬ способ защиты памяти ядра: > в монолите один на всех, а в микроядре у каждого потока свое пространство. есть и более существенные различия. .
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	87. "."
	Сообщение от _Nick_ (??) on 22-Июн-07, 23:36
	>> Вся разница между ними - это ЛИШЬ способ защиты памяти ядра: >> в монолите один на всех, а в микроядре у каждого потока свое пространство. > >есть и более существенные различия. это уже следствие того, что все нити не в одном адрессном пространстве. Там приходиться думать над коммуникациями между ними и т.д. конечно Но изначальное различие и назначение - это именно разделение всего кода ядра на защищенные подсистемы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	78. "QNX vs Linux  SMP vs ccNUMA"
	Сообщение от Michael Shigorin on 22-Июн-07, 22:17
	>уже SMP на четыре? как быстро же ты сдулся... совсем недавно говорил >о тысячах процов, которые успешно шедулит линукс-монолит ядро. Мужуки, давайте различать тысячу процессоров под одним экземпляром linux kernel, что успешно бывает, и SMP vs NUMA.  Линукс-то от этого микроядерным не становится, и склеивать два _отдельных_ обсуждения в один контекст нисколько не помогает почерпнуть из знаний друг друга.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	79. "QNX vs Linux  SMP vs ccNUMA"
	Сообщение от _Nick_ (??) on 22-Июн-07, 22:30
	>Мужуки, давайте различать тысячу процессоров под одним экземпляром linux kernel, что успешно бывает, Вот об этом и был разговор (как мне казалось). Но назвав тисячепроцессорную систему страшным словом "SMP" - был избит палками :) Да, тут я скорее всего неправ. И такие системы не бывают SMPшными - ну звыняйте, gmm20. Но в итоге, вроде бы мы вышли на исходную трассу. И спор очерчен заново: влияет ли архитектура ядра - монолит иль микроядро - на качество управления процами в SMP/NUMA (шоб всякие "по-мелочам" не приставали ;) системах. Причем, что лучше/хуже SMP или NUMA - не рассматриваем.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	83. "QNX vs Linux  SMP vs ccNUMA"
	Сообщение от gmm20 (??) on 22-Июн-07, 23:18
	> И спор очерчен заново: влияет ли архитектура ядра - монолит > иль микроядро - на качество управления процами в SMP/NUMA системах. операционные системы создаются не для того, чтобы процами управлять, а чтобы решать прикладные задачи. то что они в результате научились эффективно "управлять процами" - это всего лишь побочный эффект. мне просто грустно, что там наверху будуть летать многотонные дуры, которые управляются не QNX`ом. а каким-то монолитным ядром, пусть даже оно называется и linux с приставкой real-time.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	86. "QNX vs Linux  SMP vs ccNUMA"
	Сообщение от _Nick_ (??) on 22-Июн-07, 23:33
	>операционные системы создаются не для того, чтобы процами управлять, >а чтобы решать прикладные задачи. то что они в результате научились >эффективно "управлять процами" - это всего лишь побочный эффект. вай-вай-вай типа правильно развесить процессы этих самых прикладных задач по процессорам - это не решение прикладных задач. >мне просто грустно, что там наверху будуть летать многотонные дуры, >которые управляются не QNX`ом. а каким-то монолитным ядром, >пусть даже оно называется и linux с приставкой real-time. странно почему тебе не грустно от того, что QNX не так гибок (в лицензировании, доступе к исходникам, разработке под него) как Линух. А летать там будет что нужно и под чем нужно. А тебя не смущает, что в следствии каких-нить лицензионных (или прочих технических проблем, связанных с тем, что QNX нельзя править) система управления этими самыми "многотонными дурами" будет не столь прозрачна и гибка? Что может кое-где помешать эффективному управлению ними... Закрытый продукт - это закрытый продукт. Это черный ящик, под который _всегда_ приходиться подстраиваться. Так вот я склонен считать, что пусть инженеры будут затачивать ОС под свои корабли и требования безопасности полетов, а не корабли под ОС и ее недалекие лицензии...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	81. "QNX vs Linux  at 2,4,8,16,32,64,...1024 cores"
	Сообщение от gmm20 (??) on 22-Июн-07, 23:04
	> Мужуки, давайте различать тысячу процессоров > под одним экземпляром linux kernel, что успешно бывает и SMP vs NUMA.   SMP упирается в шину уже после восьми cores. что тут обсуждать? 1 core: UP 2-8 cores: SMP 16-256|512|1024 cores: ccNUMA/NUMA нет тут никакого "SMP vs ccNUMA". > Линукс-то от этого микроядерным не становится, > и склеивать два _отдельных_ обсуждения в один контекст > нисколько не помогает почерпнуть из знаний друг друга. здесь нет двух разных обсуждений. обсуждаются две UNIX-like операционные системы на определенной аппаратной конфигурации, с количеством ядер 2**n, где n изменяется от 1 до 10. мнения вижу, факты/аргументы - нет. обсуждаемые параметры: надежность и скорость работы OS/софта, простота и удобство написания софта под эту OS, при n => 10.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	84. "QNX vs Linux  at 2,4,8,16,32,64,...1024 cores"
	Сообщение от _Nick_ (??) on 22-Июн-07, 23:20
	>SMP упирается в шину уже после восьми cores. что тут обсуждать? > >1 core: UP >2-8 cores: SMP >16-256|512|1024 cores: ccNUMA/NUMA > >нет тут никакого "SMP vs ccNUMA". у тебя какая-то своя вселенная... в определении SMP _нет_ ограничений на количесвто процессоров, даже если на _текущий_ момент технического развития больше 8 процессоров действительно нецелесообразно объединять в SMP систему. >> Линукс-то от этого микроядерным не становится, >> и склеивать два _отдельных_ обсуждения в один контекст >> нисколько не помогает почерпнуть из знаний друг друга. > >здесь нет двух разных обсуждений. обсуждаются две UNIX-like операционные >системы какого хрена ты тогда BSD впомнил? Или QNX+Linux+BSD = 2 ??? ты полуторабитный и у тебя переполнение? >на определенной аппаратной конфигурации, с количеством ядер 2**n, >где n изменяется от 1 до 10. мнения вижу, факты/аргументы - нет. > >обсуждаемые параметры: надежность и скорость работы OS/софта, >простота и удобство написания софта под эту OS, при n => 10. "где n изменяется от 1 до 10" ... "при n => 10" Занавес.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	90. "."
	Сообщение от gmm20 (??) on 23-Июн-07, 00:00
	_Nick_> хороша у тя трава :) _Nick_> да тут гении на опеннете пропадают... :) _Nick_> Ты из какого зоопарка сбежал? :) _Nick_> у тебя какая-то своя вселенная... _Nick_> какого хрена ты тогда _Nick_> ты полуторабитный и у тебя переполнение? http://www.microchip.ru/phorum/read.php?f=2&i=126600&t=126600
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	91. "."
	Сообщение от _Nick_ (??) on 23-Июн-07, 00:08
	ну наконец-то ты сполз чисто на личности :) ознаменовав конец спора по теме. А на оффтопик времени нет
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	88. "QNX vs Linux  at 2,4,8,16,32,64,...1024 cores"
	Сообщение от Michael Shigorin on 22-Июн-07, 23:37
	>нет тут никакого "SMP vs ccNUMA". Э... согласен, спасибо.  Но всё равно предлагаю тему остудить, толк уже весь вышел.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	89. "QNX vs Linux  at 2,4,8,16,32,64,...1024 cores"
	Сообщение от _Nick_ (??) on 22-Июн-07, 23:42
	>Но всё равно предлагаю тему остудить, толк уже весь вышел. ну да уже все уже корабли и "многотонные дуры" браздят просторы большого опеннета :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	55. "RTFS! :-/"
	Сообщение от _Nick_ (??) on 21-Июн-07, 13:03
	>Эх, ма. Смотрите первое сообщение. Критические секции ! Там где запрещён параллельный >доступ к внутренним структурам ядра. Ну и ничего страшного. Это особенность SMP архитектуры. ГДЕ здесь _вина_ или _неоптимальность_ ядра Линукс? И особенно в его монолитности :)))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	56. "RTFS! :-/"
	Сообщение от Michael Shigorin on 21-Июн-07, 13:17
	>Это особенность SMP архитектуры. Нет.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	57. "RTFS! :-/"
	Сообщение от _Nick_ (??) on 21-Июн-07, 13:31
	>>Это особенность SMP архитектуры. >Нет. Ок, много чего было сказано. Может мы о разном. Я о том, что одна шина SMP системы (и не только SMP) ограничивает возможности процессоров. Не вижу здесь вины Линуха :) Он вынужден жить в таких условиях. Если же у нас речь о локах, защищающих внутренние структуры от паралельного доступа, - то и тут в линухе все хорошо. Хоть и не имеет это ничего общего с SMP.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	58. "RTFS! :-/"
	Сообщение от Michael Shigorin on 21-Июн-07, 13:35
	>Если же у нас речь о локах, защищающих внутренние структуры от паралельного >доступа, - то и тут в линухе все хорошо. Хоть и >не имеет это ничего общего с SMP. Имеет прямое отношение к возможности работать на SMP в т.ч.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	59. "RTFS! :-/"
	Сообщение от _Nick_ (??) on 21-Июн-07, 13:48
	>Имеет прямое отношение к возможности работать на SMP в т.ч. Ну, разве что учесть то, что проц в SMP должен лочить шину под адресу расположения лока, для того чтобы с ним работать. Т.е. SMP добавляет просто еще одну блокировку к сасому факту наличия локов. Если это прямое отношение - ради бога :) По мне так это лишь "добавка" от SMP-подсистемы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	72. "QNX"
	Сообщение от gmm20 (??) on 22-Июн-07, 20:14
	>> Смотрите первое сообщение. Критические секции! >> Там где запрещён параллельный доступ к внутренним структурам ядра. > Ну и ничего страшного. > Это особенность SMP архитектуры. > ГДЕ здесь _вина_ или _неоптимальность_ ядра Линукс? > И особенно в его монолитности :))) критические секции для синхронизации - это именно что особенность монолитного ядра. "особенность SMP архитектуры" состоит в том, что системная шина становится узким местом.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	74. "QNX"
	Сообщение от _Nick_ (??) on 22-Июн-07, 20:21
	>критические секции для синхронизации - это именно что особенность монолитного ядра. внимательно слушаю сказку о том, что в микроядре (именно том бинаре, который управляет памятью и процессами) нет критических секций :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	49. "совсем не так"
	Сообщение от _Nick_ (??) on 21-Июн-07, 12:18
	>>>Имейте систему из многих малозависимых друг от друга процессов и проблемы блокировок >>>и конфликтов исчезнут. >>блин... >>так а при чем тут ЯДРО?? >>Судя по вашим словам его проблемы решаються правильным выбором юзер-левел процессов %)))) > >Эх, ма. О ядерных процессах речь. Ладно, разжовываю: "сделайте ядро ОС не >одним большим куском, а состоящее из небольших, но функционально законченных процессов, >способных безопасно параллельно выполнятся на процессорах в системах SMP и проблемы >блокировок и конфликтов будут более редкими". ВНИМАТЕЛЬНО следи за выводом 'ps'а (отгрепаны лишь ядерные нити) на 4-ядерном Линухе. root         2  0.0  0.0     0    0 ?        S    May15   0:15 [migration/0] root         3  0.0  0.0     0    0 ?        SN   May15   0:08 [ksoftirqd/0] root         4  0.0  0.0     0    0 ?        S    May15   0:04 [migration/1] root         5  0.0  0.0     0    0 ?        SN   May15   0:04 [ksoftirqd/1] root         6  0.0  0.0     0    0 ?        S    May15   1:34 [migration/2] root         7  0.0  0.0     0    0 ?        SN   May15   0:14 [ksoftirqd/2] root         8  0.0  0.0     0    0 ?        S    May15   0:23 [migration/3] root         9  0.0  0.0     0    0 ?        SN   May15   0:10 [ksoftirqd/3] root        10  0.0  0.0     0    0 ?        S<   May15   0:00 [events/0] root        11  0.0  0.0     0    0 ?        S<   May15   0:00 [events/1] root        12  0.0  0.0     0    0 ?        S<   May15   0:00 [events/2] root        13  0.0  0.0     0    0 ?        S<   May15   0:00 [events/3] root       218  0.0  0.0     0    0 ?        S<   May15   0:01  \_ [kblockd/0] root       219  0.0  0.0     0    0 ?        S<   May15   0:03  \_ [kblockd/1] root       220  0.0  0.0     0    0 ?        S<   May15   0:03  \_ [kblockd/2] root       221  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [kblockd/3] root       339  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [ata/0] root       340  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [ata/1] root       341  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [ata/2] root       342  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [ata/3] root       384  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [aio/0] root       385  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [aio/1] root       386  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [aio/2] root       387  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [aio/3] root       394  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [xfslogd/0] root       395  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [xfslogd/1] root       396  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [xfslogd/2] root       397  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [xfslogd/3] root       398  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [xfsdatad/0] root       399  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [xfsdatad/1] root       400  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [xfsdatad/2] root       401  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [xfsdatad/3] root      1200  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [exec-osm/0] root      1201  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [exec-osm/1] root      1202  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [exec-osm/2] root      1203  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [exec-osm/3] root      1209  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [block-osm/0] root      1210  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [block-osm/1] root      1211  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [block-osm/2] root      1212  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [block-osm/3] root      1230  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [kcryptd/0] root      1231  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [kcryptd/1] root      1232  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [kcryptd/2] root      1233  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [kcryptd/3] root      1234  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [kmpathd/0] root      1235  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [kmpathd/1] root      1236  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [kmpathd/2] root      1237  0.0  0.0     0    0 ?        S<   May15   0:00  \_ [kmpathd/3] Не буду расшифровывать названия всех этих ядерных процессов (и ошибиться боюсь и не охота). Как видишь МНОГО чего живет именно в отдельной копии для каждого ядра (нити с номером процессора "/N" в конце). Что же еще не так? :) >SMP - архитектура вычислительной системы, а распределённые вычисления подразумевают сеть из слабосвязанных >вычислительных машин или мы с тобой по разным учебникам учились. Параллельные >вычисления не обязательно распределённые. http://ru.wikipedia.org/wiki/Распределённые_вычисления "Распределённые вычисления (distributed computing, grid computing, volunteer computing) — способ решения трудоёмких вычислительных задач с привлечением большого числа исполнителей, работающих одновременно над разными частями задачи." Ну НЕТУ в определении требований к железной части. Просто наличие большого числа исполнителей (процов). Так что и SMP и NUMA - подходят для решения задач используя _метод_ распределенных вычислений.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	50. "совсем не так"
	Сообщение от Michael Shigorin on 21-Июн-07, 12:21
	>Как видишь МНОГО чего живет именно в отдельной копии для каждого ядра Ядро тут как раз одно, но разложенное по CPU. >Ну НЕТУ в определении требований к железной части. Просто наличие большого числа >исполнителей (процов). Так что и SMP и NUMA - подходят для >решения задач используя _метод_ распределенных вычислений. Не совсем так, для DC SMP/NUMA -- это то, что спрятано внутри нод (исполнителей) и "не касается".
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	52. "совсем не так"
	Сообщение от _Nick_ (??) on 21-Июн-07, 12:34
	>>Как видишь МНОГО чего живет именно в отдельной копии для каждого ядра >Ядро тут как раз одно, но разложенное по CPU. Ессьно, я имел ввиду железное ядро проца здесь. Витруализации здесь нет - посему линуховое ядро тока одно, конечно же :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	26. "совсем не так"
	Сообщение от Michael Shigorin on 20-Июн-07, 16:52
	>Тысячи процов ? В тысячах компьютеров - по одному процессору на коробку ? Не тысячи, а тысячу (на одном ядре) -- из того, что помню. http://www.novell.com/products/server/techspecs.html (Kernel Limits, искать слово SGI) http://lkml.org/lkml/2007/3/13/65 >Системщики смотрели код ядра, а потом другая группа подтвердила это на стенде >с 16-ью процессорами: потоки стоят и нервно куря ждут своей очереди >чтобы пролезть в замочную скважину. Это всем известная проблема SMP, но >с монолитными ядрами она выпячивается больше. Боюсь, это или системщики такие, или задача такая, или SMP имени Intel с кривым транспортом между камнями.  Не знаю, что именно со скедулером, но существенные куски ядра сейчас именно параллелятся (некоторые раскладываются по всем доступным процессорам).  Ядра, а не юзерспейсной задачи. Ну и на 2--8 CPU линуксу вообще-то давно хорошо (sweet spot, в смысле, а не "нервно куря").  Чуть ли не с 2.4.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	34. "совсем не так"
	Сообщение от sauron (??) on 20-Июн-07, 21:27
	>Системщики смотрели код ядра, а потом другая группа подтвердила это на стенде >с 16-ью процессорами: потоки стоят и нервно куря ждут своей очереди >чтобы пролезть в замочную скважину. Это всем известная проблема SMP, но >с монолитными ядрами она выпячивается больше. Ну во первых SMP системы с количеством процессоров более 4 когда они сидят впринципе не бывает. Так как это и при четырех то процессорах не эффективно. И начинают использовать другие архитектуры. К примеру NUMA, которая присутсвует у AMD за счет чего они в свое время откусили рынок у Intel. И продолжают откусывать там где упор больше идет в ввод-вывод. Так как даже хваленые Intel Core Duo на массированных операциях ввода вывода сливают процессорам от AMD. И это происходит из-за того что работа с переферией у AMD осуществленная более грамотно. У шудлера же Linux недавно находили проблему в том, что после 8 потоков оно масштабируется хреново. Но случай там брался сферический конь в вакууме т.е. все в памяти. Другие же тесты где использовались внешние медленные носители такого резкого обвала не показали.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	36. "совсем не так"
	Сообщение от cmpxchg on 20-Июн-07, 22:20
	>У шудлера же Linux недавно находили проблему в том, что после >8 потоков оно масштабируется хреново. Но случай там брался сферический конь >в вакууме т.е. все в памяти. Другие же тесты где использовались >внешние медленные носители такого резкого обвала не показали. Еще бы не показали - ведь это уже тест "медленных носителей", а не того, как работает ПО. А "медленные носители" работают везде почти одинаково ( кроме случаев совсем кривых дров, разумеется ). И никакой это не сферический конь в вакууме - про in-memory tables слышали?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	38. "совсем не так"
	Сообщение от sauron (??) on 20-Июн-07, 22:50
	>Еще бы не показали - ведь это уже тест "медленных носителей", а >не того, как работает ПО. Практически все системы работают именно с такими медленными носителями :) И еще долго будут с ними работать. >И никакой это не сферический конь в вакууме - про in-memory tables >слышали? Слышал. Приведенная вами штука жрет очень много памяти и имеет довольно специфичную область применения.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	41. "совсем не так"
	Сообщение от cmpxchg on 21-Июн-07, 01:21
	>Практически все системы работают именно с такими медленными носителями :) И еще долго >будут с ними работать. Не спорю. Вот только масштабируемость планировщика потоков нужно тестить под нагрузкой процессоров, а не I/O, как это будет в случае, если задействованы медленные носители. Если на каждом чихе СУБД полезет считывать данные с HDD, то на чем тогда тестировать планировщик? На спящих потоках, что ли?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	42. "совсем не так"
	Сообщение от sauron (??) on 21-Июн-07, 06:54
	>Не спорю. Вот только масштабируемость планировщика потоков нужно тестить под нагрузкой процессоров, >а не I/O, как это будет в случае, если задействованы медленные >носители. Если на каждом чихе СУБД полезет считывать данные с HDD, >то на чем тогда тестировать планировщик? На спящих потоках, что ли? Тестировать надо на реальных задачах. Иначе если к примеру будет произведено тестирование без IO и оптимизация так же будет проведена без IO то может получиться замечательная ситуация, когда у нас будет замечательный шудлер который не особо стыкуется с системой ввода-вывода.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

30. "NASA тестирует систему управления космическим кораблем на ба..."

Сообщение от ДяДя on 20-Июн-07, 17:25

> Начали с покупки технологии RTLinux у FSMLabs. Народ, поясните пожалуйста. Зачем было покупать, если GPL ? Или это правило хорошего тона, или использована юридическая (техническая) уловка для обхода GPL ??

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	32. "RTLinux"
	Сообщение от Michael Shigorin on 20-Июн-07, 18:32
	>> Начали с покупки технологии RTLinux у FSMLabs. >Народ, поясните пожалуйста. Зачем было покупать, если GPL ? Так своя технология у них вполне патентованная ( :/ ) и закрытая.  Работает не только с линуксом. http://www.linuxdevices.com/news/NS2333482316.html /RTCore
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	35. "RTLinux"
	Сообщение от GURW on 20-Июн-07, 22:11
	писал для qnx6.3 Там только среда разработки и отладки стоит 16 тыс долларов. Это скорее эксклюзив. Удобно, но ограничено. Писал для linux - верх наслаждения. Emacs и вперед. Лучше и удобнее средства для отладки думаю не существует
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	47. "RTLinux"
	Сообщение от belkin on 21-Июн-07, 12:07
	>писал для qnx6.3 >Там только среда разработки и отладки стоит 16 тыс долларов. Это скорее >эксклюзив. Удобно, но ограничено. >Писал для linux - верх наслаждения. Emacs и вперед. Лучше и удобнее >средства для отладки думаю не существует $16k для тех, кто строит самолёты, запускает ракеты в космос или строит АЭС это не деньги. Тем более, что в стоимость включено сопровождение высокого уровня и это важнее всего.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	51. "RTLinux"
	Сообщение от _Nick_ (??) on 21-Июн-07, 12:24
	>>писал для qnx6.3 >>Там только среда разработки и отладки стоит 16 тыс долларов. Это скорее >>эксклюзив. Удобно, но ограничено. >>Писал для linux - верх наслаждения. Emacs и вперед. Лучше и удобнее >>средства для отладки думаю не существует > >$16k для тех, кто строит самолёты, запускает ракеты в космос или строит >АЭС это не деньги. Тем более, что в стоимость включено сопровождение >высокого уровня и это важнее всего. 16к - "Удобно, но ограничено" 0 - "Лучше и удобнее" а за 16к и под Emacs, думаю, можно поиметь _некислую_ поддержку... ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	62. "RTLinux"
	Сообщение от ДяДя on 21-Июн-07, 19:02
	>а за 16к и под Emacs, думаю, можно поиметь _некислую_ поддержку... ;) Уж лучше KDevelop без поддержки, чем emacs с оной ;-) У меня один знакомый пишет софт для систем наведения подводных лодок. Используется там QNX. Что такое $16K, если стоимость обычного сдвоенного LCD монитора, после военной приёмки, составляет 500000 руб.(я не опечатался не 50000, а 500000)??  Глупо экономить на мелочах. Про Linux у них даже думать не хотят. Потом я не думаю, что RTLinux будет существенно дешевле, а обычный Linux совершенно не подойдёт. P.S. Для конечного пользователя QNX бесплатен с 2000-го года. Emacs под QNX отлично работает, как и GCC c binutils.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	63. "RTLinux"
	Сообщение от _Nick_ (??) on 21-Июн-07, 19:15
	>Уж лучше KDevelop без поддержки, чем emacs с оной ;-) +5 %))))) >У меня один знакомый пишет софт для систем наведения подводных лодок. >Используется там QNX. Что такое $16K, если стоимость обычного сдвоенного LCD монитора, >после военной приёмки, составляет 500000 руб.(я не опечатался не 50000, а >500000)??  Глупо экономить на мелочах. >Про Linux у них даже думать не хотят. >Потом я не думаю, что RTLinux будет существенно дешевле, а обычный Linux >совершенно не подойдёт. > >P.S. >Для конечного пользователя QNX бесплатен с 2000-го года. Не для конечных, а для одиночного использования. т.е. для себя, в некоммерческих целях. >Emacs под QNX отлично работает, как и GCC c binutils. это почти как KDE хотеть под венду. Ну нах#%&^#%&ера извращаццо, когда есть Линух, без идиотских проприетарных ограничений (сырцы, себя/несебя, коммерческое использование...)?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	65. "RTLinux"
	Сообщение от belkin on 22-Июн-07, 10:33
	>У меня один знакомый пишет софт для систем наведения подводных лодок. Вот так ничинаются шпионские скандалы. Молодец, услужил знакомому.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

44. "Linux: Introducing Bugs"

Сообщение от Michael Shigorin on 21-Июн-07, 09:58

http://kerneltrap.org/node/8414 О чём, собственно, тоже говорилось.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	45. "Linux: Introducing Bugs"
	Сообщение от _Nick_ (??) on 21-Июн-07, 10:27
	>http://kerneltrap.org/node/8414 > >О чём, собственно, тоже говорилось. Молодец Торвальдс. Не отворачивается от реалий. А эти самые реалии, собсно уже и так ведуться: http://kernelnewbies.org/known_regressions
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

77. "NASA тестирует систему управления космическим кораблем на ба..."

Сообщение от Аноним on 22-Июн-07, 22:16

:))) RTLinuxFree.com is in transition. Please check back in March for updates. 22 06 2007

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]