| Author |
Message |
|---|
 Michael Goetz Volunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 13620
ID: 53948
Credit: 266,694,965
RAC: 299,703
                           
|
|
We have upgraded the version of LLR used on all of our LLR projects to LLR v.3.8.21.
As with the previous version of LLR, it is available in 32 and 64 bit versions for Windows and Linux, and 64 bits for Mac OS.
This release has two major features:
* Support for AVX/FMA3 on AMD Ryzen CPUs. You can expect about a 10% increase in speed on Ryzen processors as compared to earlier versions of LLR.
* A rare bug that sometimes caused errors when using multithreading has been corrected.
If you are using app_info.xml (aka anonymous platform) please upgrade to the latest LLR. The wrapper is unchanged. Upgrading is not mandatory, but is strongly recommended.
If you are not using app_info.xml, you will automatically get the new version with your next LLR task and no action is necessary on your part. If you're not sure if you're using app_info.xml you're almost certainly not using it, and no action is necessary.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
It is interesting, is it possible that some WUs are wrong because of this rare bug?
Regards. |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 13620
ID: 53948
Credit: 266,694,965
RAC: 299,703
|
It is interesting, is it possible that some WUs are wrong because of this rare bug?
Regards.
No.
The bug caused random, non-repeatable errors. If both tasks in a workunit were affected by the bug, they wouldn't match each other. You would end up with individual tasks with validation errors rather than a workunit that finished with the wrong result. In the end, it's no different than any other random calculation error.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
How do we upgrade? |
|
|
dukebgVolunteer tester
Send message
Joined: 21 Nov 17
Posts: 240
ID: 950482
Credit: 23,670,125
RAC: 0
                 
|
How do we upgrade?
If you are not using app_info.xml, you will automatically get the new version with your next LLR task and no action is necessary on your part |
|
|
|
|
How do we upgrade?
If you are not using app_info.xml, you will automatically get the new version with your next LLR task and no action is necessary on your part
I am using app_info.xml |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 13620
ID: 53948
Credit: 266,694,965
RAC: 299,703
|
How do we upgrade?
If you are not using app_info.xml, you will automatically get the new version with your next LLR task and no action is necessary on your part
I am using app_info.xml
No, you're not. (The server knows when you use app_info.xml.) You may, perhaps, be using app_config.xml, but you're definitely not using app_info.xml. They're not the same.
No action is necessary by you. Any LLR tasks you are assigned from this point onwards will be v8.01, which is the new application. You've already got a few of the new tasks, for example:
http://www.primegrid.com/result.php?resultid=898859436
____________
My lucky number is 75898524288+1 |
|
|
|
|
How do we upgrade?
If you are not using app_info.xml, you will automatically get the new version with your next LLR task and no action is necessary on your part
I am using app_info.xml
No, you're not. (The server knows when you use app_info.xml.) You may, perhaps, be using app_config.xml, but you're definitely not using app_info.xml. They're not the same.
No action is necessary by you. Any LLR tasks you are assigned from this point onwards will be v8.01, which is the new application. You've already got a few of the new tasks, for example:
http://www.primegrid.com/result.php?resultid=898859436
Ah! I was getting app_config.xml and app_info.xml mixed up! Sorry for the misunderstanding!
Thanks for the clarification!
Cheers,
JR |
|
|
|
|
|
Besides other files, in my C:\ProgramData\BOINC\projects\www.primegrid.com folder I have:
cllr64.3.8.20.exe
cllr64.3.8.21.exe
primegrid_llr_wrapper_8.00_windows_x86_64.exe
primegrid_llr_wrapper_8.01_windows_x86_64.exe
Can I get rid of
cllr64.3.8.20.exe
and
primegrid_llr_wrapper_8.00_windows_x86_64.exe
or should I just let it be ?
|
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 13620
ID: 53948
Credit: 266,694,965
RAC: 299,703
|
Besides other files, in my C:\ProgramData\BOINC\projects\www.primegrid.com folder I have:
cllr64.3.8.20.exe
cllr64.3.8.21.exe
primegrid_llr_wrapper_8.00_windows_x86_64.exe
primegrid_llr_wrapper_8.01_windows_x86_64.exe
Can I get rid of
cllr64.3.8.20.exe
and
primegrid_llr_wrapper_8.00_windows_x86_64.exe
or should I just let it be ?
As long as you're POSITIVE that all of your 8.00 tasks are completed, then yes, you can delete them.
(Worst case scenario, should I need to roll back to v8.00 your computer would just download them again upon receipt of a new 8.00 task. That's not likely to happen, however.)
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
I run with zero cache (task buffer)
Just fresh tasks running.
Currently one PPS Sieve and two TRP are being crunched.
EDIT:
For now, I just renamed the two files to
_cllr64.3.8.20.exe and _primegrid_llr_wrapper_8.00_windows_x86_64.exe.
Will delete them if no errors come up. |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 13620
ID: 53948
Credit: 266,694,965
RAC: 299,703
|
|
Anyone with a Ryzen CPU want to comment about the performance of the new LLR?
____________
My lucky number is 75898524288+1 |
|
|
mackerelVolunteer tester
Send message
Joined: 2 Oct 08
Posts: 2529
ID: 29980
Credit: 491,132,366
RAC: 1,515,223
                        
|
Anyone with a Ryzen CPU want to comment about the performance of the new LLR?
A non-controlled comparison with live TRP-DC tasks from yesterday suggested my R7 1700 was about 6% slower than my i5-6600k, with the 1700 times normalised as it if were running at the same speed as the 6600k. These tasks are small enough that ram performance shouldn't impact it, although my 1700 might be somewhat hindered by slow ram as the internal cache speed is tied to it.
Will see if I can dig up enough older data before the update, but that comparison would be riskier.
I might try a more controlled comparison later.
BTW I believe the review embargo for Ryzen 2 is only over an hour away, so will be interesting to get one of those and see if they perform much differently from 1st gen. Leaks suggest there are some improvements leading to tangible gains. |
|
|
|
|
|
Just quick question as the app_config file (I found in the FORUM) seems not to work as intended (Work Unit is: llr321):
<app_config>
<app>
<name>LLRESP</name>
<fraction_done_exact/>
<max_concurrent>1</max_concurrent>
</app>
<app_version> <app_name>LLRESP</app_name>
<cmdline>-t 4</cmdline>
<avg_ncpus>4</avg_ncpus>
</app_version>
</app_config>
I would like that each LLR WU uses 4 threads of the CPU. I think it is the cmdline part: is it: -4 t or is: it -4t?
|
|
|
dthononVolunteer tester
Send message
Joined: 6 Dec 17
Posts: 401
ID: 957147
Credit: 1,563,733,912
RAC: 3,106,602
                      
|
|
If you want to run in multithreading for 321 subproject, then the name is llr321 and not LLRESP.
<app_version>
<app_name>llr321</app_name>
<cmdline>-t 4</cmdline>
<avg_ncpus>4</avg_ncpus>
</app_version>
|
|
|
|
|
If you want to run in multithreading for 321 subproject, then the name is llr321 and not LLRESP.
<app_version>
<app_name>llr321</app_name>
<cmdline>-t 4</cmdline>
<avg_ncpus>4</avg_ncpus>
</app_version>
Thanks! |
|
|
