***UNHANDLED EXCEPTION****
Reason: Access Violation (0xc0000005) at address 0x0040AA13 read attempt to address 0x01002458
There are a look-up table reading, that is based on a dirty stack usage.
Probably the new codes (41.xx) don't have this problem, because they use statical look-up tables.
I had one of those too. The vast majority of my S40.12 results had no problems, but I did have one interesting anomaly on another result crunched by the same box that generated the Access Violation error. Even though it spent a few hours crunching out the result, and the result validated properly, it reported zero hours CPU time and claimed zero credit. Fortunately, the other boxes that crunched it did claim credit, so I received credit. Weird, no?
BTW, I also experienced slowdowns running S40.12 on HT systems, so all my HTs are back to running S40.04 whereas I've now upgraded all my SSE-compatible non-HTs to S41.06. Thanks, Akos, for the awesome improvements!
...(snipped)...BTW, I also experienced slowdowns running S40.12 on HT systems, so all my HTs are back to running S40.04 whereas I've now upgraded all my SSE-compatible non-HTs to S41.06.
On my 3GHz P4 Prescott w/HT enabled I swapped S39L to S40.04. But S40.04 ran 2 minutes longer so I switched back to S39L. Based on my comprehension of the msg thread discussions I'm not convinced that any of Akos' later versions would be any faster on my machine than S39L so I haven't experimented with them. You state that all your HT machines are back to S40.04, but is it faster than S39L, and if so, why?
You state that all your HT machines are back to S40.04, but is it faster than S39L, and if so, why?
P-4 Model 540 Prescott, 3.20 GHz, HT enabled
Akosf-optimised client version S39L
Short WUs, sample of 18 processed, avg time 2086 sec (34m 46s)
Long WUs, sample of 15 processed, avg time 6949 sec (1h 55m 49s)
Akosf-optimised client version S40.04
Short WUs, sample of 29 processed, avg time 2103 sec (35m 3s)
Long WUs, sample of 16 processed, avg time 6899 sec (1h 54m 59s)
These results are so close as to be statistically insignificant. More interesting than the averages are the groups of WUs that process in different time ranges; I found several short WUs that all took about 2035-2075 seconds, several others that all took about 2150-2180 seconds, and a few that took only 1935-1950 seconds, all on S40.04. These differences are greater than the differences between the client versions shown above. If you happen to get different groups of WUs when testing different clients, you may be misled into thinking that one has a clear advantage over the other when it really makes little or no difference in the long run.
... These differences are greater than the differences between the client versions shown above. If you happen to get different groups of WUs when testing different clients, you may be misled into thinking that one has a clear advantage over the other when it really makes little or no difference in the long run.
My 2 minute difference was with the same data set and nearly identical time slices. But your observations are real and your conclusion is reasonable, thanks. However, I would like to move on to a faster science app if Akos has one and my machine in not being contrary. I've been stuck at the 126-minute runtime ever since S39L was available. I rarely get the short WUs which is OK with me since the only time I did get them I hit the proverbial MDQ!
I've been stuck at the 126-minute runtime ever since S39L was available.
Not a bad place to be stuck, compared to those who either haven't a clue about what Akos has accomplished or are too timid to try his modified clients! ;-)
RE: RE: ***UNHANDLED
)
I had one of those too. The vast majority of my S40.12 results had no problems, but I did have one interesting anomaly on another result crunched by the same box that generated the Access Violation error. Even though it spent a few hours crunching out the result, and the result validated properly, it reported zero hours CPU time and claimed zero credit. Fortunately, the other boxes that crunched it did claim credit, so I received credit. Weird, no?
BTW, I also experienced slowdowns running S40.12 on HT systems, so all my HTs are back to running S40.04 whereas I've now upgraded all my SSE-compatible non-HTs to S41.06. Thanks, Akos, for the awesome improvements!
RE: ...(snipped)...BTW, I
)
On my 3GHz P4 Prescott w/HT enabled I swapped S39L to S40.04. But S40.04 ran 2 minutes longer so I switched back to S39L. Based on my comprehension of the msg thread discussions I'm not convinced that any of Akos' later versions would be any faster on my machine than S39L so I haven't experimented with them. You state that all your HT machines are back to S40.04, but is it faster than S39L, and if so, why?
RE: You state that all your
)
P-4 Model 540 Prescott, 3.20 GHz, HT enabled
Akosf-optimised client version S39L
Short WUs, sample of 18 processed, avg time 2086 sec (34m 46s)
Long WUs, sample of 15 processed, avg time 6949 sec (1h 55m 49s)
Akosf-optimised client version S40.04
Short WUs, sample of 29 processed, avg time 2103 sec (35m 3s)
Long WUs, sample of 16 processed, avg time 6899 sec (1h 54m 59s)
These results are so close as to be statistically insignificant. More interesting than the averages are the groups of WUs that process in different time ranges; I found several short WUs that all took about 2035-2075 seconds, several others that all took about 2150-2180 seconds, and a few that took only 1935-1950 seconds, all on S40.04. These differences are greater than the differences between the client versions shown above. If you happen to get different groups of WUs when testing different clients, you may be misled into thinking that one has a clear advantage over the other when it really makes little or no difference in the long run.
RE: ... These differences
)
My 2 minute difference was with the same data set and nearly identical time slices. But your observations are real and your conclusion is reasonable, thanks. However, I would like to move on to a faster science app if Akos has one and my machine in not being contrary. I've been stuck at the 126-minute runtime ever since S39L was available. I rarely get the short WUs which is OK with me since the only time I did get them I hit the proverbial MDQ!
RE: I've been stuck at the
)
Not a bad place to be stuck, compared to those who either haven't a clue about what Akos has accomplished or are too timid to try his modified clients! ;-)
Since I started with S40.12
)
Since I started with S40.12 on April 21th no erros, no problems, it works perfect.
Thanks Akosf
Happy crunching