Gigabyte Boards and DPC Latency

[Blazer7]

Originally posted by: beray
The more powerful your computer, the more bandwidth you have, the less sensitive your are to DPC latencies = lost of bandwidth.

The more effective bandwidth control method for you to make things obvious is --> underclock the processors, remove one of your dual-channel memory sticks, and underclock the left over memory.

This will make your computer more sensitive to DPC latencies.

All I get with the forceware betas is nothing but continuous spikes. In addition to audio/video playback I use Virtual PC extensively and occasionally Nero. Sometimes iTunes, VPC and Nero are working simultaneously. I've noticed some DPC spikes above my normal with Nero and VPC running but nothing ever stutters (normal=continuous spikes of 2500-3100µs with hacked forceware betas+nV PhysX drivers). Since I experience no stuttering I guess that I shouldn't complain about this but it makes me wonder on how accurate the DPC checker is and what are the actual effects of high DPC latencies on my system.

This is for my system only and by this I'm not suggesting that the DPC checker is not working. But it leaves some questions.

Your advise to downclock cpu, mem and go to single channel makes sense. I'll give it a shot as soon as I get the chance and will report back if I find anything worth reporting.

 

[JonLB]

Originally posted by: semaj1286
Well Gigabyte's support site sent me a BIOS to try, but it didn't work for me. Here's the link if you want to try it, JonLB. Hopefully it works for someone. Also, I noticed no negative issues when switching to this BIOS from the others.

http://ggts.gigabyte.com.tw/Fi...st/623799/ma78gs2h.zip

Tried that, and still no go....

 

[fimpenb]

Beta BIOS v. F4h for GA-EP35-DS4 rev. 2.1: EP35DS4.F4H
Same results as F4b regarding the DPC latency. I don't really know what this version fixes. Maybe the problem of not being able to change CPU voltage, haven't checked.

 

[Kaneda0]

