Конфигурация с Quad Core

[niki123bg]

LOE, няма особена враждебност в мен - просто те съветвам да не си губиш времето с нещо което явно не те вълнува/не считаш за важно. Постовете ти до тук са като цяло предизвикателни и съответно "предизвикват" някаква реакция, а и надали си очаквал нещо различно.

 

dimitarshenkov, би трябвало да е сравнително статична система, тъй като се влияе основно от това колко бързо драйверите връщат контрола на системата, а не от това колко и какви приложения си пуснал да работят. При една стабилна система, флуктуациите са малки - тоест дори процесора да отиде на 80 - 90% натоварване, DPC latency не трябва да скача сериозно, в противен случай ще е невъзможно в реално време да се чете и пише по буферите на аудио картата.

 

При мен има значение DPC латентността, защото при пикове във DPC latency аудио интерфейсът ми губи буфери (при мен буферите са сложени на 32 семпъла, а това е наистина много ниска стойност - 0.33 мс AD или DA - общо 0.66 мс латентност).

 

Текущата ти карта (Audigy), както и новата ти карта (Audiophile) не позволяват такава екстремно ниска латентност, така че вероятно няма да бъде голям проблем за теб. Нямаше да е лошо да пробваш и да споделиш колко е минималната латентност на аудио интерфейса, при която нямаш припуквания и други артефакти.

 

Ето и малко информация по темата защо се получават припуквания, какво е то DPC латентност и защо и как оказва влияние:

 

Background information: Why drop-outs occur

 

Processing of streaming data in real-time is a very challenging task for Windows based applications and device drivers. This is because by design Windows is not a real-time operating system. There is no guarantee that certain (periodic) actions can be executed in a timely manner.

 

Audio or video data streams transferred from or to an external device are typically handled by a kernel-mode device driver. Data processing in such device drivers is interrupt-driven. Typically, the external hardware periodically issues interrupts to request the driver to transfer the next block of data. In Windows NT based systems (Windows 2000 and better) there is a specific interrupt handling mechanism. A device driver cannot process data immediately in its interrupt routine. It has to schedule a Deferred Procedure Call (DPC) which basically is a callback routine that will be called by the operating system as soon as possible. Any data transfer performed by the device driver takes place in the context of this callback routine, named DPC for short.

 

The operating system maintains DPCs scheduled by device drivers in a queue. There is one DPC queue per CPU available in the system. At certain points the kernel checks the DPC queue and if no interrupt is to be processed and no DPC is currently running the first DPC will be un-queued and executed. DPC queue processing happens before the dispatcher selects a thread and assigns the CPU to it. So, a Deferred Procedure Call has a higher priority than any thread in the system.

 

Note that the Deferred Procedure Call concept exists in kernel mode only. Any user-mode code (Windows applications) runs in the context of a thread. Threads are managed and scheduled for execution by the dispatcher.

 

While there is a pre-emptive multitasking for threads, DPCs are executed sequentially according to the first in, first out nature of a DPC queue. Thus, a sort of cooperative multitasking scheme exists for Deferred Procedure Calls. If any DPC runs for an excessive amount of time then other DPCs will be delayed by that amount of time. Consequently, the latency of a particular DPC is defined as the sum of the execution time of all DPCs queued in front of that DPC. In order to achieve reasonable DPC latencies, in the Windows Device Driver Kit (DDK) documentation Microsoft recommends to return from a DPC routine as quick as possible. Any lengthy operation and specifically loops that wait for a hardware state change (polling) are strongly discouraged.

 

Unfortunately, many existing device drivers do not conform to this advice. Such drivers spend an excessive amount of time in their DPC routines, causing an exceptional large latency for any other driver's DPCs. For a device driver that handles data streams in real-time it is crucial that a DPC scheduled from its interrupt routine is executed before the hardware issues the next interrupt. If the DPC is delayed and runs after the next interrupt occurred, typically a hardware buffer overrun occurs and the flow of data is interrupted. A drop-out occurs.

[dimitarshenkov]

аз още не съм ре6ил преди6ния си проблем,не съм инсталирал заради това и приложения за да кажа минималната латентност на аудио интерфейса, при която нямам припуквания и други артефакти.

[LOE]

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

 

това което ми направи впечатление е че много хора успяват да закрепят нещата, слагат стари биоси и драйвери и прочее, и изведнъж, от самосебе си нещата пак се прецакват

 

направих един бърз опит - както си ми показваше примерно 10-20 с пикове от време на време, забранявам лан картата и латентноста пада с няколко микросекунди, после обаче, като пусна обратно лан картата, и системата се върне в състоянието в което е била, латентноста скача стабилно - отива към 600 и не слиза по ниско - което също е странно, защо латентноста се качва толкова много след като преди със същия хардуер е била много по ниска?

 

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

 

