Headshot-Deluxe
Cadet 3rd Year
- Registriert
- Aug. 2010
- Beiträge
- 54
alle GTX 460 verhalten sich so, meine HD5850 taktet auch etwas hoch im Dual Betrieb .
Consystor
Lieutenant
- Registriert
- Juli 2008
- Beiträge
- 607
Hö?
Das Problem mit der DPC Latency hat doch nichts mit der Sache zu tun, dass die Karte (mit dem älteren F1 BIOS) im Dual Betrieb nicht runtertaktet...
Ersteres Prob mit DPC liegt wohl am Treiber und Nvidia kümmert sich drum.
Zweiteres liegt am BIOS der GigaByte und wurde mit der P03-Taktdomäne im neuen BIOS (F2) behoben (wobei es angeblich aber nicht richtig funktioniert - so oder so soll bald ein neues erscheinen).
Das Problem mit der DPC Latency hat doch nichts mit der Sache zu tun, dass die Karte (mit dem älteren F1 BIOS) im Dual Betrieb nicht runtertaktet...
Ersteres Prob mit DPC liegt wohl am Treiber und Nvidia kümmert sich drum.
Zweiteres liegt am BIOS der GigaByte und wurde mit der P03-Taktdomäne im neuen BIOS (F2) behoben (wobei es angeblich aber nicht richtig funktioniert - so oder so soll bald ein neues erscheinen).
A
Afrokaracho
Gast
mhm, hab mir die gigabyte am sa bestellt und eier selbst auf nem p35 mobo von gigabyte rum. ma schaun obs probleme gibts.
S
Silentfreak07
Gast
Gibt wieder neues von Gigabyte Zitat GB-Support:
...so viel ich das weiß, tritt das problem bei allen herstellern auf, wenn das board älter vom chipsatz her ist als ein P55 oder X58
hatte heute nochmal deswegen telefoniert und hoffe, dass ich da morgen genaueres erfahre...
Na super. Hoffentlich fixt Nvidia dies mit einem neuen Bios
...so viel ich das weiß, tritt das problem bei allen herstellern auf, wenn das board älter vom chipsatz her ist als ein P55 oder X58
hatte heute nochmal deswegen telefoniert und hoffe, dass ich da morgen genaueres erfahre...
Na super. Hoffentlich fixt Nvidia dies mit einem neuen Bios
Consystor
Lieutenant
- Registriert
- Juli 2008
- Beiträge
- 607
Also, dass es mit Boards anderer Hersteller ebenfalls auftritt habe ich hier bereits geschrieben. Das mit <P55 ist auch schon seit paar Tagen bekannt. Zudem schrieb irgendwo einer mit ner 9600, dass es auch bei ihm auftritt. Ansonsten ist das Prob nur bei den GTX460 bekannt...
Wenn man keine echten Probs hat, dann kann man dieses "Problem" auch erstmal getrost ignorieren. Wieso hast Du denn bei GigaByte angerufen?
Wenn man keine echten Probs hat, dann kann man dieses "Problem" auch erstmal getrost ignorieren. Wieso hast Du denn bei GigaByte angerufen?
Consystor
Lieutenant
- Registriert
- Juli 2008
- Beiträge
- 607
Ja, das wüsste ich auch gerne! Diese Frage kann bisher wohl so recht noch keiner beantworten. Aber es gibt welche, die meinen, dass gewisse Probs mit Soundunterbrechnungen nur im Zusammenhang mit ihrer GTX460 auftauchen und diese Leute haben hohe DPC Latencies.
Doch es gibt natürlich auch welche, die Soundprobs haben und keine GTX460.
Das Problem muss aber auf jeden Fall gelöst werden, weil es sehr schlecht ist, wenn bestimmte work items (Aufgaben) in der DPC queue (Warteschlange) eine unzulässig lange CPU-Zeit in Anspruch nehmen. Es gibt soweit ich weiß pro CPU (kern) genau eine solche DPC queue in der die "Aufgaben" nicht nur eines Treibers (wie des Nvidia Treibers) eingefügt werden, sondern auch anderen Treiber (wie z.B. des Soundkartentreibers). Wenn also ein Treiber mit seinen Aufgaben eine DPC queue blockiert, dann werden die Aufgaben der anderen Treiber in der queue nicht abgearbeitet und ggf. verworfen, was sich dann z.B. mit Stottersound bemerkbar machen kann.
Ich glaube man kann diese DPC queues mit den Work Queues im Linux kernel vergleichen.
Als ich einmal einen Linux-Netzwerktreiber geschrieben habe, habe ich in work items gepollt, was man nicht tun sollte. Dies führte dazu, dass die work items ab und zu lange abgearbeitet wurden und die queue somit blockiert haben. Es wurden dann Datenpakete verworfen und das gesamte System wurde sogar bei hohen Übertraungen so instabil, dass man sich nicht einmal mehr anmelden konnte.
Bei den DPC Latencys, die derzeit auftreten ist das wohl eher unwahrscheinlich, doch man muss es in den Griff bekommen, bevor es zu einem echten Problem wird und deshalb muss Nvidia, nachdem man anscheinend festgestellt hat, dass es wohl am Treiber liegt, der Ursache nachgehen und das Problem lösen und zwar unabhängig davon, ob irgendwelche Leute ihre Soundprobleme nun dadurch haben oder nicht.
Grüße
Doch es gibt natürlich auch welche, die Soundprobs haben und keine GTX460.
Das Problem muss aber auf jeden Fall gelöst werden, weil es sehr schlecht ist, wenn bestimmte work items (Aufgaben) in der DPC queue (Warteschlange) eine unzulässig lange CPU-Zeit in Anspruch nehmen. Es gibt soweit ich weiß pro CPU (kern) genau eine solche DPC queue in der die "Aufgaben" nicht nur eines Treibers (wie des Nvidia Treibers) eingefügt werden, sondern auch anderen Treiber (wie z.B. des Soundkartentreibers). Wenn also ein Treiber mit seinen Aufgaben eine DPC queue blockiert, dann werden die Aufgaben der anderen Treiber in der queue nicht abgearbeitet und ggf. verworfen, was sich dann z.B. mit Stottersound bemerkbar machen kann.
Ich glaube man kann diese DPC queues mit den Work Queues im Linux kernel vergleichen.
Als ich einmal einen Linux-Netzwerktreiber geschrieben habe, habe ich in work items gepollt, was man nicht tun sollte. Dies führte dazu, dass die work items ab und zu lange abgearbeitet wurden und die queue somit blockiert haben. Es wurden dann Datenpakete verworfen und das gesamte System wurde sogar bei hohen Übertraungen so instabil, dass man sich nicht einmal mehr anmelden konnte.
Bei den DPC Latencys, die derzeit auftreten ist das wohl eher unwahrscheinlich, doch man muss es in den Griff bekommen, bevor es zu einem echten Problem wird und deshalb muss Nvidia, nachdem man anscheinend festgestellt hat, dass es wohl am Treiber liegt, der Ursache nachgehen und das Problem lösen und zwar unabhängig davon, ob irgendwelche Leute ihre Soundprobleme nun dadurch haben oder nicht.
Grüße
S
Silentfreak07
Gast
Hab natürlich nicht bei Gigabyte angerufen 
verfolge nur den Threat im Gigabyte Forum mit. Da bekommt man alles aus erster Hand von Gigabyte (siehe Link erste Seite). Die Probleme sind übrigens mit der Karte auf vielen Mainboards reproduzierbar und mittlerweile sind auch AMD-Boards betroffen. Ein stabiler 2d-Modus wäre halt schon nicht schlecht.
Die Frage ist, kann da ganze über neue Nvidia Treiber gefixt werden oder muss ein neues Bios aufgespielt werden (mit dem unter umständen der 2d-Modus abgeschalten wird).
verfolge nur den Threat im Gigabyte Forum mit. Da bekommt man alles aus erster Hand von Gigabyte (siehe Link erste Seite). Die Probleme sind übrigens mit der Karte auf vielen Mainboards reproduzierbar und mittlerweile sind auch AMD-Boards betroffen. Ein stabiler 2d-Modus wäre halt schon nicht schlecht.Die Frage ist, kann da ganze über neue Nvidia Treiber gefixt werden oder muss ein neues Bios aufgespielt werden (mit dem unter umständen der 2d-Modus abgeschalten wird).
Evileddie79
Lieutenant
- Registriert
- März 2004
- Beiträge
- 747
habe die gigabyte gtx460 oc mit 1Gb in einem Gigabyte P35 Board stecken.Mir ist bisher nix negatives aufgefallen.wie genau würde sich die sache denn bemerkbar machen?
Könnte mir jemand evtl. kurz erklären was genau mit DCP-Latency gemeint ist.
Danke
Könnte mir jemand evtl. kurz erklären was genau mit DCP-Latency gemeint ist.
Danke
Consystor
Lieutenant
- Registriert
- Juli 2008
- Beiträge
- 607
@Evileddie79
Wenn Du bisher kein Problem bemerkt hast, dann brauchste Dir keine weiteren Gedanken machen. Falls Du aber trotzden gerne messen willst, ob das Problem besteht und sich nur nicht bemerkbar macht, kannst Du es mit einem Programm testen. Dazu reicht es aber nicht das Programm zu starten und die Ausgabe anzusehen. Man muss mehr tun.
Wie genau Du vorgehen musst erfährst Du hier.
Zu Deiner Frage, was eine DPC Latency ist - sehr grob im Zusammenhang erklärt:
Wenn eine Hardwarekomponente, wie z.B. eine Netzwerkkarte, ein Datenpaket empfängt, so muss dieses vom Betriebssystemkern "abgeholt" und an die entsprechende Anwendung (z.B. Browser) weitergeleitet werden. Dazu verursacht die Netzwerkkarte einen Interrupt und unterbricht damit das Programm, welches von der CPU gerade ausgeführt wird. Nach dieser sogenannten Unterbrechungsanforderung wird von der CPU eine Unterbrechungsroutine ausgeführt, die im Treiber der Netzwerkkarte programmiert ist.
Diese Routine kümmert sich dann darum, dass das empfangene Datenpaket aus dem Speicher der Netzwerkkarte ausgelesen und in einen Puffer im Arbeitsspeicher gespeichert wird. Dieser Puffer muss dann an den Betriebssystemkern weiter gegeben werden, welcher den Header (Kopf) des Datenpakets einliest, um zu prüfen, ob die Daten korrekt empfangen wurden etc. und um diese dann an die zugehörige Anwendung weiterleiten zu können.
Der Puffer wird aber von der Unterbrechungsroutine nicht direkt an den Betriebssystemkern weitergegeben, weil die genannten Aufgaben eine "längere Zeit" in Anspruch nehmen würden. In dieser Zeit kann dann keine andere Unterbrechungsaufforderung bearbeitet werden. Somit würden Interrupts anderer Geräte (wie z.B. einer Soundkarte) nicht abgearbeitet werden können, die aber schnellstmöglich abgearbeitet werden müssen, weil sie zeitkritisch sind.
Anstatt also den Puffer mit dem empfangenen Datenpaket an den kernel weiterzugeben und auf dessen Verarbeitung zu warten, reiht die Unterbrechungsroutine der Netzwerkkarte diese Aufgabe in die DPC queue (DPC Schlange) ein. Dies erfolgt in sehr kurzer Zeit, sodass die gesamte Unterbrechungsroutine sehr kurz ist und die CPU fortfahren kann.
Wenn die CPU dann schlussendlich alle anstehenden Interrupts abgearbeitet hat, werden vom Dispatcher des Kerns die Aufgaben in der DPC queue abgearbeitet, bevor er mit der Ausführung des unterbrochenen Programms fortfährt. Dies geschieht genau der Reihenfolge nach, wie die Aufgaben in die DPC queue eingereiht worden sind. (Also die Aufgaben der Netzwerkkarten, Soundkarten, Grafikkarten etc.)
Wenn nun z.B. die Aufgaben der Grafikkarte eine unzulässig lange Zeit in Anspruch nehmen, können andere Aufgaben (der Netzwekkarte, Soundkarte etc.) nicht schnell genug abgearbeitet werden.
Die Zeitspanne vom Einreihen der Aufgabe durch die jeweilige Unterbrechungsroutine in die DPC queue bis zu ihrer Abarbeitung nennt man DPC Latency. Wenn also eine Aufgabe in der DPC queue die anderen lange blockiert, wird deren DPC Latency sehr groß.
Die DPC Latency kann man mit dem DPC Latency Checker messen. Ist sie zu hoch, dann ist es also ein Indiz dafür, dass womöglich ein Treiber fehlerhaft programmiert ist oder ein anderes Problem besteht.
Bei der Netzwerkkarte kann es dann zu Datenverlusten kommen, wenn also die Datenpakete nicht schnell genug abgeholt werden und der interne Speicher der Netzwerkkarte vollläuft, wobei das nicht unbedingt zu Fehlern führen muss, die man als Anwender bemerkt, weil die Datenpakete je nach verwendetem Protokoll automatisch erneut angefordert werden können. Bei einer Soundkarte kann es aber z.B. dazu führen, dass der Datenstrom immer wieder abbricht, was zu Tonaussetzern führen kann.
Ich hoffe, ich habe das verständlich genug erklärt.
Grüße
Wenn Du bisher kein Problem bemerkt hast, dann brauchste Dir keine weiteren Gedanken machen. Falls Du aber trotzden gerne messen willst, ob das Problem besteht und sich nur nicht bemerkbar macht, kannst Du es mit einem Programm testen. Dazu reicht es aber nicht das Programm zu starten und die Ausgabe anzusehen. Man muss mehr tun.
Wie genau Du vorgehen musst erfährst Du hier.
Zu Deiner Frage, was eine DPC Latency ist - sehr grob im Zusammenhang erklärt:
Wenn eine Hardwarekomponente, wie z.B. eine Netzwerkkarte, ein Datenpaket empfängt, so muss dieses vom Betriebssystemkern "abgeholt" und an die entsprechende Anwendung (z.B. Browser) weitergeleitet werden. Dazu verursacht die Netzwerkkarte einen Interrupt und unterbricht damit das Programm, welches von der CPU gerade ausgeführt wird. Nach dieser sogenannten Unterbrechungsanforderung wird von der CPU eine Unterbrechungsroutine ausgeführt, die im Treiber der Netzwerkkarte programmiert ist.
Diese Routine kümmert sich dann darum, dass das empfangene Datenpaket aus dem Speicher der Netzwerkkarte ausgelesen und in einen Puffer im Arbeitsspeicher gespeichert wird. Dieser Puffer muss dann an den Betriebssystemkern weiter gegeben werden, welcher den Header (Kopf) des Datenpakets einliest, um zu prüfen, ob die Daten korrekt empfangen wurden etc. und um diese dann an die zugehörige Anwendung weiterleiten zu können.
Der Puffer wird aber von der Unterbrechungsroutine nicht direkt an den Betriebssystemkern weitergegeben, weil die genannten Aufgaben eine "längere Zeit" in Anspruch nehmen würden. In dieser Zeit kann dann keine andere Unterbrechungsaufforderung bearbeitet werden. Somit würden Interrupts anderer Geräte (wie z.B. einer Soundkarte) nicht abgearbeitet werden können, die aber schnellstmöglich abgearbeitet werden müssen, weil sie zeitkritisch sind.
Anstatt also den Puffer mit dem empfangenen Datenpaket an den kernel weiterzugeben und auf dessen Verarbeitung zu warten, reiht die Unterbrechungsroutine der Netzwerkkarte diese Aufgabe in die DPC queue (DPC Schlange) ein. Dies erfolgt in sehr kurzer Zeit, sodass die gesamte Unterbrechungsroutine sehr kurz ist und die CPU fortfahren kann.
Wenn die CPU dann schlussendlich alle anstehenden Interrupts abgearbeitet hat, werden vom Dispatcher des Kerns die Aufgaben in der DPC queue abgearbeitet, bevor er mit der Ausführung des unterbrochenen Programms fortfährt. Dies geschieht genau der Reihenfolge nach, wie die Aufgaben in die DPC queue eingereiht worden sind. (Also die Aufgaben der Netzwerkkarten, Soundkarten, Grafikkarten etc.)
Wenn nun z.B. die Aufgaben der Grafikkarte eine unzulässig lange Zeit in Anspruch nehmen, können andere Aufgaben (der Netzwekkarte, Soundkarte etc.) nicht schnell genug abgearbeitet werden.
Die Zeitspanne vom Einreihen der Aufgabe durch die jeweilige Unterbrechungsroutine in die DPC queue bis zu ihrer Abarbeitung nennt man DPC Latency. Wenn also eine Aufgabe in der DPC queue die anderen lange blockiert, wird deren DPC Latency sehr groß.
Die DPC Latency kann man mit dem DPC Latency Checker messen. Ist sie zu hoch, dann ist es also ein Indiz dafür, dass womöglich ein Treiber fehlerhaft programmiert ist oder ein anderes Problem besteht.
Bei der Netzwerkkarte kann es dann zu Datenverlusten kommen, wenn also die Datenpakete nicht schnell genug abgeholt werden und der interne Speicher der Netzwerkkarte vollläuft, wobei das nicht unbedingt zu Fehlern führen muss, die man als Anwender bemerkt, weil die Datenpakete je nach verwendetem Protokoll automatisch erneut angefordert werden können. Bei einer Soundkarte kann es aber z.B. dazu führen, dass der Datenstrom immer wieder abbricht, was zu Tonaussetzern führen kann.
Ich hoffe, ich habe das verständlich genug erklärt.
Grüße
Zuletzt bearbeitet:
Evileddie79
Lieutenant
- Registriert
- März 2004
- Beiträge
- 747
Vielen Dank für die ausführliche erklärung.
Tonaussetzer habe ich noch nicht bemerkt.
Ist ea aber dann ein Problem des Grafikkarten Bios, des Nvidia Grafikkartentreibers oder des Mainboard bios?
Wie oder wer kann/müsste dieses dann beheben?
Und wie sollte der DPC Latency Check im besten Fall aussehen?
Habe meistens alles grün, aber ab und zu roten spitzen.
Tonaussetzer habe ich noch nicht bemerkt.
Ist ea aber dann ein Problem des Grafikkarten Bios, des Nvidia Grafikkartentreibers oder des Mainboard bios?
Wie oder wer kann/müsste dieses dann beheben?
Und wie sollte der DPC Latency Check im besten Fall aussehen?
Habe meistens alles grün, aber ab und zu roten spitzen.
Zuletzt bearbeitet:
S
Silentfreak07
Gast
Was genau die Ursache des Problems ist, steht momentan noch offen. Hoffe es geht einfach durch neue Nvidia Treiber. Graka-Bios flash ich sehr ungern. Am besten den Link auf das Gigabyte Forum weiterverfolgen. Da gibts die Entwicklung direkt von Gigabyte.
Es spricht aber bisher einiges dafür, dass es sich um ein Treiberproblem handelt, da das Problem auch bei Karten anderer Hersteller auftritt (Sparkle habe ich z.B. gelesen).
Aber wenn du sowieso kein Problem hast, würde ich es einfach auf sich beruhen lasse
.
Es spricht aber bisher einiges dafür, dass es sich um ein Treiberproblem handelt, da das Problem auch bei Karten anderer Hersteller auftritt (Sparkle habe ich z.B. gelesen).
Aber wenn du sowieso kein Problem hast, würde ich es einfach auf sich beruhen lasse
.Evileddie79
Lieutenant
- Registriert
- März 2004
- Beiträge
- 747
ok,
das Thema im Gigabyte Forum verfolge ich schon länger.Habe wie schon erwähnt ab und zu rote spitzen.Aber ich merke sonst nix.
Habe auch schon gelesen das die Gigabyte Karte angeblich auf einigen Mainboards nicht laufen soll.Aber warum weiß ich nicht.
Danke
das Thema im Gigabyte Forum verfolge ich schon länger.Habe wie schon erwähnt ab und zu rote spitzen.Aber ich merke sonst nix.
Habe auch schon gelesen das die Gigabyte Karte angeblich auf einigen Mainboards nicht laufen soll.Aber warum weiß ich nicht.
Danke
St3iner
Ensign
- Registriert
- Mai 2008
- Beiträge
- 197
hi
ich wollte mir eigentlich auch ne gtx460 kaufen und pegelte mich auf die gigabyte ein.
kann mir bitte jemand möglichst einfach erklären was dieses "DPC-Latency" problem für auswirkungen hat bzw wie es sich im altag am pc zeigt ?
des weiteren habe ich leider nen älteres MSI board,bei meinem glück wirds damit bestimmt probleme geben ^^
ich wollte mir eigentlich auch ne gtx460 kaufen und pegelte mich auf die gigabyte ein.
kann mir bitte jemand möglichst einfach erklären was dieses "DPC-Latency" problem für auswirkungen hat bzw wie es sich im altag am pc zeigt ?
des weiteren habe ich leider nen älteres MSI board,bei meinem glück wirds damit bestimmt probleme geben ^^
S
Silentfreak07
Gast
Kurz und knapp: Soundaussetzern und Hängern beim arbeiten
Werde übrigens bei meiner Vapor-X bleiben, da beim X38 Chipsatz kein PCI-Express 2.0 mit Nvidia Karten funktioniert (geblockt durch Nvidia-Treiber, warum weis keiner).
Warte lieber auf die 6000-Reihe vom AMD.
Werde übrigens bei meiner Vapor-X bleiben, da beim X38 Chipsatz kein PCI-Express 2.0 mit Nvidia Karten funktioniert (geblockt durch Nvidia-Treiber, warum weis keiner).
Warte lieber auf die 6000-Reihe vom AMD.
