Somewhere between 30 and 40 hours. S5 work units take about twice as long as s4 work units did with the stock app. The work units are 5x as long and the app 2.5-3x faster than the stock app.
Is S5T0308 working? I turned 2 units in, both have the other turned in and the message, Checked, but no consensus yet. I can see one, but never saw two in a row before. Could be the other system also. It did cut the time down from ~15 Hours to 11 Hours. Have S5T0709, SSE3 running good on the other system.
Just installed S5T0711.dat, will see how that is working.
I was wondering if the last section in your app_info.xml should be like:
Quote:
einstein_S5R1
410
einstein_S5R1_4.10_windows_intelx86.exe
einstein_S5R1_4.10_windows_intelx86.pdb
I think you'll find that the executable does not rely on or even pay any attention to a .pdb reference in the app_info.xml. Possibly such entries serve as a form of human reminder note of the need for the file, but I think they are probably best regarded as clutter. I've not seen direct evidence that any file save the executable needs to be referenced.
Is S5T0308 working? I turned 2 units in, both have the other turned in and the message, Checked, but no consensus yet. I can see one, but never saw two in a row before. Could be the other system also. It did cut the time down from ~15 Hours to 11 Hours. Have S5T0709, SSE3 running good on the other system.
Just installed S5T0711.dat, will see how that is working.
There are a few 'issues' with the threads on the new clients.
1.) The application/.dat thread is not being updated while new patches are released in this thread. The app/.dat thread also is not marking apps known to produce invalid results as such. That's an issue if people are downloading 'abandoned' apps - it's a waste of time.
I would say that that not marking patches that produce invalids is one of the biggest 'issues'. This is mostly because the patches are coming out so frequently.
2.) The app_info.xml is a major issue as it is not addressed in the app thread. It is addressed here and is helpful; the problem is that this thread has lots of posts and is probably not the greatest place to put instructions on how to modify files, etc. That is, since we're probably wanting a standardized setup and to mitigate the confusion (and arguments :)) it might be helpful to start updating the app/.dat thread.
Steve & James
Thank you very much. 468 post on this thread can make one showing that a patch is bad hard to find.
I just posted S5T0308 to the invalids listing.
This may need a few diferant threads such as
1) New Dat files (no discussion allowed)
2) App_info files (no other discussion)
3) Invallid (Already expists)
any others that keep arrizeing over and over.
[EDIT BELOW]
--------------------------------
On my other system with SSE3 the S5T0711.dat file seems to be working good, cut the time down from 13 hr's to 9 hours. Will not update that till there is one that improves on that and is known to be stable.
Can't camplain about lost time on this machine, only by testing will we know which work.
Cheers
Ray
There are a few 'issues' with the threads on the new clients.
1.) The application/.dat thread is not being updated while new patches are released in this thread. The app/.dat thread also is not marking apps known to produce invalid results as such. That's an issue if people are downloading 'abandoned' apps - it's a waste of time.
I would say that that not marking patches that produce invalids is one of the biggest 'issues'. This is mostly because the patches are coming out so frequently.
2.) The app_info.xml is a major issue as it is not addressed in the app thread. It is addressed here and is helpful; the problem is that this thread has lots of posts and is probably not the greatest place to put instructions on how to modify files, etc. That is, since we're probably wanting a standardized setup and to mitigate the confusion (and arguments :)) it might be helpful to start updating the app/.dat thread.
I neglected to fully explain one of my concerns noted above. When a patch/app is known to be invalid but is not posted as such in the 'official' read-only thread for downloads people keep downloading them.
This is not just a 'waste of time' for the people who download patches that are known to produce invalid thread. It has 'knock on' effects for the rest of the project. That is, by continuing to use invalid patches a third machine must validate the two already reported results. This is a problem; basically what should be an alpha project with minimal effects on the 'stock' project is turning into a project where the stable clients are 'subsidizing' the optimized clients that are no good.
So...people check out the download page more frequently than the invalids. All invalid producing patches must be marked as such (if not removed).
How about a listserv for those of us using the optimized clients? That might be a good way to keep everyone up to date on what patches not to use anymore.
With some of these improvements implemented we might be able to cut down on the need for the stable clients to have to verify our invalid results:) It would also be helpful as the ultimate aim of this project is to produce the maximum number of valid results, which can even be done with the test patches as long as people are aware of a 'bad' patch.
After finishing the work I had, I made an app_info.xml from the code Stick quoted, made sure I had a 4.10 named exectuable, and patched it up to S5T0712 which was the newest version I saw with valid results reported here. I got a few short work units when I turned on work requests again, and one has been sent in. It finished in less than 1 hour and was done in about 70% of the time as the first short work unit I did with the standard application -- nice improvement. It hasn't validated yet, but given the positive reports of the S5T0712 patch here, I expect it to be good. And it reported back as "E@H S5R1 4.10 0712 TEST", so the modified version number has been picked up correctly from app_info.xml.
Aside: It looks like Einstein has change the credit granting system so that it's more uniform and less dependent on time, benchmarks, or whatever. Does that mean I can turn off calibration by my client, report the real CPU time with the optimized application, and still be fine? I'd rather report the real crunching time if calibration isn't necessary to claim and get the right credit (which it was before). Thanks.
Somewhere between 30 and 40
)
Somewhere between 30 and 40 hours. S5 work units take about twice as long as s4 work units did with the stock app. The work units are 5x as long and the app 2.5-3x faster than the stock app.
Is S5T0308 working? I turned
)
Is S5T0308 working? I turned 2 units in, both have the other turned in and the message, Checked, but no consensus yet. I can see one, but never saw two in a row before. Could be the other system also. It did cut the time down from ~15 Hours to 11 Hours. Have S5T0709, SSE3 running good on the other system.
Just installed S5T0711.dat, will see how that is working.
Try the Pizza@Home project, good crunching.
Hi Udo, I was wondering if
)
Hi Udo,
I was wondering if the last section in your app_info.xml should be like:
since you have included an einstein_S5R1_4.10_windows_intelx86.pdb in you zip?
Regards,
Yin Gang
Welcome To Team China!
RE: Hi Udo, I was
)
I think you'll find that the executable does not rely on or even pay any attention to a .pdb reference in the app_info.xml. Possibly such entries serve as a form of human reminder note of the need for the file, but I think they are probably best regarded as clutter. I've not seen direct evidence that any file save the executable needs to be referenced.
Please advise if I am wrong on this point.
My X2 is still calculating
)
My X2 is still calculating some S4 Units and so this app_info.xml file does the job very well:
albert
albert_4.37_windows_intelx86.exe
albert_4.37_windows_intelx86.pdb
albert_4.50_windows_intelx86.exe
albert_4.50_windows_intelx86.pdb
albert_4.62_windows_intelx86.exe
albert_4.62_windows_intelx86.pdb
albert
437
albert_4.37_windows_intelx86.exe
albert_4.37_windows_intelx86.pdb
albert
450
albert_4.50_windows_intelx86.exe
albert_4.50_windows_intelx86.pdb
albert
462
albert_4.62_windows_intelx86.exe
albert_4.62_windows_intelx86.pdb
einstein_S5R1
einstein_S5R1_4.02_windows_intelx86.exe
einstein_S5R1_4.10_windows_intelx86.exe
einstein_S5R1
402
einstein_S5R1_4.02_windows_intelx86.exe
einstein_S5R1
410
einstein_S5R1_4.10_windows_intelx86.exe
RE: Is S5T0308 working? I
)
S5T0308 was not good and should not be used
98SE XP2500+ @ 2.1 GHz Boinc v5.8.8
There are a few 'issues' with
)
There are a few 'issues' with the threads on the new clients.
1.) The application/.dat thread is not being updated while new patches are released in this thread. The app/.dat thread also is not marking apps known to produce invalid results as such. That's an issue if people are downloading 'abandoned' apps - it's a waste of time.
I would say that that not marking patches that produce invalids is one of the biggest 'issues'. This is mostly because the patches are coming out so frequently.
2.) The app_info.xml is a major issue as it is not addressed in the app thread. It is addressed here and is helpful; the problem is that this thread has lots of posts and is probably not the greatest place to put instructions on how to modify files, etc. That is, since we're probably wanting a standardized setup and to mitigate the confusion (and arguments :)) it might be helpful to start updating the app/.dat thread.
Steve & James Thank you very
)
Steve & James
Thank you very much. 468 post on this thread can make one showing that a patch is bad hard to find.
I just posted S5T0308 to the invalids listing.
This may need a few diferant threads such as
1) New Dat files (no discussion allowed)
2) App_info files (no other discussion)
3) Invallid (Already expists)
any others that keep arrizeing over and over.
[EDIT BELOW]
--------------------------------
On my other system with SSE3 the S5T0711.dat file seems to be working good, cut the time down from 13 hr's to 9 hours. Will not update that till there is one that improves on that and is known to be stable.
Can't camplain about lost time on this machine, only by testing will we know which work.
Cheers
Ray
Try the Pizza@Home project, good crunching.
RE: There are a few
)
I neglected to fully explain one of my concerns noted above. When a patch/app is known to be invalid but is not posted as such in the 'official' read-only thread for downloads people keep downloading them.
This is not just a 'waste of time' for the people who download patches that are known to produce invalid thread. It has 'knock on' effects for the rest of the project. That is, by continuing to use invalid patches a third machine must validate the two already reported results. This is a problem; basically what should be an alpha project with minimal effects on the 'stock' project is turning into a project where the stable clients are 'subsidizing' the optimized clients that are no good.
So...people check out the download page more frequently than the invalids. All invalid producing patches must be marked as such (if not removed).
How about a listserv for those of us using the optimized clients? That might be a good way to keep everyone up to date on what patches not to use anymore.
With some of these improvements implemented we might be able to cut down on the need for the stable clients to have to verify our invalid results:) It would also be helpful as the ultimate aim of this project is to produce the maximum number of valid results, which can even be done with the test patches as long as people are aware of a 'bad' patch.
After finishing the work I
)
After finishing the work I had, I made an app_info.xml from the code Stick quoted, made sure I had a 4.10 named exectuable, and patched it up to S5T0712 which was the newest version I saw with valid results reported here. I got a few short work units when I turned on work requests again, and one has been sent in. It finished in less than 1 hour and was done in about 70% of the time as the first short work unit I did with the standard application -- nice improvement. It hasn't validated yet, but given the positive reports of the S5T0712 patch here, I expect it to be good. And it reported back as "E@H S5R1 4.10 0712 TEST", so the modified version number has been picked up correctly from app_info.xml.
Aside: It looks like Einstein has change the credit granting system so that it's more uniform and less dependent on time, benchmarks, or whatever. Does that mean I can turn off calibration by my client, report the real CPU time with the optimized application, and still be fine? I'd rather report the real crunching time if calibration isn't necessary to claim and get the right credit (which it was before). Thanks.