Hi, i think i have good news, i had the same DPC latency problem with my Gigabyte GA-P35-DS3 Board (glitchy sound and performance issues) and i searched for a solution for about 2 Weeks now. I think i have it. There is a faulty Driver in Vista which generates a LOT of DPCs, when sound and/or Video is played. The driver is the one for the MMCSS service, which has the function to reduce gliching ( yeah, i know, that service does a BAD job ) To deactive it, you have to follow this procedure (BIG thanks to Courtney on http://blogs.technet.com/markr...7/1833290.aspx#1841934 !!!! ):

my first thought was to disable the MMCS service, but the Windows Audio service is dependent on it.

So I ran regedit, and changed the key

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Audiosrv\DependOnService

Just remove MMCS from that key in the list, and set MMCS to disabled in services, then reboot.

As soon as I rebooted I was able to copy files at 40mb/s+ while listening to audio

-Courtney

I still have light DPC lag, but it's harmless because the numbers of requests don't increase anymore, when i'm using sound and graphics.

I hope this helps, good luck !

 

[VirtualLarry]

Originally posted by: beray

Originally posted by: VirtualLarry
No, they're not IRQ-driven, not directly. Hardware IRQ handlers are IRQ driven, DPC calls are scheduled by the scheduler. They have a higher priority than all other tasks, EXCEPT for the hardware IRQ handlers.

The idiot version --> All software IRQ handlers (schedulers) have lower priority than hardware IRQ handlers (schedulers). All IRQ handlers had higher priority than anything else.

Originally posted by: VirtualLarry
What happens is that a hardware IRQ happens, which, if no other hardware IRQ handler is executing, then the hardware IRQ handler for that IRQ executes, and that hardware IRQ handler schedules a DPC to be executed (which is like a "second half" IRQ handler), which it normally happens after the IRQ handler completes, although it can be further delayed by additional back-to-back hardware IRQs firing. The reason for having DPC calls scheduled like this is so that the hardware IRQs are not tied up for too long. That's IRQ latency - the time between hardware IRQ handler completion. DPC latency depends on the scheduling, which in turn depends on the IRQ latency, but they are not the same thing, because DPCs can be deferred multiple times, because of back-to-back hardware interrupts.

The idiot version --> All time critical high priority used hardware IRQ handlers (schedulers), all less time critical used software IRQ handlers (schedulers).

Originally posted by: VirtualLarry
PCI latency is another thing entirely, which has to do with the hardware signalling protocol of the PCI bus. Every agent on the bus can occupy the bus for a maximum number of clock cycles, which is the PCI latency number. So that means that the next PCI agent wanting to gain control of the bus has to wait at most PCI_LATENCY number of cycles.

The idiot version --> Old PCI devices used hardware IRQ handlers (schedulers) exclusively, new PCI devices used both software IRQ handlers (schedulers) and hardware IRQ handlers (schedulers).

Originally posted by: VirtualLarry
Do I need to explain DRAM latency too to you?

Would that be possible in the idiot version?

My god man, get a clue. IRQ handlers are not schedulers. Also, PCI latency has NOTHING to do with IRQs.

I'm glad you're so intellegent that you can quote wikipedia. But you clearly do not know the subject matter.

 

[VirtualLarry]

For a simple example of IRQ latency and DPC latency, imagine a worker at a desk in an office, with a phone. A Phone call is a hardware IRQ handler, the worker has to pick up the phone, and stops doing what he is doing to answer and deal with the phone, and the phone can only recieve one call at a time. The hardware IRQ handler latency is the time spent on the phone call. The objective is to deal with the phone call and get off the phone as fast as possible, in case another call comes in. Now imagine that immediately after recieving a phone call, the worker must prioritize doing work that the phone call initiated, immediately after the phone calls have ended. These are DPC calls. If the worker recieved several phone calls back-to-back, then he may have several priority work items to work on, before he can get back to his basic daily office work. That work would be equivalent to scheduling application threads and running programs.

 

[beray]

Originally posted by: VirtualLarry
My god man, get a clue. IRQ handlers are not schedulers. Also, PCI latency has NOTHING to do with IRQs.

I'm glad you're so intellegent that you can quote wikipedia. But you clearly do not know the subject matter.

Originally posted by: VirtualLarry
For a simple example of IRQ latency and DPC latency, imagine a worker at a desk in an office, with a phone. A Phone call is a hardware IRQ handler, the worker has to pick up the phone, and stops doing what he is doing to answer and deal with the phone, and the phone can only recieve one call at a time. The hardware IRQ handler latency is the time spent on the phone call. The objective is to deal with the phone call and get off the phone as fast as possible, in case another call comes in. Now imagine that immediately after recieving a phone call, the worker must prioritize doing work that the phone call initiated, immediately after the phone calls have ended. These are DPC calls. If the worker recieved several phone calls back-to-back, then he may have several priority work items to work on, before he can get back to his basic daily office work. That work would be equivalent to scheduling application threads and running programs.

Ha ha ha :laugh: :laugh: And here I myself had yet ever taken an English class.

It's a pity, no wonder tech stuff outsourced and gone to places where they don't even speak English.

 

[Blazer7]

This thread is getting ridiculous. You people must either agree to disagree or take it elsewhere. The rest of us are trying to figure this out and the last thing we need is a mod locking this thread down because of you.

 

[beray]

Originally posted by: Blazer7
This thread is getting ridiculous. You people must either agree to disagree or take it elsewhere. The rest of us are trying to figure this out and the last thing we need is a mod locking this thread down because of you.

It is a fact that when you said to FSAA "experts" --> "Jittered blending of adjacent pixels caused blurriness in V5's FSAA"... You have to repeat it over and over and over, again and again and again, then wait at least 6 months for their brains to kick in.

VirtualLarry the "expert" had no clue of --> "EvtInterruptIsr" = Immediate high priority interrupt and "EvtInterruptDpc" = Defer low priority interrupt used in PCI drivers. You will have to put up with VirtualLarry the "expert" for at least 6 months, though sometimes many "experts" required years and years.

 

[Blazer7]

beray,

This has nothing to do with who is right and who is wrong. Everyone is entitled to his/her own opinion. Disagreeing is ok, it's part of life. The thing between you and VirtualLarry has gotten way too personal and this is devalueating this thread and the efforts of all others here. I know that I didn't join the forums for this and by no means I will take part on your little debate.

However, I'm completely fed up with this and if you 2 continue your little flame war I will exercise my right as an AT forum member as this is described in the AnandTech Forum Guidelines and send my e-mail to moderator@anandtech.com

This has gone too far and one way or another this will stop.

 

[beray]

Originally posted by: Blazer7
beray,

This has nothing to do with who is right and who is wrong. Everyone is entitled to his/her own opinion. Disagreeing is ok, it's part of life. The thing between you and VirtualLarry has gotten way too personal and this is devalueating this thread and the efforts of all others here. I know that I didn't join the forums for this and by no means I will take part on your little debate.

However, I'm completely fed up with this and if you 2 continue your little flame war I will exercise my right as an AT forum member as this is described in the AnandTech Forum Guidelines and send my e-mail to moderator@anandtech.com

This has gone too far and one way or another this will stop.

[/quote]
OK I'm going to make you happy....


I beray recognized the superior technical expertise of VirtualLarry the expert, I hereby admitted my mistake.

"Deferred Procedure Call" is not Deferred Interrupt Service, and had nothing to do with interrupt service.

 

[VirtualLarry]

For the record, I have been trying to keep the discussion factually correct, which is why I have such an issue with beray's posts. If you do contact a mod (and I hope that you do), then at least may I suggest contacting bsobel, he's a senior mod, and he understands OS internals.
For a good read, check out the thread in which beray clearly outsmarts a power-supply engineer about power designs. http://forums.anandtech.com/me...t_key=y&keyword1=phase
Or when he resorts to insults when he disagrees with tcsenter. http://forums.anandtech.com/me...=2196230&enterthread=y

 

[beray]

Originally posted by: VirtualLarry
For the record, I have been trying to keep the discussion factually correct, which is why I have such an issue with beray's posts. If you do contact a mod (and I hope that you do), then at least may I suggest contacting bsobel, he's a senior mod, and he understands OS internals.
For a good read, check out the thread in which beray clearly outsmarts a power-supply engineer about power designs. http://forums.anandtech.com/me...t_key=y&keyword1=phase
Or when he resorts to insults when he disagrees with tcsenter. http://forums.anandtech.com/me...=2196230&enterthread=y

I beray recognized the superior technical expertise of VirtualLarry the expert, I hereby admitted my mistake.

"Deferred Procedure Call" is not Deferred Interrupt Service, and had nothing to do with interrupt service. DPC latency is not IRQ latency.

--------------------------------------

I beray recognized the superior technical expertise of tcsenter the expert, I hereby admitted my mistake.

Multi-rail power supply is a cost cutting saving technique used by experts.

--------------------------------------

I beray recognized the superior technical expertise of the mentioned power-supply engineer about power designs. I hereby admitted my mistake.

Neither I or Asus's engineers knew what we were doing. Only the above mentioned power-supply engineer did.

 

[DarkRogue]

While I appreciate the lively discussion about the inner workings of these things, every time I see more posts in this thread, I come in checking in hopes that a solution to this problem has finally been found.. only to see more bickering.
IMO, if you guys wish to continue this discussion, please start a new thread or take it to the PMs.

 

[beray]

Originally posted by: DarkRogue
While I appreciate the lively discussion about the inner workings of these things, every time I see more posts in this thread, I come in checking in hopes that a solution to this problem has finally been found.. only to see more bickering.
IMO, if you guys wish to continue this discussion, please start a new thread or take it to the PMs.

Everything factually corrected, VirtualLarry should no longer have issues with all factually corrected.

 

[Blazer7]

DarkRogue is 100% right. As for the 2 of you take note that I did sent my e-mail as promised.

@ VirtualLarry,

forum rules dictate that I do not contact a specific mod. This "issue" now lies with the AT moderators. I have full trust in them that they will look into all aspects of this, the threads you've mentioned included. The final decision for all of this is theirs alone.

 

[beray]

@ Blazer7,

"Help me, help me... I've DPC latency problems."

"beray ... No one could ever use understanding of DPC latency to fix DPC latency problems. No one needed to know what DPC latency is to fix it."

 

[JasonandBecky]

You just dont know when to quit do you?

 

[beray]

Originally posted by: JasonandBecky
You just dont know when to quit do you?

Generally I assumed people I'd explained to had above grade school comprehension...

I quit when grade school level explanation failed... HERE

"Think of a 400HP 16-cylinder engine. 400HP 16-cylinder engine is more reliable and more dependable than 400HP 1 cylinder engine, as each of the 16 cylinders only had to withstand 25HP worth of stress. (simple aprox)

However, this is a special 400HP 16-cylinder engine. It functions as efficient as a regular 100HP 4-cylinder engine, because it works as a 100HP 4-cylinder engine when that's all needed... And became 200HP 8-cylinder, 300HP 12-cylinder, 400HP 16-cylinder engine on demands."

 

[hooflung]

I just recently purchased a EP35-DS3R from the egg to replace my P965-DS3 R3.3. It has F2 bios and I just installed Vista Ultimate 64. No service packs or patches have been added yet. Installing Age of Conan got me this:

My DPC

I looked at the registry setting for the MMCS but its not there. I will be installing all the patches to Vista after AoC is installed. I am really disapointed in the P35 thus far knowing that this is my Fraps editing machine for EVE Online PVP videos =/

2.7 OC'ed 4300, 4g DDR2 800 4-4-4-12, HD3850 512, Killer M1 NIC, WD 160g SATA II, SGt 320G SATA II, LiteOn SATA DVD+-R/RW

 

[DarkRogue]

If you can return it, see if you can swap it out for a P45 board, people seem to say that Gigabyte's P45 boards no longer suffer from this issue. I can't say from experience though, as it's far too late for me to return mine.

 

[hooflung]

Well I bought it on the 1st of June so my 30 days is up for returns to newegg. However, it didn't get here until like the 5th so maybe they count 30 days from arrival and subtract non business days. Its running really nice right now despite any latency issues so I might just keep it and hope for a bios fix in the future. Hopefully they won't treat us like EVGA treat their NF4 owners and just decide not to fix it.

 

[lopri]

1. DPC latency issue isn't exclusive to Gigabyte boards and isn't something to be nervous about unless it occurs consistently and you're actually experiencing issues related to it. It's not like your usual stability test that has to pass certain amount of time without a fail.
   
   The issue specific to the Gigabyte boards has been discussed, so this thread is closed. If any of you want/need to discuss this matter further, feel free to start a new thread. Be specific to issues and respective to fellow forummers. Please note any new thread regarding this issue will be closely monitored, and any violation of forum rule will not be tolerated. If you've received a personal warning(s) from a mod, pay close attention to the forum rules since warnings are cumulative.
   
   AnandTech Moderator lopri