The fitfunction gives for these days an increase of 0,987[TFlops/d]
Ok. 1 TFLOPS per day doesn´t sound impossible. I´m not sure about the real performance of a new Intel core i7, but it should be at least 50 GFlops. So only 20 new PCs are needed for an increase of one TFlops if they run 24/7.
The Boinc benchmark says 26 GFlops, if you use all 8 processors with 100% CPU Usage. That's for the 2,8 GHz Version of the I7
I understand that there is a whole working group of scientists that are preoccupied with characterizing and understanding the detector noise (the physicists here will know better than me).
Even if you just read the introductory and the summary sections, I think you get a pretty good idea: it were changes done in the upgrading of the detector hardware (e.g. mode cleaners, more powerful laser) rather than environmental changes that complicated the noise characteristics of the detectors. And when you read between the lines, you can even get some sense of surprise/disappointment about the S6 noise situation, IMHO.
I intend to pick up my work on the new workunit generatior for the Radio-Pulsar search.
[...]
But the next larger project I intend to work on is basically rewriting the code that reads the SFT data files for the GW search into the applications memory.
Oliver is back and finished the work on the new workunit generator, and Benjamin finished the setup of the new search & data. Testing is well underway, we should have new radio pulsar work in the next (working) days, depending on what problems the internal tests might reveal.
I am pretty confident that the bug in the BOINC API causing random segfaults on Linux has been found and fixed yesterday.
And the re-implementation of the SFT reading code is almost finished. It will take a bit of testing to get enough confidence in it, and I already have an idea for a further optimization.
I'm still thinking and discussing whether I should take the effort to build and publish new app versions for every little change (which would slow down the process quite a bit), or whether I should collect changes to push out a single new app version when everything is finished (which would mean that you have to wait a bit longer for anything to happen). Currently I'm more inclined to the latter.
But in any case this looks like a pretty successful week.
RE: RE: The fitfunction
)
The Boinc benchmark says 26 GFlops, if you use all 8 processors with 100% CPU Usage. That's for the 2,8 GHz Version of the I7
No more work for S5GC1 search
)
No more work for S5GC1 search progress
:D
Are you working on ATI-Support? I want to crunch with my 5650 ;)
RE: No more work for S5GC1
)
See here.
There's some work being done on an OpenCL version of the Radio-Pulsar search that should also make use of ATI GPUs.
BM
BM
RE: Why is that? A science
)
I'm curious about this as well. I'd been looking forward to S6 because I thought that was where things were really supposed to get exciting.
-Steve Bergman
Hi I understand that there
)
Hi
I understand that there is a whole working group of scientists that are preoccupied with characterizing and understanding the detector noise (the physicists here will know better than me).
One paper from that group is this one :
http://iopscience.iop.org/0264-9381/27/19/194010/pdf/0264-9381_27_19_194010.pdfhttp://iopscience.iop.org/0264-9381/27/19/194010/pdf/0264-9381_27_19_194010.pdf
Even if you just read the introductory and the summary sections, I think you get a pretty good idea: it were changes done in the upgrading of the detector hardware (e.g. mode cleaners, more powerful laser) rather than environmental changes that complicated the noise characteristics of the detectors. And when you read between the lines, you can even get some sense of surprise/disappointment about the S6 noise situation, IMHO.
CU
HBE
RE: Short update on what I
)
Oliver is back and finished the work on the new workunit generator, and Benjamin finished the setup of the new search & data. Testing is well underway, we should have new radio pulsar work in the next (working) days, depending on what problems the internal tests might reveal.
I am pretty confident that the bug in the BOINC API causing random segfaults on Linux has been found and fixed yesterday.
And the re-implementation of the SFT reading code is almost finished. It will take a bit of testing to get enough confidence in it, and I already have an idea for a further optimization.
I'm still thinking and discussing whether I should take the effort to build and publish new app versions for every little change (which would slow down the process quite a bit), or whether I should collect changes to push out a single new app version when everything is finished (which would mean that you have to wait a bit longer for anything to happen). Currently I'm more inclined to the latter.
But in any case this looks like a pretty successful week.
BM
BM
Slow and steady wins the
)
Slow and steady wins the race. Go with the latter.
RE: Slow and steady wins
)
I agree with Allen. Take the time to check everything and to ensure the quality. Go with the latter.
Einstein is known as a
)
Einstein is known as a long-term quality project where exciting things happen every now and then. Don't rush to change that ;)
MrS
Scanning for our furry friends since Jan 2002