Gigabyte Boards and DPC Latency

[beray]

Originally posted by: semaj1286
I'm hoping someone can shed some light on my issue and if it even relates to the one discussed in this thread. I use Gigabyte's GA-MA78GM-S2H motherboard, version 1.0. I'm currently on BIOS F5 which was just released recently. I've been trying to figure out the audio/video stuttering that I've been seeing randomly (mostly apparent while gaming).

The easiest way for me to get the issue to occur is to simply load Half-Life 2 or Team Fortress 2 and strafe back and forth. I can see the FPS spike occur and occasionally the audio will stutter with it.

Finally after searching forever across Google and forums I came across that DPC Latency Checker program. While I'm even typing this message the DPC Latency Checker is spiking into the 50,000us+ range. If I leave the computer sitting without typing or anything it won't spike over 200us. From what I've read 50,000+ is pretty insane, but I really have no idea how to go about fixing it or if it's the same issue you all are dealing with. I put in a ticket on Gigabyte's site and PM'ed GigabyteColin on here as well thinking and hoping that's my issue.

I was wondering cactusdog since you said "There are some problems with high DPC latency on most Gigabyte boards released since P35 upto X38/X48. Some people have the problem and dont know it. " if you know if my motherboard is affected by this issue or if it sounds like I have the same issue?

Try to separate latencies contributed by lousy software/driver from hardware latency problem.

One of the best way is multiple OSs, when it's pure hardware latency problem, it'll show up on all OS.

Example of software/driver contributed DPC latency spikes in XP --> Using windows managed wireless connection manager would cause a huge DPC spike every 64 seconds with XP_SP3.

 

[cactusdog]

semaj1286, i havent seen many reports about Gigabyte boards with AMD chipsets but it wouldnt surprise me because the latency issue is related to the board and not the chipset, but there could be many reasons you are having problems like beray said so you will need to test it yourself.

The best thing to do is remove any peripherals from your PC(incuding Esata etc just run a basic system), format and reinstall Windows. Before you load any drivers for anything, run the DPC latency program and see if its still there. If it is, its most likely a problem with the board. If its ok you need to install drivers/peripherals 1 at a time until you find the cause.

If you dont like the idea of reformatting you could remove your Hard drive and use another Hard drive for testing if you have one.

 

[semaj1286]

Well I decided to reformat and I'm still getting the DPC Latency spikes just by typing this message to you all. What do you all suggest now?

 

[Blazer7]

Ok, I've finally nailed it. The GT200 drivers + modified inf were responsible for the abnormally high DPC latencies so everybody take note of this. I've used an old ghost image to fully revert my boot drive to a former state. Once finished DPC latencies fell back to green and stayed there until I tried to reinstall the modified GT200 drivers (Forceware ver 177.35,39,40,41 + modified inf). It's one thing to experience high latencies because of a problematic board/BIOS but it's an entirely different thing to get into trouble because of a driver.

Still I can't explain why I experienced no stuttering whatsoever. It is also strange that I can't find any other utility out there that can measure DPC latencies. Anybody know of an alternate utility for this? It would be great if we could find something to cross-check the results from the DPC checker.

 

[beray]

Originally posted by: Blazer7
Ok, I've finally nailed it. The GT200 drivers + modified inf were responsible for the abnormally high DPC latencies so everybody take note of this. I've used an old ghost image to fully revert my boot drive to a former state. Once finished DPC latencies fell back to green and stayed there until I tried to reinstall the modified GT200 drivers (Forceware ver 177.35,39,40,41 + modified inf).It's one thing to experience high latencies because of a problematic board/BIOS but it's an entirely different thing to get into trouble because of a driver.

Outstanding..!!!

Originally posted by: Blazer7
Still I can't explain why I experienced no stuttering whatsoever. It is also strange that I can't find any other utility out there that can measure DPC latencies. Anybody know of an alternate utility for this? It would be great if we could find something to cross-check the results from the DPC checker.

That's because basicly everything worked in BUFFERED BURST MODE data streams, as long as the spikes didn't last too long causing time out for others there's no problem.

This is why CD/DVD burners have huge builtin cache, and still require burning sofware using montrous memory cache as well as montrous disk cache. Even with the monster caches usage, the data still had to be streamed (BUFFERED BURST) properly.

Low latency buffers are smaller and they need to be updated more frequently.

 

[semaj1286]

Is there anything else I can do or should I just wait to see if a BIOS is available and can fix it? Hopefully a BIOS update will fix it and it won't be a motherboard issue. lol Thanks for all of your all's help

 

