P Workunits
25 Apr 2006 17:06:04 UTC
Topic 191134
(moderation:
Noticed one of my hosts has downloaded 2 workunits preceded by p1 rather than the usual z1 or r1.Anyone know what they are?
http://einsteinathome.org/workunit/7391714
The initial replication is also 6 rather than 3.
Neil
P Workunits
)
Seven days and still no official comment - the Einstein@home information policy needs urgently to be revised.
Why did the scientific team change the WU style, to aim at what? Do you expect any changes in user behavior, i.e. keeping less WUs cached or something like that?
Questions over questions. I'd like there's someone to give answers.
--lox
Anyone also notice this
)
Anyone also notice this change:
max # of error/total/success results 5, 10, 20
I've always seen 20,20,20 for WUs
RE: Noticed one of my hosts
)
I vaguely remember a thread answering this. They're being named after the developers, in this case whose surname probably starts with a 'p'. The remaining characters refer to sky grid positions and search frequencies, alas I can't recall the exact algorithm for deciphering...
Maybe it means something encouraging, helpful and uplifting like 'positive signal number 1' or somesuch :-)
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
RE: I vaguely remember a
)
Found it here.
Cheers Mike.
(edit) See here too.
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
Thanks for putting some light
)
Thanks for putting some light on WU naming.
But, it doesn't say much about 'p' or 'j' WUs we are seeing lately.
And more, it doesn't say anything about what's going on and I must agree with Loxami on that. Too much space for speculations doesn't server well, IMO...
Are we testing some new WUs?
Is this connected with S5 series to be launched once we are finished with S4?
Is there any connection to issue of maximum daily quota (MDQ)?
Is MDQ recognized as a problem and being in proccess of solving (several ways has been suggested) or are we to hack client_state.xml to overcome this?
What is the load of scheduler and other Einstein servers? Are they ready to provide more work? (It's a bad situation having crunchers able to help more and project let them down by not solving MDQ).
Any change implementing some optimalizations and concepts from akosf's effort? How is it - and testing on new app for Linux - going?
How about some time schedule?
Those are couple of question raised during last days/was and I haven't fund answer on forum(s) yet.
I undestand that project staff has a lot more to do as a part of they daily job etc and there can be more on to do list with higher priorities. That's perfectly fine - just let us know.
Neil: The "p" and "j"
)
Neil:
The "p" and "j" workunits have fake signals injected into them. The "p" is probably for Holger Pletsch, and the "j" ... I don't know, maybe injection?
We have a pretty complicated data analysis pipeline now, and testing our ability to pick up fake signals of various strengths is crucial. If we see a real one, it lets us state a statistical confidence and likely amplitude. If this S4 run doesn't get a real signal, which is more likely, the injection studies let us make statements on upper limits: We can state with 95% confidence there is no real signal stronger than X in this data set, that sort of thing.
By the way ... people keep asking things like "Why not put a blinker on the screensaver when a possible signal is detected?" The answer is we won't know if anything is there until well after all the numbers are crunched. A signal from a real pulsar would be spread over many workunits, and we wouldn't be able to distinguish it from noise until we had compared it to the noise which is spread out over even more workunits. So even though the S4 numbers will be crunched by mid-summer, we probably wouldn't know if there was anything until fall. There is a lot of post-processing to be done.
Honza:
We're not on S5 yet. Right now it looks like mid-summer.
There are more optimizations being tested. Linux is hard, though, because of the way the compiler works.
I know this is having some effect on the maximum daily quota and the server, though I'm not sure of the details. I do know the server is the easiest thing to break, though. And Bruce has been very conservative ramping up the load on it, with the result that Einstein@Home has been one of the more reliably "up" distributed computing projects.
Hope this helps,
Ben
Thanks for the update on S5,
)
Thanks for the update on S5, Ben. This may be a foolish question, but it's something I've wondered about regarding signal injection. What would be required to inject a real signal? For example, if it were possible to collect a tablespoon-sized sample of matter from a neutron star, and move it back and forth near the LIGO detector, how big of a sample would be required, and at what distances from the detector would it be, in order to inject a real signal?
Since at current crunching
)
Since at current crunching rates we're going to finish the S4 WUs in mid to late june, with S5 not being ready for a while afterwards, does that mean einstien is going to be temporarily shut down?
Thanks for the info, Ben,
)
Thanks for the info, Ben, appreaciated.
Yes, it helped and put some light in what's going on at Einstein.
Keep up the good job...and keep us informed :-)
RE: [...] There are more
)
In what way is the GNU gcc compiler 'hard'?
Or are you talking about the IDE and/or hard following the Windows format?
Regards,
Martin
See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)