It's been a perennial problem at SETI when people use the 'Return Results Immediately' third-party clients. 'Return Results after a brief pause' usually eliminates it. But I didn't know about the other possibilities - thanks, that'll be useful info to refer to next time it crops up.
Which properties exactly set this state of a result depends on the validator the project uses, so is usually highly specific to the project (edit: with the exeption of projects that use one of BOINC's validator examples like the "bitwise validator").
The result file in question here has a broken directory entry in the zip archive header, while the zipped data itself looks ok. I've seen some of these problems with zipping on overclocked machines, my rough guess is that it depends on the die temperature of the ALU when the zipping happens. For now it doesn't look to me like a problem with the App.
Does the file unzip properly though?
Depends on the tool / library you're using. InfoZip's unzip and the zlib-based zziplib (which we use in our current validator) refuse to unzip the file, gzip-based zcat skips the zip header anyway and reveals a result file that looks ok at first glance.
The result file in question here has a broken directory entry in the zip archive header, while the zipped data itself looks ok. I've seen some of these problems with zipping on overclocked machines, my rough guess is that it depends on the die temperature of the ALU when the zipping happens. For now it doesn't look to me like a problem with the App.
Not arguing with your conclusion regarding the ap unless we see repeats, especially on other hosts.
However this host is a Q6600 running only 2.8 GHz, with 1.35625 requested voltage. I ran Einstein, SETI, and all my usual personal computing on this exact host at 3.005 GHz at a similar voltage for some months, at a lower fan setting on warmer days. I estimate the die temperature at the time the zipping was done to have been about 52C. (it routinely got up to 65C on warm afternoons at the previous more aggressive settings, and still usually peaks at about 60C now).
None of which says the ap has a problem, but it is just a little puzzling. Watchful waiting seems the right response. And I'll reboot the machine, just in case there is a little bad state waiting to be cleansed.
It's been a perennial problem at SETI when people use the 'Return Results Immediately' third-party clients. 'Return Results after a brief pause' usually eliminates it. But I didn't know about the other possibilities - thanks, that'll be useful info to refer to next time it crops up.
Which properties exactly set this state of a result depends on the validator the project uses, so is usually highly specific to the project (edit: with the exeption of projects that use one of BOINC's validator examples like the "bitwise validator").
BM
Thinking about it, SETI don't compress their result upload files, which eliminates one-and-a-half of your four cases (the half case being the pure ASCII uncompressed upload not being pure ASCII). But the zero-length empty file is certainly worth considering.
This is true in irreversible computing. But you can also have reversible computing (at least in theory), where you can go back from the final state to the initial state without any increase of entropy. From what I remember, but could find the source, it is only the destruction of a bit of information which increases entropy.
Tullio
Indeed, that was the point - that we don't ever have truly reversible machines - only abstractions to use in considering the best ( but unobtainable ) case which a real machine might approach. There's always some equivalent of friction to spoil the show. If you had a little demon to remember/decide-upon prior states ( the one of Maxwell's opened and shut a little door between two gas compartments depending upon approaching individual particle speed - hence could partition fast/hot from slow/cold ), like what was in a register before it was zeroed then you could combat information loss. But this demon has to have his registers or equivalent to perform his remembering, and we recurse the issue. Alas.
Information is 'any difference that makes a difference' and such persistent differences from 'random' states, that represent any encoding, are subject to thermodynamic rulings.
A less esoteric finding ( and more relevant to this thread! ) is that transistor switching speed will increase with the voltage/energy across it. But that's a two way street as speeding up transitions raises the chance, in digital systems, of intermediate voltage levels being wrongly attributed to the other logical state. [ Or if you like the logical state is acted upon before it has settled/completed the transition. ] I'm sure Peter could tell us all about the thrashing that chips/dies go through before release - which is why they are deemed to have the given/published speeds to which the term overclocking then applies.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
I finished mine in 25h 31m 38s, about 3 to 4 hours quicker than I would do one with plain SSE. I got this one sent earlier and with only 58 minutes to go, I installed the Power App, which caused the task to be deleted and resent. I do remember that at that time, it was at 28h of crunching already.
It also managed to get credit, it validated normally against the 6.04 app of the other person.
The result file in question here has a broken directory entry in the zip archive header, while the zipped data itself looks ok. I've seen some of these problems with zipping on overclocked machines, my rough guess is that it depends on the die temperature of the ALU when the zipping happens. For now it doesn't look to me like a problem with the App.
Does the file unzip properly though?
Depends on the tool / library you're using. InfoZip's unzip and the zlib-based zziplib (which we use in our current validator) refuse to unzip the file, gzip-based zcat skips the zip header anyway and reveals a result file that looks ok at first glance.
BM
Perhaps I should know what I'm about to ask, but I don't...
When do the result files on our machines get deleted?
Also, is it BOINC doing the zipping or is it the science application?
Perhaps I should know what I'm about to ask, but I don't...
When do the result files on our machines get deleted?
Also, is it BOINC doing the zipping or is it the science application?
From what I can tell, the result files get deleted as soon as the upload is complete and successful - they don't hang around until the reporting stage. That makes it difficult to catch them with BoincLogX or suchlike, unless you set a really fast polling interval or disable networking for the whole BOINC installation.
Since SETI doesn't zip the files, but Einstein does, my guess is that it's the science app whiich does the zipping.
If you have seen them before, you are likely to have to do an explicit page reload in your browser to see the updated data. Caching is a wonderful thing--until it isn't.
As Stoll3 and Stoll4 have now finished some results near cyclic high, a more balanced picture of improvement is emerging than the pretty "all best ever" initial picture. It may be the case that the percentage improvement in the code which varies in amount of use between peak and valley is less than the improvement in the code which is used a nearly constant amount across the cycle. As my initial estimates of overall improvement were toward cycle bottom, if true this might depress the average net improvement slightly.
I have not seen any more validate errors.
As to Richard's point of the difficulty of picking up result files with BoincLogX, it appears I'm getting about one out of every ten with my current 60 second monitoring interval. In very rough numbers, that suggests that they are typically persisting for about 6 seconds in a condition in which BoincLogX thinks them interesting to copy, and yet they are still there. I assume my wireless net, the Internet service between my home and Einstein, and the response of the Einstein servers all play a part in this, at minimum.
Funny to see how my AMD finished its task with the stock SSE application way faster than the Intel did its task with the SSE2 application.
Unless there's a lot of difference between the two tasks (AMD did a 0632.30, the Intel did a 1103.35), it would still seem as if the AMD is beating the Intel hands down (again).
Single CPU AMD XP 2200+, Windows 2000, 1GB RAM.
Single CPU Intel P4 3.0GHz with Hyperthreading on, Windows XP Pro, 2GB RAM.
RE: RE: Where do you get
)
Which properties exactly set this state of a result depends on the validator the project uses, so is usually highly specific to the project (edit: with the exeption of projects that use one of BOINC's validator examples like the "bitwise validator").
BM
BM
RE: RE: The result file
)
Depends on the tool / library you're using. InfoZip's unzip and the zlib-based zziplib (which we use in our current validator) refuse to unzip the file, gzip-based zcat skips the zip header anyway and reveals a result file that looks ok at first glance.
BM
BM
RE: The result file in
)
Not arguing with your conclusion regarding the ap unless we see repeats, especially on other hosts.
However this host is a Q6600 running only 2.8 GHz, with 1.35625 requested voltage. I ran Einstein, SETI, and all my usual personal computing on this exact host at 3.005 GHz at a similar voltage for some months, at a lower fan setting on warmer days. I estimate the die temperature at the time the zipping was done to have been about 52C. (it routinely got up to 65C on warm afternoons at the previous more aggressive settings, and still usually peaks at about 60C now).
None of which says the ap has a problem, but it is just a little puzzling. Watchful waiting seems the right response. And I'll reboot the machine, just in case there is a little bad state waiting to be cleansed.
[edited to correct typical peak temperature]
RE: RE: RE: Where do
)
Thinking about it, SETI don't compress their result upload files, which eliminates one-and-a-half of your four cases (the half case being the pure ASCII uncompressed upload not being pure ASCII). But the zero-length empty file is certainly worth considering.
RE: This is true in
)
Indeed, that was the point - that we don't ever have truly reversible machines - only abstractions to use in considering the best ( but unobtainable ) case which a real machine might approach. There's always some equivalent of friction to spoil the show. If you had a little demon to remember/decide-upon prior states ( the one of Maxwell's opened and shut a little door between two gas compartments depending upon approaching individual particle speed - hence could partition fast/hot from slow/cold ), like what was in a register before it was zeroed then you could combat information loss. But this demon has to have his registers or equivalent to perform his remembering, and we recurse the issue. Alas.
Information is 'any difference that makes a difference' and such persistent differences from 'random' states, that represent any encoding, are subject to thermodynamic rulings.
A less esoteric finding ( and more relevant to this thread! ) is that transistor switching speed will increase with the voltage/energy across it. But that's a two way street as speeding up transitions raises the chance, in digital systems, of intermediate voltage levels being wrongly attributed to the other logical state. [ Or if you like the logical state is acted upon before it has settled/completed the transition. ] I'm sure Peter could tell us all about the thrashing that chips/dies go through before release - which is why they are deemed to have the given/published speeds to which the term overclocking then applies.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
I finished mine in 25h 31m
)
I finished mine in 25h 31m 38s, about 3 to 4 hours quicker than I would do one with plain SSE. I got this one sent earlier and with only 58 minutes to go, I installed the Power App, which caused the task to be deleted and resent. I do remember that at that time, it was at 28h of crunching already.
It also managed to get credit, it validated normally against the 6.04 app of the other person.
RE: RE: RE: The result
)
Perhaps I should know what I'm about to ask, but I don't...
When do the result files on our machines get deleted?
Also, is it BOINC doing the zipping or is it the science application?
RE: Perhaps I should know
)
From what I can tell, the result files get deleted as soon as the upload is complete and successful - they don't hang around until the reporting stage. That makes it difficult to catch them with BoincLogX or suchlike, unless you set a really fast polling interval or disable networking for the whole BOINC installation.
Since SETI doesn't zip the files, but Einstein does, my guess is that it's the science app whiich does the zipping.
I've updated the execution
)
I've updated the execution time graphs in two previous posts:
message 89861
message 89807
If you have seen them before, you are likely to have to do an explicit page reload in your browser to see the updated data. Caching is a wonderful thing--until it isn't.
As Stoll3 and Stoll4 have now finished some results near cyclic high, a more balanced picture of improvement is emerging than the pretty "all best ever" initial picture. It may be the case that the percentage improvement in the code which varies in amount of use between peak and valley is less than the improvement in the code which is used a nearly constant amount across the cycle. As my initial estimates of overall improvement were toward cycle bottom, if true this might depress the average net improvement slightly.
I have not seen any more validate errors.
As to Richard's point of the difficulty of picking up result files with BoincLogX, it appears I'm getting about one out of every ten with my current 60 second monitoring interval. In very rough numbers, that suggests that they are typically persisting for about 6 seconds in a condition in which BoincLogX thinks them interesting to copy, and yet they are still there. I assume my wireless net, the Internet service between my home and Einstein, and the response of the Einstein servers all play a part in this, at minimum.
Funny to see how my AMD
)
Funny to see how my AMD finished its task with the stock SSE application way faster than the Intel did its task with the SSE2 application.
Unless there's a lot of difference between the two tasks (AMD did a 0632.30, the Intel did a 1103.35), it would still seem as if the AMD is beating the Intel hands down (again).
Single CPU AMD XP 2200+, Windows 2000, 1GB RAM.
Single CPU Intel P4 3.0GHz with Hyperthreading on, Windows XP Pro, 2GB RAM.