[Blazer7]

Originally posted by: beray
That's because basicly everything worked in BUFFERED BURST MODE data streams, as long as the spikes didn't last too long causing time out for others there's no problem.

That's part of why I'm confused. The modded drivers caused continuous latencies in the range of 2500-3100. The latency would spike from 2500 to 3000-3100 and then gradually descent to the 2500 level just to start all over again yet I experienced no playback problems and I play music all the time.

 

[toadeater]

Originally posted by: semaj1286
Well I decided to reformat and I'm still getting the DPC Latency spikes just by typing this message to you all. What do you all suggest now?

USB keyboard? If so, try a PS/2 keyboard. It seems to be related to USB and eSATA for some people.

 

[beray]

Originally posted by: Blazer7

Originally posted by: beray
That's because basicly everything worked in BUFFERED BURST MODE data streams, as long as the spikes didn't last too long causing time out for others there's no problem.

That's part of why I'm confused. The modded drivers caused continuous latencies in the range of 2500-3100. The latency would spike from 2500 to 3000-3100 and then gradually descent to the 2500 level just to start all over again yet I experienced no playback problems and I play music all the time.

Simplified...

Typical stereo sounds are 16-bit 20kHz, or 4 BYTES at 40000 samples = 160KB = 1X CDROM = 1 second of sound.

Current typical mobo used DDR2-800 or PC6400 or 6 GB/s or 40 seconds worth of sound per millisecond bursts.

"The latency would spike from 2500 to 3000-3100" = 3 millisecond glitch = no hindrance to playing music.

 

[semaj1286]

Originally posted by: toadeater

Originally posted by: semaj1286
Well I decided to reformat and I'm still getting the DPC Latency spikes just by typing this message to you all. What do you all suggest now?

USB keyboard? If so, try a PS/2 keyboard. It seems to be related to USB and eSATA for some people.

Nope, just the standard keyboard and mouse connections are being used.

 

[fimpenb]

I've got a hold of beta BIOS F4b for EP35-DS4 rev. 2.1 and there's a huge improvement. The latency spikes are more or less completely gone. From having spikes around 1600 us every other second I now have a smooth pattern that stays within 2-30 us. I've only had one spike the last half hour that went up to 2400 us, don't know why yet but it's just been one. (I'm not running Dynamic Energy Saver of course.) If you have the EP35-DS4 motherboard I recommend to try it out.

BIOS F4b: ep35ds4.f4b
Picture of latency pattern: Latency after BIOS update

Edit: Ok, I occasionally have spikes around 2400 us, with about a five minute interval.
Edit2: IMPORTANT! You can't change the CPU voltage with these BIOS so beware. It'll keep the current settings as long as you don't clear the CMOS after flashing.

 

[toadeater]

Originally posted by: fimpenb
Edit2: IMPORTANT! You can't change the CPU voltage with these BIOS so beware.

I've read a lot of threads where people have this problem with beta Gigabyte BIOSes. Since whenever they first introduced this bug, it has spread to different boards. Voltage can't be changed, and for some EIST disappears from the BIOS. Strange that they haven't noticed this happening yet, it's been months already.

 

[JonLB]

I've got a GA-MA78GM-S2H (rev.1.0) motherboard and am also experiencing this problem, getting 1500 uS and audio dropouts every 3/4 minutes. Is there any solution for this?
http://i18.photobucket.com/alb...movie_fan_2005/dpc.jpg

Processor is an Athlon X2 5000+, 2 Gb memory, Asus Xonar D2, Marvell Veritas wireless adapter.

Disabled wireless card, USB hosts, etc, but could not solve the issue.

 

