Well that's an interesting observation or three. Certainly plausible. In theory you could correlate heat production ( random motion ) via the thermodynamic laws to entropy changes ( ie. changes in information/order states ). I couldn't derive a quantitative expression for you in this instance though ... :-)
I think it was Claude Shannon who looked at this, using the notion of Maxwell's Demons to prove that all information processing must consume energy, generate heat and result in a nett entropy increase. Ultimately quite similiar to Carnot cycles for the steam engines, with mechanical work in those being replaced by the electrical work of state changing in circuits.
By extension suppose you generate the same final algorithmic result from some original state, but by a quicker route. Then some minimum heat will still be generated either way but the quicker method dumps that sooner and gives the greater temperature. [ a blizzard of other factors, like heat loss mechanisms particularly, being held equal ].
[aside]
Speaking of state changes, heat and speed. I just bought some 2GB sticks, Corsair DDR3's. They are embedded in hefty finned heat sinks. First I've ever seen of this. Old hat no doubt and I lead a sheltered life. I didn't get the optional surrounding fan unit. Perhaps I should!
[/aside]
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
One of my many returns on 6.05 is currently showing a validate error.
Interestingly enough, both mine and my quorum partner show "checked but no consensus yet". Yet mine shows as a validate error while his shows as success.
Does this mean simply that they weren't adequately similar and that mine was the second reported in? Or does it mean more definitively that there is something wrong with my host's result?
The second possibility might point to something with the application itself, as my hosts have not been generating validate errors on 6.04. If the first possibility is the case, it could still be true that the real discrepant result came from the other hosts. As the tiebreaker is not even yet sent out, it may be quite a while before we get resolution on this leg.
Now it is true that this host is mildly overclocked, and one possibility is that the new application occasionally does something that is a little more speed challenging for it than the old one. While one could also term that an application problem, as a philosophical point I don't.
I think it was Claude Shannon who looked at this, using the notion of Maxwell's Demons to prove that all information processing must consume energy, generate heat and result in a nett entropy increase. Ultimately quite similiar to Carnot cycles for the steam engines, with mechanical work in those being replaced by the electrical work of state changing in circuits.
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
One of my many returns on 6.05 is currently showing a validate error.
Can you point me to the result?
BM
Here's a direct link to workunit 43808838, which is where the error shows.
'Validate error' usually means that the actual result file isn't available for the validator to look at (timing problem, reporting too soon after uploading or suchlike), rather than the confusingly similar but different 'validation error', where the file is available to be compared but contains garbage.
One of my many returns on 6.05 is currently showing a validate error.
Can you point me to the result?
BM
Here's a direct link to workunit 43808838, which is where the error shows.
'Validate error' usually means that the actual result file isn't available for the validator to look at (timing problem, reporting too soon after uploading or suchlike), rather than the confusingly similar but different 'validation error', where the file is available to be compared but contains garbage.
Where do you get that from?
On Einstein@home a file is marked as "validate error" (i.e. BOINC's validate_state = VALIDATE_STATE_ERROR) when something goes wrong checking the single result file (before comparing it to a different result of the same workunit). It could be that the file is not where the validator expects it to be, that it is empty (has zero length), can't be uncompressed properly, the uncompressed file contains something else than pure ASCII etc. etc. All these will end up as the same state in the DB. It might be that different web pages name that state slightly different, but AFAIK internally it's the same state in all cases.
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.
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.
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.
Well that's an interesting
)
Well that's an interesting observation or three. Certainly plausible. In theory you could correlate heat production ( random motion ) via the thermodynamic laws to entropy changes ( ie. changes in information/order states ). I couldn't derive a quantitative expression for you in this instance though ... :-)
I think it was Claude Shannon who looked at this, using the notion of Maxwell's Demons to prove that all information processing must consume energy, generate heat and result in a nett entropy increase. Ultimately quite similiar to Carnot cycles for the steam engines, with mechanical work in those being replaced by the electrical work of state changing in circuits.
By extension suppose you generate the same final algorithmic result from some original state, but by a quicker route. Then some minimum heat will still be generated either way but the quicker method dumps that sooner and gives the greater temperature. [ a blizzard of other factors, like heat loss mechanisms particularly, being held equal ].
[aside]
Speaking of state changes, heat and speed. I just bought some 2GB sticks, Corsair DDR3's. They are embedded in hefty finned heat sinks. First I've ever seen of this. Old hat no doubt and I lead a sheltered life. I didn't get the optional surrounding fan unit. Perhaps I should!
[/aside]
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
One of my many returns on
)
One of my many returns on 6.05 is currently showing a validate error.
Interestingly enough, both mine and my quorum partner show "checked but no consensus yet". Yet mine shows as a validate error while his shows as success.
Does this mean simply that they weren't adequately similar and that mine was the second reported in? Or does it mean more definitively that there is something wrong with my host's result?
The second possibility might point to something with the application itself, as my hosts have not been generating validate errors on 6.04. If the first possibility is the case, it could still be true that the real discrepant result came from the other hosts. As the tiebreaker is not even yet sent out, it may be quite a while before we get resolution on this leg.
Now it is true that this host is mildly overclocked, and one possibility is that the new application occasionally does something that is a little more speed challenging for it than the old one. While one could also term that an application problem, as a philosophical point I don't.
RE: I think it was Claude
)
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
RE: One of my many
)
Can you point me to the result?
BM
BM
RE: RE: One of my many
)
Must be this one .
Bikeman
RE: RE: One of my many
)
Here's a direct link to workunit 43808838, which is where the error shows.
'Validate error' usually means that the actual result file isn't available for the validator to look at (timing problem, reporting too soon after uploading or suchlike), rather than the confusingly similar but different 'validation error', where the file is available to be compared but contains garbage.
RE: RE: RE: One of
)
Where do you get that from?
On Einstein@home a file is marked as "validate error" (i.e. BOINC's validate_state = VALIDATE_STATE_ERROR) when something goes wrong checking the single result file (before comparing it to a different result of the same workunit). It could be that the file is not where the validator expects it to be, that it is empty (has zero length), can't be uncompressed properly, the uncompressed file contains something else than pure ASCII etc. etc. All these will end up as the same state in the DB. It might be that different web pages name that state slightly different, but AFAIK internally it's the same state in all cases.
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.
BM
BM
RE: Where do you get that
)
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.
My 3500+ machine is the only
)
My 3500+ machine is the only one I've switched over so far. After the first few workunits, it looks like SSE2 is giving it a big boost.
I've still to switch over two other Windows boxes. I'll do that once they've completed crunching the workunits in progress.
RE: The result file in
)
Does the file unzip properly though?