That is what I figured..anyone wanna uninstall the command center and see if that fixes our issue?![]()
-
-
It probably won't help those of us with the M17x.
-
The higher DPC latency spikes may be caused by the nVidia dedicated graphics cards when they are downclocking.
Download GPU-Z and monitor the frequencies in the same time while having the DPC lacenty tool opened and see what happens when cards change their clocks. -
Someone posted that in stealth mode they didnt have many spikes on latency. Then out of stealth mode it went crazy..
-
It's not a AW software because when i just install vista or 7 with no driver and no software the DPC Latency is the same.
Edit: And My M15x has no DPC latency (always in the green) -
Maybe Alienware added one extra feature free of charge then? "DPC latency generator" that gives us all high latencies.
-
I saw the problem with the DPC Latency in M17x being signaled a couple of months ago when I was looking to decide between M17x and D900F.
This is my D901C DPC Latency results on Win7 RC with no tweaking, e.g. all drivers installed, including Intel 5300 and browsing with an external D-Link DWA-140 USB wifi card; no speed step or Nvidia downclocking disabled.
D901C/D900F have been sold as Digital Audio Workstations (DAW) for some time by some of the professional audio equipment resellers. ADK Pro Audio used D901C and now uses D900F for DAWs. Kobalt Computers UK was also looking to qualify D901C for audio pro tools before D900F appeared.
The most recurring inquiry of the audiophiles looking for DAW laptops was about the firewire chipset. It appears that the existence of the Texas Instruments (TI) firewire chip was essential as it was the most stable and without frame drops (probably when connecting external audio tools via firewire, not sure it affects the DPC otherwise). D901C, D900F, MacPro, and extremely very few laptops (some HP and Lenovo) had the TI chip.
Clevo M570TU/RU had lower spec firewire chipsets (Via !?) although in certain configurations were acceptable. Ricoh chipset was the worse.
Maybe disabling the Firewire drivers (if the chipset in M17x is not so great) will fix the problem?! Worth a try.Attached Files:
-
-
To the OP and those interested in isolating the issue, perhaps this might help. http://forum.notebookreview.com/showthread.php?t=291800
A group of people and I have worked together to isolate the issue when it occurred on the m15x. In a nutshell, we found out that the x34 BIOS (which was being shipped with every m15x at the time) was the culprit for the issue.
Because I personally do not own an M17x, I can't say for sure that this is what's causing the issue for you guys but perhaps the dialogue in the link above will give you a general idea on where to start looking and how to come about diagnosing the issue. Try recording inconsistencies between different OSes, different versions of WIFI and sound drivers, and inconsistencies between different versions of the BIOS (if there are more than 1 version of the BIOS). -
Some additional information is here (abstraction of the marketing competitive statements): http://www.adkproaudio.com/compete.cfm
1) Chipsets: The main chipset is the Intel 945 PM/GM (GM indicates onboard video) and 965. And this is not the issue. The Chipset issue is what is being used for the Cardbus(if it actually still has one)or Express card slot, memory card reader, modem, network, Firewire, or what's called combo chipsets (everything on one controller).
Ricoh: (Asus and others) a lot of incompatibility with audio interfaces and general poor performance. lack of low latency
ENE: (compal and others) same as above, the Cardbus is horrid. Usually with Via Firewire. The Via Firewire does better than Ricoh.
O2R: Orange Micro, (MSI) same as the Ricoh chipset.
Agere: (found in Apple for 6 months now Apple is back to TI) same issues as Ricoh but not as bad. some interface will work but still not at low latency.
Realtek: now found on several laptops, not just as audio, but audio, card reader, Cardbus, modem, Firewire.
Texas Instruments: Firewire and Cardbus/Express slot (again Cardbus is gone from most new laptops). The chipset to have!
2) BIOS: most laptops are 512k some are 1 meg, where a desktop will have 4meg- 8meg.
This is probably the biggest issue. The BIOS for the most part is responsible for IRQ and resource allocation. A small and poorly written BIOS is what causes so many things to be lumped onto one IRQ.
ACPI handles this.
Microsoft developer site
With laptops you have hot swap devices (cardbus, Express slot and more), and this adds to the issue. Understanding that resource allocation is memory based (name space and virtual memory), a small BIOS has a hard time allocating space for all potential product IDs.
Add to that we now have PCIe even more BIOS issues arise.
More from Microsoft.
Insufficient bridge resources appear when the platform BIOS cannot assign appropriate PCI-bridge resource windows during POST. Systems supporting hot-plug PCI devices are particularly problematic. When a PCI device can be hot-plugged behind a PCI bridge at run time, it is impossible for the BIOS to ascertain during POST how large a bridge resource window must be to accommodate a device. Additionally, a PCI bridge device might be hot plugged in certain situationsfor example, in generic docking solutions that connect through CardBus adapters
The previous scenarios are exacerbated with the emergence of PCI Express. PCI Express defines many bridge devices that are used to represent ports, thereby making complex bridge hierarchies more prevalent. Additionally, PCI Express hot-plug will be widely used in desktop and workstation client systems, so hot-plug scenarios will not be limited to large servers.
So small BIOS means less ability to handle ACPI steering and resources in virtual space
3) Expectation of ODM: Most laptops are NOT designed to be used as workstations. The vendors never expected this. Laptops are designed to be light weight, have long battery life, and be used mostly by business people on the go, or typical home user surfing the net, playing music, and so on. Therefore they program the BIOS in a careless manner.
Here is more about how its left to the individual ODM to program the bios.
The rules for the above programmable ranges are:
1. ALL of these ranges MUST be unique and NON-OVERLAPPING. It is the BIOS or system designers responsibility to limit memory population so that adequate PCI, PCI Express, High BIOS, PCI Express Memory Mapped space, and APIC memory space can be allocated.
2. In the case of overlapping ranges with memory, the memory decode will be given priority.
3. There are no Hardware Interlocks to prevent problems in the case of overlapping ranges.
4. Accesses to overlapped ranges may produce indeterminate results.
5. The only peer-to-peer cycles allowed below the top of memory (register TOLUD) are DMI to PCI Express VGA range writes. Note that peer to peer cycles to the Internal Graphics VGA range are not supported.
Taken from Intel's whitepapers Here
A few manufacturers put more thought into it. Again the more expensive Texas Instruments chipset is a good indication that there was consideration for use as a workstation. The BIOS will be a bit more open and better programming as well as usually larger. The more different chipsets there are internally the more likely they will have their own resources, as opposed to everything in one chipset. So that about covers the less obvious (hard drives, memory etc) -
http://kmuto.jp/debian/hcl/. Could not find anything about Alienware or some other current systems, but some notable examples are:
http://kmuto.jp/debian/hcl/Clevo/D901C/ - TI Firewire chipset
http://kmuto.jp/debian/hcl/Apple/MacBook+Pro+17 - TI Firewire chipset
http://kmuto.jp/debian/hcl/DELL/M1530 - Ricoh Firewire chipset -
I have try to disable all the périphéral in the same time an no luck with that. I really think it's a problem with the Sli and maybe a bios can fix this.
-
Heres what mine looks like running windows 7
Attached Files:
-
-
Running Everest to find the size of the BIOS and the firewire chipset may give some indications to the problem.
You can also run DPC Latency checker with the 9400M alone, with only one dedicated card and in SLI to narrow down the cause. -
this laptop has a 640kb bios.
-
I think that Alienware is aware of the DPC problems since they have already addressed the issue in m15x systems:
http://forum.notebookreview.com/showthread.php?t=291800&page=24
Their m15x BIOS revision lowered the DPC from 10-15k to about 1k. Don't know why they didn't share their knowledge on this one with the M17x team.
D901C has a 2MB BIOS and D900F has 4MB BIOS, I think, because they both use desktop chipsets. It would be interesting to find out if the Clevo M98U/ Sager NP9850 mobile gaming laptop has the dpc latencies issue. -
Hi K-nabeesse,
Did you ever solve your M17X DPC Latency issues? I am having the same issues with my M17X and have tried everything to resolve it. I have finally contacted Alienware and Dell Senior Reps. They called me back this morning and said they they are able to duplicate the DPC latency issues and are working on a software update to try to resolve the issue. (either bios or other driver)
I was just checking with you to see if you are still having issues too?
All the Best -
-
I'm suffering from the same exact issues: stuttering due to DCP Latency (Deferred Procedure Calls) and sometimes even hung ups.
I will start off with the description of my hardware:
Alienware M17x
Intel Core 2 Quad CPU
4 GB RAM
GeForce 9400
GeForce GTX 260M
I've been monitoring DCP latency with different setups (different OS's, while iddle, while gaming, etc) and this is what I got:
DRIVERLESS WIN XP IDDLE
http://img4.imageshack.us/img4/722/dcplatwinxpiddle.png
WIN 7 IDDLE
http://img188.imageshack.us/img188/7012/dcplatwin7iddle.png
WIN 7 WHILE GAMING WITH GEFORCE 9400
http://img8.imageshack.us/img8/8536/dcplatwin7whilegamingwi.png
WIN 7 WHILE GAMING WITH GEFORCE GTX 260M
http://img188.imageshack.us/img188/8536/dcplatwin7whilegamingwi.png
I have tried disabling every possible hardware in the machine and the latency is still the same. I have no screenshots while running on vista but I suffered from the same exact problem. I have tried many driver combinations as well. Some my reduce the highest spikes but still getting an average of over 4000µs, when a computer like this should be running under 50µs. I'm gonna call Dell today for a replacement or a solution. I might be wrong but I doubt this problem will be solved through drivers or BIOS updates.
Hopefully this benchmarking will help other users to determine their stuttering problems.
Cheers!
---------------
Just a few more notes:
- My desktop computer while running orthos doesn't even reach the 500µs mark and iddled not over 120µs. It's running under Win7 RC 64 using vista and beta drivers.
- You can download DPC Latency Checker from this site -
Heres my results, they seem to be a bit different than some of the other guys, with the spikes only going up to 2000 at idle and 4000 under load.
My specs are M17x, A02 Bios, t9550 Overclocked to 3.2Ghz 2 x gtx260, 2 x 500gb Raid, blu ray burner, Vista 64
I have changed a few of the bios options and have disabled the onboard 9400 but otherwise am running the standard drivers and software, ill mess around with it to see if I can affect the results.
Idle
http://img5.imageshack.us/i/dpcresult.jpg/
Under load
http://img5.imageshack.us/i/dpcresultload.jpg/ -
My problem of DPC latency is not resolved.... I think Dell doesn't care about that.....
-
FIX THIS! PRONTO! -
Aristotelhs2060 Notebook Virtuoso
finally is it a drivers issue , bios issue or os issue or no one knows? according to dpc latency checker a driver may cause this but i disabled almost all devices in device manager and almost all processes and nothing changed..
i was trying to find something for this those days and it seems that its a matter of bios? for the old m15x a bios called x36 seemed to reduce the dcp latency.
http://forum.notebookreview.com/showthread.php?t=291800&page=19 post#188.
lets force Dell -Alienware to do something about this. its the most expensive laptop in the world. for God shake! -
-
Hello Everyone,
I've been working with Alienware's Senior Techs on this issue for the past few weeks. They are currently writing a BIOS update to resolve our issue. (That is what they believe the cause is after all our testing)
I just spoke with Tech a few minutes ago and showed him this thread once again. (on 10/21/09 @ 12PM EST.) They are fully aware of our issue and firmly believe this Bios revision will resolve our DPC Latency on our M17X's. The tech went on to assure me that they expect to have this New Bios available from the Dell Support Site in approximately 2 Weeks.
I will keep you posted! Lets keep our fingers crossed that it finally resolves the issue! -
wow what a great update. Yeah I think Alienware/Dell have gotten very good at customer feedback - keep in mind this is a bohemouth corporation actually implementing end user feedback.. Love it
-
good news coterj
i hope this is real. -
Yes, it is absolutely real.
-
Aristotelhs2060 Notebook Virtuoso
if this is true then it will be absolutely great! fingers crossed! -
This is Deja Vu all over again. The older m15x had the same issues.
-
Aristotelhs2060 Notebook Virtuoso
better deja vu than nothing. at least for the time being we shoudl wait for it.
-
If this is true they are gonna make happy plenty of users ^_^
-
Any updates on this?
-
It is not primarily a BIOS issue, although it may reduce the problem.
It is the firewire chip on the laptop; if it is not a Texas Instruments (TI) chip, the laptop will most likely have this problem.
The firewire chip is important because all the PCI-Express I/O ports that come from the Southbridge have to pass a legacy PCI-bridge which is the actual TI chip. For some reason, all firewire chips are PCI based, even if they are advertised with a PCI-Express interface.
There are just a few laptops with TI "firewire"/PCI bridge chipset. These include Clevo D901C/Sager NP9262, most of the MacPro laptops, and some HP's. Maybe others.
Look in the Device Manager or with Everest to see the device name and id under PCMCIA tab. You will find your own chip. Ricoh is the worse from what I hear, VIA is better but not much. -
The M17x has a Ricoh 1394 compliant host controller, it seems. Disabling it in the device manager doesn't appear to help with the DPC latency, however.
-
Sager NP8662, which is not a cheap laptop either but definitely lowered spec-ed than M17x, uses a Ricoh chip too. -
cookinwitdiesel Retired Bencher
Ricoh chips are VERY commonly used.....just like realtek and marvell
-
I was just referring to the M17x high-end profile.
-
Any word on whether that BIOS update will be coming out soon? I swear I am going to have to kill myself if this issue continues. I love listening to music and the audio is just slaying all my songs
-
Sorry for double posting but I was curious if someone could explain this to me.
If this really is a BIOS issue why is it that when I disable SLI the DPC latency issue is still there (fluxuating between 130-4000 whereas with SLI is jumps to 66000) but the sound stuttering is fixed (because the spikes are what kills the sound).
Also, as a poster above stated about the Firewire, why would it also be that?
I understand that there is a connection between all these things (don't shun me for not knowing my hardware!) but I really don't get the connection between SLI on and off correcting the stuttering.
What can I say, I'm a software guy... Hardware isn't my strong suit. -
cookinwitdiesel Retired Bencher
funny, since this is 100% a software issue....it is drivers for the hardware causing the issues, not the hardware it self
-
But how can it be a driver problem when I can do a completely clean install without any drivers installed and the DPC latency issue still occurs?
-
cookinwitdiesel Retired Bencher
maybe BIOS, but don't forget that windows will load its own drivers if you never load manufacturer specific device drivers
Good argument though, I will have to think on that
Pretty sure this is related to the stuttering issue people have been experiencing, so hopefully they can fix both with one patch -
Yeah for sure, I've tried every version of every driver available for the M17X since launch day, from fresh installs for each (yeah... I have no life) and no variation of patches improves or worsens the problem. That is kind of where I got the BIOS idea from, alongside the arguements other people have supplied towards the BIOS idea.
-
cookinwitdiesel Retired Bencher
I am pretty sure a BIOS can fix the stutter as well,
lets just all hope Dell is reading this attentively -
I think this is a primarily hardware problem and only secondarily a BIOS problem. You can look for this thread to gain more info:
http://forum.notebookreview.com/showthread.php?p=5392280#post5392280
They mention there that you can alleviate this using by using a Firewire 800 ExpressCard adapter link for your external audio devices.
Neil@Kobalt mentioned Lacie Firewire 800 ExpressCard 34, but I have read that Sonnet Firewire 800 ExpressCard 34 is better since it has a better TI firewire chip, e.g. XIO2213. -
I looked in the D901C User's Manual and I found that it has a TI PCI7402 Firewire chip. From the attached schematics you can see that it is an integrated Firewire and FlashMedia controller on the PCI bus.
This is why an Audio Pro Tools reseller said that until the whole PCI bus is phased out from the notebooks this latency problem will remain important.
Again I do not understand why the OEM's/ODM's cannot afford a good firewire chip when the TI PCI7402 costs only 5$ per 1000 trays. You sell a 2000+ laptop and for 5$ you screw the whole PCI bus which obviously you cannot upgrade:
http://focus.ti.com/docs/prod/folders/print/pci7402.htmlAttached Files:
-
-
Or would physically disconnecting the whole firewire/flash media assembly help? -
If uninstalling the drivers/disabling the firewire controller from Device Manager doesn't help, you may try to disable it from BIOS to experiment. However, it will also may disable all the ports/devices that are downstream the PCI bridge.
If you read here you may find that almost all devices are on that bridge with the exception of the MXM video cards.
http://www.kvraudio.com/forum/viewtopic.php?p=3149566&sid=fae9fa6ff5b386e70c66532a9a662114#3149566
I assume, but not very sure, that even the audio controller is downstream of the PCI bridge, so that may defeat the purpose. -
JUST AN UPDATE:
Dell called me and left me a voicemail on Friday. (10-30-09) They tell me they are still working on the problem.
I am curious.... does anyone here have this system with the ATI Cards (Crossfire) and ATI Chipset? If so... can you check and see if your latency is the same as the other M17X's with the NVidia SLI Cards n Nvidia Chipset? I was kind of wondering if that setup had the same DPC Latency issues in the M17X.
My system is still useless with this problem. -
M17x and DPC Latency
Discussion in 'Alienware' started by K-nabeesse, Aug 13, 2009.