[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

 

[VirtualLarry]

Originally posted by: beray

Originally posted by: spammah
Could it be something that would have to do with RAM or the RAM values in the BIOS?

No, it's directly related to "PCI latency" which is a misnomer. The accurate name is IRQ LATENCY .

More INFO

Originally posted by: spammah
Tested this program with my old AMD 3800+ X2 with ASUS A8N32-SLI Deluxe nForce4 SLI X16 chipset and I have below 20 us constantly.

AMD systems inherently better for realtime apps as AMD had lower LATENCY values from onboard memory controller.

Please get a clue. DPC latency is NOT PCI latency which is NOT IRQ latency. Neither do they inherently have anything directly to do with the DRAM access latency.

I have a socket 939 system running on an NVidia 6150 chipset that has absolutely HORRID DPC latency issues right now. 260,000us delays, the mouse freezes momentarily, watching YouTube is impossible.

 

[beray]

Originally posted by: VirtualLarry
Please get a clue. DPC latency is NOT PCI latency which is NOT IRQ latency. Neither do they inherently have anything directly to do with the DRAM access latency.

"Deferred Procedure Call" is IRQ driven. --> More INFO for idiots.

Originally posted by: VirtualLarry
I have a socket 939 system running on an NVidia 6150 chipset that has absolutely HORRID DPC latency issues right now. 260,000us delays, the mouse freezes momentarily, watching YouTube is impossible.

I've zero problem watching YouTube with my nvidia 6150.

 

[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

semaj1286,

I'll try that.

Thanks!

 

[imaheadcase]

I just though I would let you all know, it will spike to red with ANY usb device or wireless device on computer, REGARDLESS OF MOTHERBOARD..this is NORMAL. I ran it on my "old" Gigabyte DS3 version 1.0.

I ran the program, move usb logitech g5 mouse during running and will spike to 4000, type on keyboard, spike to 4000, run wireless usb stick, spike to 4000.

 

[Blazer7]

@ beray,

As I know what causes the high latencies I was able to recreate it and test with Video & DVD playback. Still no stuttering. Even when I'm running other tasks like burning a DVD with Nero everything's working fine. What do you make of this ?

 

[VirtualLarry]

Originally posted by: beray

Originally posted by: VirtualLarry
Please get a clue. DPC latency is NOT PCI latency which is NOT IRQ latency. Neither do they inherently have anything directly to do with the DRAM access latency.

"Deferred Procedure Call" is IRQ driven. --> More INFO for idiots.

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.

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.

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.

Do I need to explain DRAM latency too to you?

 

[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?

 

[Blazer7]

I don't know if that's possible but I don't think that that's what matters right now. What matters is that DPC latency is an issue and flaming doesn't help.

Flaming is totally unacceptable here and that grinding noise in the background is probably that of some mod sharpening his axe. At the worst, flaming can cause this thread to be locked and that suits nobody.

So behave.

It's far more civil to agree that you disagree but calling names and stuff, that's totally unacceptable.

 

[beray]

Originally posted by: Blazer7
I don't know if that's possible but I don't think that that's what matters right now. What matters is that DPC latency is an issue and flaming doesn't help.

Flaming is totally unacceptable here and that grinding noise in the background is probably that of some mod sharpening his axe. At the worst, flaming can cause this thread to be locked and that suits nobody.

So behave.

It's far more civil to agree that you disagree but calling names and stuff, that's totally unacceptable.

In most places, it's OK to be low-life no manner idiots. But recognizing low-life no manner idiots usually is a greater crime to humanity.

1. beray,
   
   This is an official warning for your rude and inappropriate posts. There will not be any more warning before a vacation. No personal attack is allowed in this forum.
   
   AnandTech Moderator lopri

 

[Blazer7]

Forum rules : absolutely zero personal attacks.

If somebody can't cope with that then that somebody doesn't belong here.

 

[beray]

Originally posted by: Blazer7
@ beray,

As I know what causes the high latencies I was able to recreate it and test with Video & DVD playback. Still no stuttering. Even when I'm running other tasks like burning a DVD with Nero everything's working fine.

Realtime apps required bandwidth for "Realtime", different apps required different amount of bandwidth to be "Realtime". As long as there's enough bandwidth "Realtime" is possible.

Bandwidth = both time and frequency. --> Time is bandwidth.

The below is not normal.

I just though I would let you all know, it will spike to red with ANY usb device or wireless device on computer, REGARDLESS OF MOTHERBOARD..this is NORMAL. I ran it on my "old" Gigabyte DS3 version 1.0.

I ran the program, move usb logitech g5 mouse during running and will spike to 4000, type on keyboard, spike to 4000, run wireless usb stick, spike to 4000.

One occasional little 4000 spike is not much of a problem, lots of little 4000 spikes is a big problem. One little spike = tiny lost of bandwidth, lots of little spikes is not a tiny lost of bandwidth.

Think of the DPC graph as the display of a spectrum analyzer, the spikes plot the lost bandwidth. Unfortunately the horizontal resolution is not finer, most likely the programmer didn't want the program to become part of the bandwith problem, and the program had very low negligible bandwidth usage to be "Realtime".

Originally posted by: Blazer7
What do you make of this ?

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.