I'm trying to get a few windows 2012 servers with 32GB or more memory to run the Python app and they all consistently fail import cv2

File "T:\Program Data\BOINC\slots\5\lib\site-packages\pytorchrl\envs\atari\wrappers.py", line 8, in <module>
import cv2
ImportError: DLL load failed while importing cv2: The specified module could not be found.

https://www.gpugrid.net/result.php?resultid=32907162
https://www.gpugrid.net/result.php?resultid=32907179
https://www.gpugrid.net/result.php?resultid=32907165
https://www.gpugrid.net/result.php?resultid=32907038

Is this part of the python app that is being downloaded and extracted or is it something else that's missing?

I'm wondering if it could be part of the Microsoft Visual C++ Redistributable that needs to be updated.

These currently have Microsoft Visual C++ Redistributable 2015-2019. Do they need to be updated to 2022?

If anyone has a Windows system that is successfully running Python apps it would be interesting to see what version of the VS is installed.

Anything else you could think of would be appreciated.

Update - Installing the Microsoft Visual C++ 2015-2022 Redistributable on these did not resolve the issue. They are still failing with the same error.

Since it seems that the missing module is not being included in the python app I will have to try finding it elsewhere and see if it can be installed separately.

Any thoughts on what's needed to resolve the Windows application errors would be appreciated.

If anyone has a Windows system that is successfully running Python apps it would be interesting to see what version of the VS is installed.

Anything else you could think of would be appreciated.

You should shoot Richard Haselgrove a PM and ask how he is able to run the Python tasks in Windows.

Richard knows a ton about Windows and BOINC.

You should shoot Richard Haselgrove a PM and ask how he is able to run the Python tasks in Windows.

Richard knows a ton about Windows and BOINC.

I can't - I'm only running Python on Linux at the moment.

My Windows machines have good enough GPUs, but they don't have enough system memory. And I haven't been able to get the "guaranteed compatible" RAM upgrade I bought to POST, let alone boot.

It's a low priority project - they can run ACEMD and Einstein for the time being.

Read this post of mine for help on Windows.

https://www.gpugrid.net/forum_thread.php?id=5322&nowrap=true#58908

This one is hardware. The Crucial system scanner detects that the OEM system builder (local gaming specialists) has installed Kingston KHX1866C10D3/4G RAM - note speed 1866.

It goes on to say that a Crucial 8GB DDR3L-1600 UDIMM upgrade is compatible - but I get nada, zilch, on power-up.

Motherboard is a Gigabyte GA-Z97P-D3, again as detected by Crucial (but it corresponds with system documentation and markings on the circuit board).

Can you get into the BIOS or is even that not possible?

I'd try and set the memory back down to base 800Mhz.

Then try putting in the new memory and see if it boots.

If it reads the new memory, try increasing the clock speed.

With apologies to the thread starter for taking it off topic:

I can get into the BIOS when the original build RAM (only) is present, but not if the 'compatible' upgrade RAM is present - either in conjunction with the original RAM, or by itself.

The working assumption has to be that the builder tuned the RAM timings for the 1866 RAM, and they would need de-tuning for the new stuff. But I'd need to set that 'flying blind', with only the old RAM installed, and I'd risk bricking the whole setup if I got that wrong. The alternatives could be:

Source some 1866 RAM for the upgrade - but nobody seems to be making/selling it now?

