Проблема: ESI Juli@, VST & Out Of Memory

  • Автор темы Автор темы Lexman
  • Дата начала Дата начала

Lexman

What?!
24 Дек 2004
594
345
93
Краснодар
Прикупил сию карточку и тут же наткнулся на неприятную проблему:
при загрузке массивного VST, когда объем подгружаемого банка превышает объем оперативы, после соответствующего сообщения (мол продолжить закачку?) и соглашения система уходит в аварийный останов ещё некоторое время попытавшись что-то закачать. Что характерно, пока юзал встроенную звучку, проблем не было, не было такого даже на старенькой ливе.
Что за таракан?

ЗЫ информация по сбою системы (которая на синем фоне) ссылается на плохо себя ведущий драйвер Julia. Попробовал две из четырех версий драйвера, что поставляются на компакте (самую новую и самую старую) - результат тот же.
Может было у кого? Поиск не в курсе.
 
Ахрененно.
А менее болезненных способов нет?
Система новая сосвем, хотя я и собирался делать апгрейд (вроде как временно у меня пень Д), но не настоолько резко.
 
Тока одна неувязочка:
глюки появились вместе с новой картой.
Т.е. версии о несовместимости софта со старым железом неправдоподобна.
 
На встроенной карте какая latency? :lol: Нажал клавишу и пошел кофе пить :D

<div class='quotetop'>Цитата(Lexman @ Dec 30 2006, 10:17 PM) [snapback]388973[/snapback]</div>
Тока одна неувязочка:
глюки появились вместе с новой картой.
Т.е. версии о несовместимости софта со старым железом неправдоподобна.
[/b]
Как я понимаю термин Hyper treating:ядро одно,а секвенсор видит 2 процессора
Происходит обращение к одному адресу памяти,ну и сбои соответственно :D
После перехода на А64 данная проблема у меня исчезла B)
 
К сожалению, у тебя не верное понимание сути двухпроцессорной машины.
Я когда-то (года 2-3 назад, щас бросил) занимался программированием.
Количество процессоров никак не связано с адресным пространством, строго говоря, софт, ориентированный на одно ядро будет работать и на двухядернике или двухпроцессорнике, но задейсвовано будет одно ядро (процессор).
Например - Windows 98 не поддерживает многопроцессорные машины, но работать на них, на сколько я помню, будет.

По поводу latency - а причем здесь она? Я же говорю - сбой происходит в процессе ЗАГРУЗКИ VST. Т.е. проект (Nuendo) ещё не успевает открыться.
Имхо, тараканы надо искать в драйверах Juli@, тока кому ж этим заняться-то... :)

ЗЫ
Поставил DFD - вроде всё работает.
Кстати, сорри - я неправильно прочитал твой первый пост - у меня конТактовские (EWQLSO) библиотеки.
 
<div class='quotetop'>Цитата(Lexman @ Dec 31 2006, 12:03 PM) [snapback]389160[/snapback]</div>
К сожалению, у тебя не верное понимание сути двухпроцессорной машины.

[/b]
HT -не два процессора,а один :lol: полтакта-один,еще полтакта -два :lol: А один хер один :rolleyes:

А может проблема в засоренности системы?У меня с Юлькой проблем не было(кроме описанной выше)
Пробовал отключить HT?

Кстати,если выбивает на синий экран,может проблема в ACPI?На прерывании Julia
еще сидит что-нибудь?
 
Дело не в том, сколько микросхем стоит на плате.
Количество процессоров - это прежде всего программная абстракция (а мы ведь о софте, верно?).
Если посмотреть на системную инфу, и на диспетчер задач, видно, что система считает, что у неё 2 процессора.
А это означает с точки зрения API, что софт при желании может программно распределять задачи на разные процессоры. А что уж там - HT или XEON, или вирус который изменил представление системы о количестве процов :) - не важно.
 
<div class='quotetop'>Цитата(Lexman @ Dec 31 2006, 01:34 PM) [snapback]389227[/snapback]</div>
видно, что система считает, что у неё 2 процессора.

[/b]
Вот именно,что считает :lol:
Hyper Threading:

1. Данная технология предназначена для увеличения эффективности работы процессора. Дело в том, что, по оценкам Intel, большую часть времени работает всего 30% (кстати, достаточно спорная цифра — подробности ее вычисления неизвестны) всех исполнительных устройств в процессоре. Согласитесь, это достаточно обидно. И то, что возникла идея каким-то образом "догрузить" остальные 70% — выглядит вполне логично (тем более что сам по себе процессор Pentium 4, в котором и внедрят эту технологию, отнюдь не страдает от избыточной производительности на мегагерц). Так что эту идею автор вынужден признать вполне здравой.

2. Суть технологии Hyper Threading состоит в том, что во время исполнения одной "нити" программы простаивающие исполнительные устройства могут заняться исполнением другой "нити" программы (или "нити" другой программы). Или, например, исполняя одну последовательность команд, ожидать данных из памяти для исполнения другой последовательности.

3. Естественно, выполняя различные "нити", процессор должен каким-либо образом отличать, какие команды к какой "нити" относятся. Значит, есть какой-то механизм (некая метка), благодаря которой процессор отличает, к какой "нити" относятся команды.

