Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: bteifeld on July 19, 2016, 11:14:00 am
-
I have observed at times that when I am running no software like i1profiler, profilemaker, a rip that works with an x-rite device, or anything of color management significance at all, that Xrite Device Services(xrdd.sys) is pinning the needle to the tune of a full cpu core on my workstation. What on earth could be going on to require what appears to me to be a monumental waste of my workstation's resources?
-
Hmmmm.... on my rMBP (Core i7) with Mac OS X 10.11.5 XRDD runs at .2% CPU.
-
While measuring a target:
-
On my Skylake PC, it's using an average of 0.02% of cpu. However, it's clearly doing something continually, as it generates around 1,000 page faults per second, all the time.
What on earth is it doing when one is not actually calibrating and profiling a PC? Why is it running?
-
On my Skylake PC, it's using an average of 0.02% of cpu. However, it's clearly doing something continually, as it generates around 1,000 page faults per second, all the time.
What on earth is it doing when one is not actually calibrating and profiling a PC? Why is it running?
yeah. sounds like a bug. think there was something like that on the Mac side a while back that Andrew discovered.
-
What on earth is it doing when one is not actually calibrating and profiling a PC? Why is it running?
What it is supposed to do is look out for connection of measurement devices and hand them off to their app. WHY this is necessary is beyond me, it never was in the past. It's nearly as buggy as useful. Huge engendering for little gain. Hook up USB device, software detects it, done. That's how ProfileMaker Pro and lots of older products worked. Progress?
-
What on earth could be going on to require what appears to me to be a monumental waste of my workstation's resources?
Typically that would be a bug - code that spins in a tight loop, waiting for something to happen.
Best practice is to use an operating system call that puts the thread to sleep while it's waiting, and wake it up when what it's waiting for becomes ready. Second best practice is to put a small sleep in the spin loop, so that the processor is idle most of the time.
-
Just experimenting on a PC, one can disable all the xrite stuff in start-up and task scheduler, and set the xrdd service to manual (not automatic). i1 profiler then grizzles that it can't find the device, and you have to start the xrdd service manually (and kill it afterwards unless you want it to continue running).
All the while it's running - on my system, anyway - xrdd.exe is using little cpu and memory (16M) but generating around 1,000 page faults per second. In the two or three minutes I've had it running it's clocked up 120,000 I/O operations. Not huge in the great scheme of things, but clearly not good programming to use any system resources at such a rate every second, for a device that's probably used no more than once a month.
Xrite are shining proof of the principle that companies can create good hardware or good software but very rarely both (Apple being one of the few exceptions). I also have a Colormunki Display, which uses different software, and the installer for that is defective and fails on some (perfectly sound) Windows configurations. It ends up loading the device driver 6 times - creating a restore point each time - during every installation on affected machines.