Contact the system builder - they're normally a friendly bunch, but tech support retreated behind a chatbot during the pandemic, and they hadn't emerged last time I looked. (and they're not selling 1866 RAM any more, either)

As I said, it's a low-priority job. If this project (or any project) offers applications which require me to deplete even more of the earth's resources in order to run them - that's their problem, not mine. My machines can carry on running other work, and being available for testing, as they have been since the last major refit.

With apologies to the thread starter for taking it off topic:

(With apologies for the same reason ;-)

I can get into the BIOS when the original build RAM (only) is present, but not if the 'compatible' upgrade RAM is present

I'd try to update BIOS to the latest for your GA-Z97P-D3 motherboard.
It is F9b Beta BIOS, but just "Fix memory compatibility" is mentioned at Version Description
Please, be sure to check and choose the right update for your MB revision.
GA-Z97P-D3 (rev. 1.0)
GA-Z97P-D3 (rev. 1.1)

Yup, saw that. I'm on F7 at the moment, which isn't too bad - F8 just improved support for 5th. gen Intel CPUs, which I haven't got.

Had a poke around the BIOS and memory settings today. Biggest warning flag seems to be that the builder's Kingston RAM (it's HyperX Fury) is running at 1.5V, whereas the Crucial is specc'd for 1.35V. It seems to be using SPD, but not XMP, and the configurable setting are all on auto.

I can move things around, so one machine is all Kingston, and another is all Crucial - avoiding mixing seems like a good idea.

No indication via software (or on the invoice) whether it's 1.0 or 1.1 - I'll have to open her up and shine a torch around.

I'd definitely update the BIOS.

Also I'd try a BIOS reset or clear to get rid of any builder's settings.

Well, I've got her up on the bench and under an inspection lamp. I was just about to conclude that "if it doesn't say rev 1.1, it must be 1.0" when I spotted the rev 1.1 mark deep in the darkest corner, behind 2 GPUs. Oops.

So, 1.1 it is - and it comes with a autoexec.bat file...

I'll try that at a command prompt under Windows 7, and see how I get on. I've just picked up an ACEMD 3 job, so I'll let that run overnight, and try swapping the RAM round tomorrow.

Guess what.


OK, that worked. Running the ACEMD now.

I think all the efiflash utilities are 16 bit DOS based.

Put a copy of FreeDOS on a USB stick along with the utility and firmware image and go to it.

That's what I did, basically.

There's a Q-Flash utility in the BIOS, which can read a USB drive.

Yay! Something's worked - probably the BIOS update. I've now got a machine running with twice the memory size - according to BIOS, Windows, and BOINC. It'll be a bit slower, because it's using the 1600 compatible RAM: but that means I've got two spare sticks of 1866 RAM to put in the next machine.

If I can squeeze it past the knuckle-grater of a heat sink. It's fitted with heat-spreaders, so I'll probably have to remove the CPU fan to gain access, and re-position it slightly higher up the heatsink to provide clearance.

And it seems to be attempting to run. It's got to 2.980%, and

13:38:39 (3360): .\7za.exe exited; CPU time 8.626855
13:38:39 (3360): wrapper: running python.exe (run.py)
Windows fix!!
Created CWorker with worker_index 0
Created GWorker with worker_index 0
Created UWorker with worker_index 0
Created training scheme.
Created Learner.

But that's in 1 hour 50 minutes.

CPU is over-committed (I haven't added Python to the app_config yet, so it's still allocating <1 CPU in BOINC's scheduler. I'll finesse that next.)

We can watch task 32918800 together.

Progress!

The plucky little thing has progressed to 19.640% in 9 hours - might even get an intermediate (1-2 day) bonus! It's not brilliant, but for a January 2016 build, with a 4-core, 4th. gen. i5, Windows 7, it's doing its best to keep up. I'm shutting down as much else as I can, and I'll post the virtual memory settings when/if this task succeeds.

We have a home run for task 32918800

From stderr:
13:38:39 (3360): wrapper: running python.exe (run.py) [Tuesday]
02:40:32 (3360): python.exe exited; CPU time 301601.725332 [Thursday]

So Python ran for a little over 37 hours (133,200 seconds), with an average CPU utilisation of 2.26.

This machine is fitted with a GTX 1660 Ti, the same as Linux host 508381. That hosts completes the tasks in about 14 hours. So, either the operating system, or - I suspect - the host CPU, is significantly slower in Windows than in Linux.

The Windows host has a 4-core i5-4690 CPU @ 3.50GHz
The Linux host has a 6-core i5-9600K CPU @ 3.70GHz
Both machines (now!) have 16 GB of RAM