IRQ dedicato

[virman71]

Buongiorno a tutti,vi chiedo aiuto riguardo un problema nel dedicare l'IRQ alla mia E-MU 1212mpci-e.Vedo dalla schermata che la scheda audio ha un irq 16 condiviso con altre applicazioni.Posso disattivare le altre applicazioni senza creare danni oppure esiste un altra procedura?Ho una mobo Gigabyte h67ma-ud2h-b3.
L'elenco delle applicazioni con irq condiviso dalla emu:
adattatore pci standard da pci a pci
intel(r)6 series/c200 series chipset family pci express root port1-1c10
intel(r)6 series/c200 series chipset family pci express root port5-1c18
intel(r) hd graphics family
xeon E3-1200/2nd generation intel(r) core(tm) processor family PCI express root port-0101

[bibo01]

I pci express root port li puoi lasciare.
Lo Xeon lo puoi disabilitare.
Se hai disabilitato l'accelerazione video, puoi togliere anche Intel HD graphics.

[giannicimbalo]

In realtà il mio sistema nlite non mi consente di cambiare l'RQ della Juli@..in comune..vado a memoria..con quelche componente "di sistema"..Ah..la scheda è su PCI 1

[virman71]

..Grazie per la risposta....provvederò immediatamente

[bibo01]

In realtà il mio sistema nlite non mi consente di cambiare l'RQ della Juli@..in comune..vado a memoria..con quelche componente "di sistema"..Ah..la scheda è su PCI 1

Non esiste problema reale perché, come nel caso di virman, sono delle risorse di sistema e non delle periferiche in uso.

[Totocellux]

Come già espresso in precedenza, non è mia volontà intromettermi nell'asserire o dissentire alcunché sulla bontà delle scelte utilizzate per giungere alla qualità audio desiderata, ovvero tramite queste particolari ottimizzazioni che sono utilizzate allo scopo.

Che ben vengano se il fine giustifica i mezzi

Ma è d'obbligo rammentare come tutto l'apparato che porta questi benefici è alla fine pur sempre un vero e proprio pc, con tutta la sua componentistica a bordo

Disabilitare o disattivare un dispositivo potrebbe, anche solo sfortunatamente, divenire rischioso in quanto è con l'hardware a disposizione che il s.o. deve far sempre quadrare i conti.

Asserire che non esiste un problema reale tagliando a destra e manca delle risorse e/o dei dispositivi sol perché l'esperienza ci dice che non siano generalmente/attualmente utilizzati, potrebbe non rispecchiare completamente in seguito la realtà dei fatti, o meglio rispecchiarla solo in parte.


Mi spiego


Fintantoché quel dispositivo hardware a cui viene segato radicalmente il supporto verso il s.o., non viene colpito da una anomalia, potrebbe ancora andare bene (come certamente va).

Forse ci si dovrebbe chiedere anche cosa potrebbe accadere al momento di generarsi una problematica o peggio un malfunzionamento a cui quel dispositivo era demandato il controllo/gestione.
In quel caso potrebbero insorgere anche gravi problemi.

Passo ad un esempio concreto e volutamente estremo, proprio per esplicitare meglio e allo stesso modo ricordare che esistono anche tutta una serie di altri possibili eventi di rilevanza intermedia.

Ho notato che in uno dei thread di ottimizzazione è stato consigliato di disattivare in Windows XP uno dei dispositivi che in determinate circostanze è senz'altro tra i più vitali del sistema, il PIC:

Programmable interrupt controller

In una situazione analoga con la comunicazione da/verso il PIC interrotta, finché il s.o. riuscirà a gestire gli eventi e le richieste normalmente generate dai programmi verso i vari dispositivi di I/O collegati al pc (richieste sincrone di tipo software), tutto filerà senz'altro liscio per come avrete avuto esperienza finora.

Mi sento però in dovere di far notare invece che al momento di generarsi una richiesta in ordine ad una grave problematica di ordine hardware e quindi di tipo asincrona NMI (Non Maskable Interrupt), questa andrà a interrompere immediatamente ed incondizionatamente le operazioni della cpu.

