James
I have to agree with that 100%.
On the download pages the info about the bad ones I think can stay, but the links to the DAT files should be eliminated.
I have a listserver at my server, I can set the list up if you think if would be used.
Cheers
Ray
Quote:
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.
The credit of S5 WU is pre-assigned on server side.
Quote:
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.
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.
Credit is predetermined server side regardless of your claim, so no calibration is needed.
Terry
edit: Oops, looks like Yin Gang and I were giving the same answer at the same time.
Simultaneous answers happen sometimes. :) Thanks, I just wanted to check and make sure before I changed anything. I'll have to see if calibration is actually needed on my other projects; I might be able to just dump the calibrating client all together.
My other two short work units should report back within a few hours. Maybe I'll have real validation status by tomorrow morning when I wake up. (It's almost bed time for me here.)
I just started a email list for the anouncement and discussion of optomized Einstein Applications. All are invited to join and share info there, finding things in the Archives (now empty as new) should be easier by the subject rather than searching through hundreds of postings in one thread.
You can get info on this and sign up at: This link
2006-06-26 10:00:08.9896 [normal]: E@H S5R1 4.02 0711 TEST
2006-06-26 10:00:08.9896 [normal]: Started search at lalDebugLevel = 0
2006-06-26 10:00:09.6771 [normal]: Checkpoint-file 'Fstat.out.ckp' not found.
2006-06-26 10:00:09.6771 [normal]: No usable checkpoint found, starting from beginning.
Detected CPU type 1
Unhandled Exception Detected...
- Unhandled Exception Record -
Reason: Access Violation (0xc0000005) at address 0x00400400
Standard: ~41,800 S5T0712: 27,518
About 35% faster
You don't need waiting to cache out. You can edit your client_state.xml :
- all strings "einstein_S5R1_4.02_windows_intelx86" replace "einstein_S5R1_4.10_windows_intelx86"
- all strings "version_num>402410"
And of course put into E@H project directory files app_info.xml, einstein_S5R1_4.10_windows_intelx86.exe and einstein_S5R1_4.10_windows_intelx86.pdb
Example of WU which was edited by this technique is here
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 get the impression that Akofs is using that thread more as a public release of the 'Stable' apps only. Good idea really as not everyone wants to be a tester which is what we are doing in this thread. Testing all the latest patches to determine the 'stable' ones. When Akosf believes a specific patch can be considered stable he can release it for everyone in that thread (just a figure of speech- of course anyone can just come to this thread and download whichever they like) and they can use that 'stable' patch knowing it has been fully tested and should be safe and cause them no trouble.
I agree the app_info could be clarified by either Bernd or Akosf and let us all know exactly what them mean and what they would like us to do more clearly. Why i asked
Quote:
Once we get all this sorted it might be a good idea to start this thread afresh. Starting with a new set of instructions and fresh links to the latest stable/test app and a known working app_info.xml file. Basically all that’s needed to continue from here with as little confusion as possible. This thread is getting very long too.
I'd prefer if I could ask that Akosf be the one to decide when its time to do this when he's decided what the next 'stable' release is maybe, and when he and Bernd have sorting things out in the background.
Quote:
but i doubt we at that stage yet and yea your right it would be nice if people could edit their posts to include info on invalid patches but sometimes its too late so maybe they could remove the files wherever so cant be downloaded?
Mush easier-if your worried about getting invalids then stick to the latest 'Stable' releases only. They're updated fairly regularly and you can be sure there safe. Or stay a few patches behind the latest 'beta' patch and you'll get responses from people that have tried them informing if they get valids or invalids. These are all just suggestions. There's always risk when running test patches/apps.
James I have to agree with
)
James
I have to agree with that 100%.
On the download pages the info about the bad ones I think can stay, but the links to the DAT files should be eliminated.
I have a listserver at my server, I can set the list up if you think if would be used.
Cheers
Ray
Try the Pizza@Home project, good crunching.
The credit of S5 WU is
)
The credit of S5 WU is pre-assigned on server side.
Welcome To Team China!
RE: Aside: It looks like
)
Credit is predetermined server side regardless of your claim, so no calibration is needed.
Terry
edit: Oops, looks like Yin Gang and I were giving the same answer at the same time.
Simultaneous answers happen
)
Simultaneous answers happen sometimes. :) Thanks, I just wanted to check and make sure before I changed anything. I'll have to see if calibration is actually needed on my other projects; I might be able to just dump the calibrating client all together.
My other two short work units should report back within a few hours. Maybe I'll have real validation status by tomorrow morning when I wake up. (It's almost bed time for me here.)
I just started a email list
)
I just started a email list for the anouncement and discussion of optomized Einstein Applications. All are invited to join and share info there, finding things in the Archives (now empty as new) should be easier by the subject rather than searching through hundreds of postings in one thread.
You can get info on this and sign up at:
This link
Ray Brown
Try the Pizza@Home project, good crunching.
RE: RE: S5T0713.dat -
)
thx for the zipped .exe and all :)
S5T0711 won't run on AMD
)
S5T0711 won't run on AMD Opteron 280:
- exit code -1073741819 (0xc0000005)
2006-06-26 10:00:08.9896 [normal]: E@H S5R1 4.02 0711 TEST
2006-06-26 10:00:08.9896 [normal]: Started search at lalDebugLevel = 0
2006-06-26 10:00:09.6771 [normal]: Checkpoint-file 'Fstat.out.ckp' not found.
2006-06-26 10:00:09.6771 [normal]: No usable checkpoint found, starting from beginning.
Detected CPU type 1
Unhandled Exception Detected...
- Unhandled Exception Record -
Reason: Access Violation (0xc0000005) at address 0x00400400
S5T0709 seems to work.
Metod ...
S5T0712- Valid and credit
)
S5T0712- Valid and credit granted.
For now it's still 4.02 till i can run my cache out.
http://einsteinathome.org/task/35150680
Standard: ~41,800
S5T0712: 27,518
About 35% faster
RE: S5T0712- Valid and
)
You don't need waiting to cache out. You can edit your client_state.xml :
- all strings "einstein_S5R1_4.02_windows_intelx86" replace "einstein_S5R1_4.10_windows_intelx86"
- all strings "version_num>402410"
And of course put into E@H project directory files app_info.xml, einstein_S5R1_4.10_windows_intelx86.exe and einstein_S5R1_4.10_windows_intelx86.pdb
Example of WU which was edited by this technique is here
RE: There are a few
)
I get the impression that Akofs is using that thread more as a public release of the 'Stable' apps only. Good idea really as not everyone wants to be a tester which is what we are doing in this thread. Testing all the latest patches to determine the 'stable' ones. When Akosf believes a specific patch can be considered stable he can release it for everyone in that thread (just a figure of speech- of course anyone can just come to this thread and download whichever they like) and they can use that 'stable' patch knowing it has been fully tested and should be safe and cause them no trouble.
I agree the app_info could be clarified by either Bernd or Akosf and let us all know exactly what them mean and what they would like us to do more clearly. Why i asked