Erik: thanks, I didn't even know this was possible.

I would think Win10 on a USB stick would a be painful experience (slow).

That's what the USB stick certification from MS is about: only allowing drives which are not painfully slow.

MrS

---

Scanning for our furry friends since Jan 2002

it is portabke between all host machines.

Ahh... Nice to know.

It seems Microsoft don't insist on licensing each host individually, but rely on the PC being covered by Software Assurance.

This is for Windows 8.1, I assume is the same for Win10.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-8.1-and-8/jj592680(v=ws.11)
See heading How is Windows To Go licensed?

I am not sure if this was an anomaly or not but I did get a "usb windows 10" stick to boot and be activated.

Background: I bought several used HPZ-400 motherboards on eBay. They are all licensed for windows 7 due to having an SLIC2.1 in the bios. The activation code for windows 7 pro is the same generic HP windows 7 pro key so all these systems can legally run win7pro as the license is bound to the system and the key is listed all over the internet.

I installed windows 7 on 2 mombos and did that still free upgrade to 10. According to one of the Microsoft MVP'ers it was not necessary to activate on windows 7, I could have put in 10 and simply used my windows 7 HP key. While I did not try that I did install 7 pro and upgraded to 10 pro using a USB stick on mombo #2. I then put that USB stick in the 3rd HPZ-400 mombo and was able to activate it. However, I had named the 3rd system the same name as the 2nd and I had registered the 2nd one on Microsoft's web site as one of my devices. Later I changed the name of that 2nd one and all three were working just fine wind10pro.

I suspect if the motherboard has an SLIC2.1 license then a USB win10 stick can boot and be activated using the generic win7pro license from the original vendor (dell, hp, etc)

Just a guess.

Any word on the status of acemd3? Last I saw there was a hold up due to a Windows (10?) issue.

Haven't heard a peep either. Still waiting on Windows app I guess.

Toni is trying out a new acemd3 application. 2.04 works as well as the previous 2.03 version. Still having issues getting the Windows app to work consistently.

He has a new thread. https://www.gpugrid.net/forum_thread.php?id=4955

We are still dreaming of Linux app :з

We are still dreaming of Linux app :з

My RTX 2080Ti's eagerly waiting for the acemd3 Linux app.
My ranking in SETI@home has risen by 43,140 in the meantime. (51,148 -> 8,008)

We have an application working to new application but forced to wait on win. Not fair when our old application expired.

Backup project very happy but my goal with gpus are lost.
(linux user)

Hi,

Will the new version support Titan V CUDA 7.0?

Thanks

Hi,

Will the new version support Titan V CUDA 7.0?

Thanks

I would assume so.

I setup for some acemd3 if any WU drop then I'll see what happens

I setup for some acemd3 if any WU drop then I'll see what happens

The wrapper app is able to handle CC capabilities of up to 7.5 for Turing cards. So your Titan V should be good to go

Problem is getting some of the test tasks. I have been hammering the project since the announcement of the new acemd3 apps and I have yet to receive one.

I hope that Toni releases some more work so I can get back to crunching for this project.

I had no issues with the test versions back in July. Want some more work to get the latest apps.

I'm really dissatisfied with the new acemd3 tasks for the following reasons:

*The app always spins a whole CPU thread. With the old app, you could configure this behaviour using the SWAN_SYNC environment variable. It made almost no difference with the old app for me (like half a percent in GPU utilization), so I would prefer the app to leave some cycles for a CPU-only task instead.

*The wrapper spawns the acemd3 process with the lowest priority possible (nice 19). If you configure BOINC to run GPU tasks with a higher priority, only the wrapper has higher priority this way. The wrapper should instead spawn the acemd3 process with the same nice value that it has itself.

*The credit you get for these work units seems to be way off, I only get little more than half of the credit per hour that I get with acemd2 work units

i have build 4 rigs (with 24 gpu cards, gtx 1070, gtx 1080, gtx 1080 ti and rtx cards, all mixed together) special for gpugrid. but after summer vacation i have impression that this project is nearly dead. because after summer i dont get any WU to crunch (2 rigs with 12* gtx 1070 only) while before summer no problems at all.

so, i am leaving gpugrid, going to F@H (folding @ home) with my hardware.

bye bye gpugrid

I'm really dissatisfied with the new acemd3 tasks for the following reasons:

*The app always spins a whole CPU thread. With the old app, you could configure this behaviour using the SWAN_SYNC environment variable. It made almost no difference with the old app for me (like half a percent in GPU utilization), so I would prefer the app to leave some cycles for a CPU-only task instead.

That's true under Windows Vista+ because of WDDM. Linux and Windows XP have significant performance benefit from SWAN_SYNC.

*The wrapper spawns the acemd3 process with the lowest priority possible (nice 19). If you configure BOINC to run GPU tasks with a higher priority, only the wrapper has higher priority this way. The wrapper should instead spawn the acemd3 process with the same nice value that it has itself.

This should be corrected.

*The credit you get for these work units seems to be way off, I only get little more than half of the credit per hour that I get with acemd2 work units

That's because this is beta work, and work from the short queue.

*The wrapper spawns the acemd3 process with the lowest priority possible (nice 19). If you configure BOINC to run GPU tasks with a higher priority, only the wrapper has higher priority this way. The wrapper should instead spawn the acemd3 process with the same nice value that it has itself.

This should be corrected.

The wrapper app can handle that - see https://boinc.berkeley.edu/trac/wiki/WrapperApp#Thejobdescriptionfile: the final parameter in the job description file should be 2 (I think).

If you're running a test task, you should be able to see and change that value. If changing it doesn't correct the problem, we'll have to dig deeper.

i am leaving gpugrid, going to F@H (folding @ home) with my hardware. bye bye gpugrid

You'll be back when you get tired of F@H's buggy software.

---

That's true under Windows Vista+ because of WDDM. Linux and Windows XP have significant performance benefit from SWAN_SYNC.

Well, when I played around with SWAN_SYNC about a year ago on Linux, there definitely was a small performance benefit, but it was so minimal that I decided it's not worth sacrificing half a CPU core for it for me.

That's because this is beta work, and work from the short queue.

Ah, so the tasks for acemd3 are just tasks that have been moved over from the "Short runs" application? Makes sense. Is there any particular reason why the "short runs" give much less credit than the "long runs" for the same runtime?

For the "TEST" work units, I figured that they give less credit because they are just tests. Is it possible to opt-out of test work units?

The wrapper app can handle that - see https://boinc.berkeley.edu/trac/wiki/WrapperApp#Thejobdescriptionfile: the final parameter in the job description file should be 2 (I think).

If you're running a test task, you should be able to see and change that value. If changing it doesn't correct the problem, we'll have to dig deeper.

This would solve the problem, but I'm pretty sure that BOINC verifies the files and re-downloads them if they have been altered...

The wrapper app can handle that - see https://boinc.berkeley.edu/trac/wiki/WrapperApp#Thejobdescriptionfile: the final parameter in the job description file should be 2 (I think).

If you're running a test task, you should be able to see and change that value. If changing it doesn't correct the problem, we'll have to dig deeper.

This would solve the problem, but I'm pretty sure that BOINC verifies the files and re-downloads them if they have been altered...

You could still inspect the file and confirm whether GPUGrid have deployed it properly. A local edit wouldn't be permanent, for the reasons you state, but an edit to a task that has downloaded but not yet started might last for long enough for you to observe and report back.