Just started up a task with 4.36. Seems to be working fine. Graphics are fine, although I didn't switch during a task like some of the rest of you did...
Projections based on the first few minutes of runtime show a shorter completion than any of my previous results processed with version 4.32, but definitely not 20% shorter. Looks right now like about 10%, but this is only an early projection... By the time I know for sure, the result will have finished...as I'm going to bed soon...
It happens that I have switched over whilst I am doing frequency 903.85 and sequence 420 (about 50% done with 4.32). This happens to be the trough of the cycle I am running down.
Sequence unit 421 done on 4.32 was under 27,000 seconds, which I was happy with, if this goes faster still I will be VERY happy.
A 10% improvement on say 26,500 seconds will lower the time to 23,850 seconds and a 20% improvement will lower to 21,200 seconds, so I will wait and see how it goes.
I will very happy with 10% improvement.
It also means my peak times are much lower as well.
Congratulations to the Einstein Project Team for the continued improvement to the programmes we are running for them.
First estimates show my new task to go run in just under 12 hours. The one started with 4.26 (continued with 4.32) ran in 17 hours. The one started with 4.32 (continued with 4.36) ran in 15 hours. I have good hopes.
First estimates show my new task to go run in just under 12 hours. The one started with 4.26 (continued with 4.32) ran in 17 hours. The one started with 4.32 (continued with 4.36) ran in 15 hours. I have good hopes.
I build my own BOINC 5.10.43 with all the latest fixes. Copied over my BOINC data directory to a testing directory. Put the BOINC 5.10.43 files in it and started running it. Then checked the graphics.
In 5.10 I see everything in the graphics, so including my own data, the clock and the search information, thereby excluding my video card to be the culprit. As a conclusion, it's BOINC 6.1.8 which doesn't play nice yet.
I build my own BOINC 5.10.43 with all the latest fixes. Copied over my BOINC data directory to a testing directory. Put the BOINC 5.10.43 files in it and started running it. Then checked the graphics.
In 5.10 I see everything in the graphics, so including my own data, the clock and the search information, thereby excluding my video card to be the culprit. As a conclusion, it's BOINC 6.1.8 which doesn't play nice yet.
I see. For the bug report: there must be a "key" the BOINC core client writes into the "boinc init data" that tells the the graphics app where to find the shared memory segment with the progress information. Looks like this is broken (or at least different) in the 6.1.8 core client.
For the bug report: there must be a "key" the BOINC core client writes into the "boinc init data" that tells the the graphics app where to find the shared memory segment with the progress information. Looks like this is broken (or at least different) in the 6.1.8 core client.
Not in any of the xml files. I have just about checked them all and can't find anything different between them for Einstein. I'm happy to send you the init_data.xml files and client_state.xml files for you to scrutinize.
But I'm pretty sure it's something in the way that boinc.exe executes the graphics.
Else just tell me what you need and I'll zip it up and email it to you, per BOINC version.
First estimates show my new task to go run in just under 12 hours. The one started with 4.26 (continued with 4.32) ran in 17 hours. The one started with 4.32 (continued with 4.36) ran in 15 hours. I have good hopes.
for 4.32 which is almost a 31% improvement in estimated productivity, and considerable reduction, in variance, though not to so low a level as the estimate you show.
I have some reservations about the model fit, especially for the Q6600, where there is more noise in the CPU times than is good for Ready Reckoner's digestion, but I have no reservations about saying that for Conroe-type Windows XP hosts 4.36 is a major improvement over 4.32, by rather more than 20% on the average, and possibly near or even over the upper end of my first estimate of 20 to 30% productivity per hour improvement, with a considerable reduction of variance from recent versions.
I have some reservations about the model fit, especially for the Q6600, where there is more noise in the CPU times than is good for Ready Reckoner's digestion, but I have no reservations about saying that for Conroe-type Windows XP hosts 4.36 is a major improvement over 4.32, by rather more than 20% on the average, and possibly near or even over the upper end of my first estimate of 20 to 30% productivity per hour improvement, with a considerable reduction of variance from recent versions.
Thanks for the comparison data!!
A considerable reduction of variance is exactly what was hoped for and expected by one of the improvements that went into 4.36. Basically, there are two relatively tiny parts of the science app that consume the vast majority of processing time. Of these two "hot-spots" or "hot-loops", one has constant processing time while the second one is more data dependent and causes this cyclic runtime variations.
The new improvements in 4.36 speed up the second hot-loop more than the first, so the variance should drop. Because of this, the speed-up of 4.36 over 4.32 will not be a uniform factor, but will be smaller for "runtime trough" tasks and greater for "peak runtime" tasks.
Just started up a task with
)
Just started up a task with 4.36. Seems to be working fine. Graphics are fine, although I didn't switch during a task like some of the rest of you did...
Projections based on the first few minutes of runtime show a shorter completion than any of my previous results processed with version 4.32, but definitely not 20% shorter. Looks right now like about 10%, but this is only an early projection... By the time I know for sure, the result will have finished...as I'm going to bed soon...
Second unit finished, a few
)
Second unit finished, a few seconds longer to crunch.
Downloaded and started as 4.36 graphics work here.
It happens that I have
)
It happens that I have switched over whilst I am doing frequency 903.85 and sequence 420 (about 50% done with 4.32). This happens to be the trough of the cycle I am running down.
Sequence unit 421 done on 4.32 was under 27,000 seconds, which I was happy with, if this goes faster still I will be VERY happy.
A 10% improvement on say 26,500 seconds will lower the time to 23,850 seconds and a 20% improvement will lower to 21,200 seconds, so I will wait and see how it goes.
I will very happy with 10% improvement.
It also means my peak times are much lower as well.
Congratulations to the Einstein Project Team for the continued improvement to the programmes we are running for them.
First estimates show my new
)
First estimates show my new task to go run in just under 12 hours. The one started with 4.26 (continued with 4.32) ran in 17 hours. The one started with 4.32 (continued with 4.36) ran in 15 hours. I have good hopes.
RE: First estimates show my
)
First estimates from Mike's Ready Reckoner:
App 4.32:
App 4.36:
Same host, same frequency.
Bernd, I build my own
)
Bernd,
I build my own BOINC 5.10.43 with all the latest fixes. Copied over my BOINC data directory to a testing directory. Put the BOINC 5.10.43 files in it and started running it. Then checked the graphics.
In 5.10 I see everything in the graphics, so including my own data, the clock and the search information, thereby excluding my video card to be the culprit. As a conclusion, it's BOINC 6.1.8 which doesn't play nice yet.
RE: Bernd, I build my own
)
I see. For the bug report: there must be a "key" the BOINC core client writes into the "boinc init data" that tells the the graphics app where to find the shared memory segment with the progress information. Looks like this is broken (or at least different) in the 6.1.8 core client.
BM
BM
RE: For the bug report:
)
Not in any of the xml files. I have just about checked them all and can't find anything different between them for Einstein. I'm happy to send you the init_data.xml files and client_state.xml files for you to scrutinize.
But I'm pretty sure it's something in the way that boinc.exe executes the graphics.
Else just tell me what you need and I'll zip it up and email it to you, per BOINC version.
RE: RE: First estimates
)
I've been wondering whether 4.36 gives a big reduction in variance. Your estimate suggests this is spectacular. (.261 going down to .102)
This morning I did some selective pausing to move a few results pretty near peaks into play. With that aid to accuracy, my E6600 shows:
for 4.36, compared to
for 4.32 which is almost a 31% improvement in estimated productivity, and considerable reduction, in variance, though not to so low a level as the estimate you show.
For my Q6600:
for 4.36
for 4.32
I have some reservations about the model fit, especially for the Q6600, where there is more noise in the CPU times than is good for Ready Reckoner's digestion, but I have no reservations about saying that for Conroe-type Windows XP hosts 4.36 is a major improvement over 4.32, by rather more than 20% on the average, and possibly near or even over the upper end of my first estimate of 20 to 30% productivity per hour improvement, with a considerable reduction of variance from recent versions.
RE: I have some
)
Thanks for the comparison data!!
A considerable reduction of variance is exactly what was hoped for and expected by one of the improvements that went into 4.36. Basically, there are two relatively tiny parts of the science app that consume the vast majority of processing time. Of these two "hot-spots" or "hot-loops", one has constant processing time while the second one is more data dependent and causes this cyclic runtime variations.
The new improvements in 4.36 speed up the second hot-loop more than the first, so the variance should drop. Because of this, the speed-up of 4.36 over 4.32 will not be a uniform factor, but will be smaller for "runtime trough" tasks and greater for "peak runtime" tasks.
CU
Bikeman