4. Ясно также, что, учитывая небольшое количество регистров общего назначения в архитектуре х86 (всего 8), у каждой нити свой набор регистров. Впрочем, это уже давно не новость — данное ограничение архитектуры уже довольно давно обходится при помощи "переименования регистров". Другими словами, физических регистров намного больше, чем логических. В процессоре Pentium III их 40. Наверняка это число для Pentium 4 больше — у автора есть ничем не обоснованное (кроме соображений "симметрии" :-) мнение, что их порядка сотни. Никаких достоверных сведений об их количестве найти не удалось. По неподтвержденным пока данным, их 256. По другим данным — другое число. В общем, полная неопределенность…. Кстати, позиция Intel по этому поводу совершенно непонятна :-( — автору непонятно, чем вызвана подобная секретность.

5. Также известно, что в случае, когда несколько "нитей" претендуют на одни и те же ресурсы, либо одна из "нитей" ждет данных — во избежание падения производительности программисту необходимо вставлять специальную команду — "pause". Естественно, это потребует очередной перекомпиляции программ.

6. Также понятно, что возможны ситуации, когда попытки одновременного исполнения нескольких "нитей" приведут к падению производительности. Например, из-за того, что размер кэша L2 не бесконечный, а активные "нити" будут пытаться загрузить кэш — возможна ситуация, когда такая "борьба за кэш" приведет к постоянной очистке и перезагрузке данных в кэше второго уровня.

7. Intel утверждает, что при оптимизации программ под данную технологию выигрыш будет составлять до 30%. (Вернее, Intel утверждает, что на сегодняшних серверных приложениях и сегодняшних системах измеренный выигрыш до 30%)


А вот из-за п.5 все проблемы :lol: Поскольку Куб не заточен под НТ(вернее заточен под мультипроцессорность,а это разные вещи)
п.7 реального повышения производительности нет
Я почувствовал реальое повышение производительности,когда перешел на двух"ядерник
 
Хех. С миру по нитке, называется :))
Я уж не знаю, где ты это взял, но - разве мы о производительности говорим? :)
По поводу п.3: различие процессов (нитей) и т.п. возлагается на операционную систему. Сам процессор не выбирает, с какой "нитью" ему на данный момент работать. А механизмы определения ("метки") - их целый набор. Но они срыты в системе и к процессору прямого отношения не имеют.

По поводу п.5 - ерунда. Во-первых, не "необходимо". Ресурсы компа, в т.ч. ресурсы ЦП, выделяемые выполняемым в данный момент процессам и их потокам, администрируются системой. Т.е., процесс или его поток (что есть вещи сильно разные, но здесь почему то речь только о "нитях" или "потоках" - Thread) не могут нагло "ОТОБРАТЬ" у системы что-то. Но, при желании программиста, ОТДАТЬ лишнее могут - тут упоминается некая команда "pause", но если мне не врет память, в API такой команды нет. Опять таки, если память мне не врет (могу, кончено, глянуть в доку), есть т.н. команда нулевой задержки sleep(0), которая говорит системе, что ОСТАТКИ КВАНТА времени процессора , выделенные данному процессу/потоку, можно отдать системе (т.е. другой программе по её выбору). И делается это программистами ой как не часто :) Тем более, если программа требовательна к ресурсам :)))).
Более того, механизм распределения времени процессора операционной системой нигде не документируется (речь об ветке систем WinNT/2000/XP на конец 2004г, с тех пор не слежу), так что говорить о каких-то 100%-тно надежных методах распределения процессорного времени - слишком самонадеянно.
А уж коль речь об HT - это просто методика экономии ресурсов. В свое время таким же "чудом" было появление конвейеров в процессорах. Думаю также, что здесь больше коммерции, чем эффективности.

Далее: "нити будут пытать загрузить кэш" - кэш процессора не доступен рядовым программам напрямую. Не буду утверждать по поводу драйверов, но боле-мене представляя многоуровневую архитектуру драйверов WinNT, скажу, что 100 к одному - кэш процессора доступен ТОЛЬКО СИСТЕМЕ, и не доступен даже большей часте драйверов (которые, как известно, по с равнению с обычными программами, обладают рядом преимуществ). Так что от нас оборот данных в L2 скрыт.
 
Это все теория...Ну и гонка вооружений гигантов кремниестроения.А мы,рядовые пользователи страдаем :lol:
Лучше расскажи,удалось решить проблему.И как? :rolleyes:
 
Да уж, отклонились мы :)

Удалось.
Поставил DFD. С тех пор глюков нет. Возможно, что и сама ось глючила.
Уже навешал синтов в два раза больше, чем тогда - скрипит, а работает :)
 
<div class='quotetop'>Цитата(Lexman @ Jan 2 2007, 08:58 PM) [snapback]389824[/snapback]</div>
Я уж не знаю, где ты это взял, но - разве мы о производительности говорим? :)

[/b]
http://www.ixbt.com/cpu/hyperthreading-tech.shtml
<div class='quotetop'>Цитата(Lexman @ Jan 2 2007, 08:58 PM) [snapback]389824[/snapback]</div>
мы о производительности говорим? :)

[/b]
Cбой происходит по этой причине имхо

<div class='quotetop'>Цитата(Lexman @ Jan 2 2007, 09:17 PM) [snapback]389829[/snapback]</div>
Да уж, отклонились мы :)

Удалось.
Поставил DFD. С тех пор глюков нет. Возможно, что и сама ось глючила.
Уже навешал синтов в два раза больше, чем тогда - скрипит, а работает :)
[/b]
Ну это не совсем решение-проблема то осталась :D
У меня проблема Out of memory решилась отказом от i B)
 
Да это ещё как посмотреть.
Ну, во первых, дело не в производительности - 100%, т.к. даже во время работы проц загружен процентов на 40 всего.
По поводу Out Of memory - сбой возникал при попытке, я бы с казал, "агрессивно" залить в оперативу (в т.ч. в подкачку) большой объем инфы. DFD это дело "размазал" во времени. Вполне возможно, что баги, возникавшие на стадии загрузки проекта просто отсутствуют на стадии воспроизведения.
Но пока проблем не было. Возникнут - бум думать дальше :)
Истинная причина скрыта. Так что все методы хороши :)
 

Сейчас просматривают