In una situazione standard con architettura hardware x86/x64 ed una architettura software di tipo Interrupt Driven come Windows, gestita sostanzialmente tramite meccanismi Plug and Play, quando il PIC (nei pc moderni si tratta in realtà di un Advanced PIC, e risiede nel SouthBridge) verificherà l'esistenza di una anomalia tale da dover interrompere immediatamente le operazioni della cpu, avrà modo di comunicare nel contempo anche al s.o., ad esempio di interrompere le operazioni di scrittura su disco.

Qualora il dispositivo (quindi la comunicazione) sia stata precedentemente disattivata, accadrà nei casi più sfortunati che Windows tenterà fino all'ultimo istante di scrivere su disco ciò di cui ha necessità, e non permetterà al braccio testine di portarsi in zona parcheggio in tempo utile.

Ovviamente questo è uno scenario solo probabile e i cui danni potrebbro essere +o- gravi ma ecco, è solo una delle situazioni possibili di cui comunque è bene sapere l'esistenza

Disabilitare la comunicazione tra s.o. e dispositivi di sistema facenti parte dell'architettura hardware dei pc alla fine non sempre rappresenta la scelta migliore.

Spero in qualche modo di esservi d'aiuto

[bibo01]

Totocellux,

i tuoi avvertimenti sono assolutamente ben accetti

Comunque, in un sistema chiuso come cMP² molti dispositivi installati dal SO sono inutili, anzi a volte costituiscono un elemento di rallentamento. Non è un caso che un cMP² possa funzionare bene con soli 256MB di RAM.

[Totocellux]

Totocellux,
i tuoi avvertimenti sono assolutamente ben accetti
[...]

di questo ne sono contento e consapevole

[...]
Comunque, in un sistema chiuso come cMP² molti dispositivi installati dal SO sono inutili, anzi a volte costituiscono un elemento di rallentamento. Non è un caso che un cMP² possa funzionare bene con soli 256MB di RAM.

stando alle vostre esperienze, questo può essere definito vero

La mia, ripeto, non vuole essere una critica al sistema in sé in quanto, se sta bene a chi felicemente lo usa, non può che stare bene anche a me

Il concetto alla base è che trattandosi di un sistema informatico che vive di hardware e di software, è mia opinione che parlarne non debba rappresentare uno spunto finalizzato al puro confronto di idee, giuste o sbagliate.

Piuttosto sono convinto che debba essere interpretato come un viatico al fine di una maggiore comprensione dei meccanismi che lo governano, in previsione anche dell'apporto, perché no, di ulteriori future modalità di sviluppo, possibilmente alla luce di un produttivo porting su Windows 7

[audiodan]

Totocellux grazie di esistere!
Questa è la controparte "colta" informatica che serve ( oltre a san bibo da bali, peccato che non si chiami nicola: ve lo immaginate nicola di bali? Sarebbe stato perfetto!!), sia per non fare cose che rendano i sistemi instabili o crashabili sia per fare ciò che noi tutti vogliamo, ovvero ascoltare la musica al meglio.
Io non credo, in cuore mio, che un sistema basato su seven sia performante quanto il cMP2 su XPpro, fin'ora i miei tentativi di comparazione sono finiti con disfatte ( intese in senso audiofilo puro, ovvero in pratica piccoli ma indubbi vantaggi) dalle quali emergeva sempre cMP2 come vincitore.
Ma poichè sono uno fiducioso di base non dispero di vedere superare quello che, a tutt'oggi, ritengo il miglior sistema di riproduzione della musica che mi sia passato tra le mani. Sarà Eight che riuscirà?
Intanto, per tornare al tema del thread, posso dire di non aver mai applicato la disattivazione del PIC e di non averne mai sentito la mancanza. Sugli IRQ, essendomi votato ben presto alla PCI-E, ho allegramente sorvolato di occuparmene minimamente, soprattutto dopo qualche bella schermata blu che risale proprio agli inizi della mia esperienza. Insomma anche lo spirito critico del "non capisco bene quindi non faccio" porta a buoni risultati, anche se inconsapevoli, tanto c'è sempre tempo per imparare ed effettuare modifiche successivamente.

[bibo01]

Queste sono le impressioni del nostro Crazy M. con cMP² vs Seven :
http://www.nexthardware.com/forum/cm...tml#post793012

...e queste quelle di cics riguardo Seven:
http://www.nexthardware.com/forum/cm...tml#post804197