аз като програмистко чадо... баща ми е казвал "ако работи не го пипай", в общи линии за мен е по важно системата ми да работи добре от това какво показва дадена програма

[niki123bg]

Не виждам какво повече да се каже по въпроса, а и явно това все още не е на дневен ред за питащият.

 

Колкото до това колко пътчеки и с какви ефекти би успял да претовариш процесора и да започне да губи буфери - това е основно функция на скоростта на процесора и по-бързият процесор при еднакви други условия винаги би се справял по-добре.

 

DPC latency е друга тематиката - тя оказва влияние независимо от броя тракове - т.е. можеш да имаш само 1 пътечка, но ако имаш сериозни проблеми с DPC latency трудно ще можеш да записваш при ниски латентности, но тъй като ползваш USB аудио интерфейс, при теб такива ниски латентности са невъзможни, така че не те касае - отдъхни си

[dimitarshenkov]

може6 ли по подробно да кажеш защо предпо4иташ Q9300

[niki123bg]

Q9300 е с 10 - 15% по-бърз от Q6600

Q9300 e 45 nm и грее по-малко, иска по-малко охлаждане, съответно при еднакъв охладител - по-ниски обороти на вентилатора и по-малко шум

 

Разликата в цената е малка, имайки в предвид разликата в поколенията - Q9300 е около 20% по-скъп което поне за мен се оправдава в някаква степен от по-високата производителност и по-малкото греене - склонен съм да дам повече, за да получа повече.

 

Но това е базирано на моите лични предпочитания (т.е. не желая да овърклоквам процесори, искам минимален шум и т.н.), а и ти вече си направил своя избор, така че не знам с какво ти помага това.

 

Процесорът не е толкова важен (10 - 15% повече производителност е малка разлика), важното е системата да работи като цяло добре, да е стабилна и предсказуема.

[dimitarshenkov]

но е с по-малко ке6 и сравнително не доказал се за сега..?

Редактирано Ноември 15, 2008 от dimitarshenkov

[dimitarshenkov]

но е с по-малко ке6 и сравнително не доказал се за сега..?

 

има ли проблем да клокна с програма имам ка4ена една и си работи добре за сега,при запис на вокали просто ще намаля на наи=ниска скорост процеса и вентилатора става мн тих,като рендвам пак клоквам и така..

[niki123bg]

Q6600 има 8 MB L2 кеш, а Q9300 има 6 MB L2 cache, само че има още една подробност - при по-новата архитектура на Q9300 латентността на кеша е по-ниска и като резултат разликата от 2 MB не оказва влияние. Резултатът от тестове е 15% по-висока производителност за Q9300 (при реални приложения - енкодинг, архивиране и т.н., както и при синтетични тестове).

 

В същност ако трябва да разглеждаме в детайли ситуацията, ето как изглежда:

 

Q6600 е на 2.4 GHz

Q9300 е на 2.5 GHz

 

Разликата в скоростта е само 4% по-висока честота за Q9300, а разликата в тестовете e 15% по-висока производителност за Q9300, което показва че новата архитектура е значително по-добра и в същност ползата идва не от разликата в скоростта на процесорите, а от по-новата архитектура.

 

Само не мога да разбера - изпитваш ли ме нещо, опитваш се да си оправдаеш покупката или какво по-точно?

[niki123bg]

има ли проблем да клокна с програма имам ка4ена една и си работи добре за сега,при запис на вокали просто ще намаля на наи=ниска скорост процеса и вентилатора става мн тих,като рендвам пак клоквам и така..

 

Ами пробвай и си прецени или да вадим отново кристалните топки?

[dimitarshenkov]

добре по друг начин казано какво ти е мнението за този тип програми или няма6 наблюдения?

Редактирано Ноември 15, 2008 от dimitarshenkov

[niki123bg]

Нямам си и бегла представа - от доста години не овърклоквам машините си, по времето когато го правех всички промени се правеха с джъмпери. LOE предполагам ще сподели по въпроса за овърклокващ софтуер.

 

Сериозно ли няма да ти стигнат 4 ядра по 2.4 GHz?

[dimitarshenkov]

мн се надявам да ми стигнат просто мраза да чакам рендването

Редактирано Ноември 15, 2008 от dimitarshenkov

[dimitarshenkov]

При разединяването на екранировката от единия край няма ли да се загубят ка4ествата на кабела?

Редактирано Ноември 15, 2008 от dimitarshenkov

[niki123bg]

Ако става въпрос за балансирани кабели - не. Погледни в темите отгоре - има тема за направа на кабели ("Kaк да сглобим аудио кабел"), от там ще стигнеш до една статия която доста подробно се занимава с тези въпроси.

 

До сега можеше хиляда пъти да пробваш всичките тези нещица за които питаш и да си отговориш сам на въпросите.