Tool To Analyze Labs ?

[mathieujm]

Really Samplitude is great because it seems to be the only recording tool that detects errors during recording and let you know how many and where are these errors.

SO, then we have to find how eliminating the causes of these errors. In OrangeHill optimization guide we have plenty of good tweaks, and there others here in the board.

BUT what is really lacking is a debug tool to know the context of the system when the errors occur.

Actually we have to try in the dark, particulary when you have to face erratic LABs from time to time.

IF a tool could give all the pertinent measures on the system (CPU / drives I/O / PCI latency / ports using...), it could be a great advantage for Samplitude.

Now some ideas :

- XP (and I think Vista) has a lot of capabilities to measure a lot of these parameters (look at the Performance screen)

- Some tools exist that give an history of others measures (Process Explorer, DPC Latency checker

- But these tools don't give a clear vision of what was the system when a LAB occured

The tools could generate a status report when a lab occurs.

If Samplitude support don't want to be swamped whith these reports, they will have to be readable by most of us who know some little things about computers

Recently I was appealed on the Magix support site for a survey over a similar project.

Clearly i would be ready to pay (not too much...) to have this kind of tool.

[Sebastian.Gabler]

Perfmon (onboard profiler of Windows, press F1 or search MS Developer network for more information) and this : http://www.thesycon.de/dpclat/dpclat.exe

is actually all you need.

Besides: LAB is not the result of an exact measurement, but contains a good portion of crystal-ball reading. That will not go away.

Regards,

Sebastian

[perler]

is dpclat.exe cpu speed dependant? i have a latency of 2000 ums but then i' am on a 1,4 ghz pentium m. should i try to lower this value?

PAT

[Sebastian.Gabler]

Ask them who developed the tool.

Cheers,

Sebastian

[mathieujm]

Besides: LAB is not the result of an exact measurement, but contains a good portion of crystal-ball reading. That will not go away.

Regards,

Sebastian

OK, I already noticed the tools you mention. But when you have one or two labs an hour, it's not easy to find what happened just at this moment and it seems I don't have the right crystal-ball

The problem is to be able to eliminate a maximum of potentiel causes to concentrate on some possible ones.

The biggest problem to solve an erratic issue is to know when this issue happends to be able to see the context. But with Samp we know when this happends, so what about giving the context just at this time ?

[Sebastian.Gabler]

Hi,

If you have the time working with the tools I have mentioned, then your questions will be answered from yourself.

Regards,

Sebastian

[mathieujm]

If you have the time working with the tools I have mentioned, then your questions will be answered from yourself.

Thanks Sebastian.

I took long time to deeply investigate where the prob was.

First i finally noticed that the prob arrive once an hour, always at the same min/sec in each hour. And these min/sec corresponds to the last boot .

I used the alerts on CPU usage per process in the performance tool. The log showed me that every hour there was a cpu spike of 60% on the process System.

The process involved don't say anything about the thread involved to identify the faulty driver.

So, knowing the exact hour of the problem, i used Process Explorer to identify the thread. It was very easy to find that it's was Iastor.sys.

This driver is the Intel AHCI/SATA driver.

This problem arrive constantly even if nothing run on the PC.

Then I installed the latest version of Intel Matrix Storage Manager witch provide this driver.

The result : always the hourly CPU spike for the iastor.sys but only at 20%. But it's enough to always have my hourly LAB

So now I consider AHCI as the real problem and I want to go back to IDE for my SATA drive. But it seems to be not so easy as I will probably have to reinstall XP for that.

NB : I saw on SoundonSound forums that RME recommend to not use AHCI because of this kind of problem

If this could help others with LABs and SATA drives

Jean-Marie

[Sebastian.Gabler]

It can be that Iastor.sys really is causing problems with DPC calls. There are several reports that allow for that allegation.

If you run any current Intel chipset in AHCI mode, you have to deal with Iastor.sys. I think however that AHCI itself is not the culprit, to oppose to the development of another urban myth.

Regards,

Sebastian

[mathieujm]

It can be that Iastor.sys really is causing problems with DPC calls. There are several reports that allow for that allegation.

If you run any current Intel chipset in AHCI mode, you have to deal with Iastor.sys. I think however that AHCI itself is not the culprit, to oppose to the development of another urban myth.

Sebastian, I made my tests disabling all I can (Network, Antivirus...). CPU is 0% constantly eccept the hourly spike and only Iastor activity so...

I used DPCLAT during the prob and nothing significant appears at this moment

here is a thread about this on RME forum

Finally I applied this process :

- I changed the driver of my controler from the Intel AHCI to the Microsoft standart IDE

- I rebooted

- F2 to modify the BIOS

- Change to disable AHCI

- Save the Bios

- Finish the boot

And, O miracle, after that I recorded continuously 3 h without a lab.

So I don't know why IASTOR has this problem and if the source is somewhere else but going back to IDE resolved my LAB problem

Thanks for the help to a poor Samplitude MS2008 user

Jean-Marie