Yes you did - it's called Locality Scheduling :-). It was developed initially specifically for Einstein GW searches. If you search for those two words for ID=2 (Bernd) you will find various comments about it and (in more recent times) about how it needed to be adapted (or adapted to) for the follow up searches to work when bunches of candidate signals were being looked at rather than continuous frequency bins.
I would imagine a version of LS is working right now. If you and others got data in particular frequency bins before ALL of the bins were dumped into the database, there should be enough hosts feeding on those bins to guarantee a reasonable number of quorum partners. With all the bins now available, I imagine the scheduler has such a wide choice that it might take a little while to get enough extra hosts to allow a sufficient number feeding on the one set of bins. So you will see no quorum partners until the scheduler gets back to assigning that particular set of bins to a 2nd, 3rd, etc, host.
The original prediction was that this 'tuning' run was going to take about 2 weeks. Tasks seem to be taking longer than expected and there is competition from FGRP4 and FGRPB1 so unless there is a flood of new computers it might take rather longer than 2 weeks. In any case, it really shouldn't take very long (not up to a week or more like I've seen in the past) for the second task to be issued so I wouldn't be too concerned just yet.
Quote:
I'm not sure there are any hard and fast rules requiring quorums currently to be filled with a dissimilar application ...
LS doesn't do anything like that as far as I know. That's not to say that new code hasn't been written that we don't know about. I believe that if you and some other host chosen at random happen to be assigned to the same bins, that relationship is likely to continue for some time. Check if you have the same quorum partner in multiple quorums. You should have. It will be less obvious when more hosts are feeding on the same frequency bins.
I've lost the feel for what effects Locality Scheduling has during my time of focusing on GPU Einstein work that happens not to use it. Maybe that is the whole story here. But some of the patterns still seem odd.
It appears you have a host receiving work of this type, so you probably don't need this, but in case someone else stops by, at the moment, in order to get O1AS20-100T work:
1. in your Einstein web page preference for the location (venue) occupied by your host, you need to have the Einstein@home preference "use CPU" activated.
2. also on that Einstein location preference option page you need to have "Run test applications?" activated (people commonly refer to this option as the option to run beta test work).
3. Just in case they transition this work to not beta, or change the server behavior to restrict work delivery to your requested particular program, it is probably prudent in the "run selected applications" section to activate "Gravitational Wave search O1 all-sky tuning". So far in this run this setting has not been needed, as the "beta test" permission renders it superfluous.
4. your machine needs actually to request CPU work from Einstein.
That last point brings up some more complexities, as it relates to your settings under computing preferences for "Store at least n.nnn days of work" and "Store up to an additional n.nn days of work". Also relevant is the current estimate of how fast your machine processes work, which is at least partially influenced by the current value for "Task duration correction factor" for that machine. Also relevant is how much CPU type work your machine already has onboard (not only from this project).
Furthermore, there is, I think, some sort of processing pipeline, which grabs a pretty small number of tasks at a time, does a bit of preliminary work, and then only offers work from that stage to a new incoming request. At any given moment, if a request comes in for which a _suitable_ task is not found in that ready-to-send pipeline, that request will be refused with a work not available message--whether or not there is a huge backing stock of that type available on the server. Somewhere there is a mechanism which lets the project control the ratio of jobs of different applications issued--so if your machine is requesting a type currently above distribution rate quota, somehow that must get denied sometimes.
Lastly there are subflavors--for example the Locality Scheduling Gary mentioned in this thread--that help govern whether a particular ready-to-send task is deemed a match to a particular requesting destination machine.
Filipe, as I'm unclear as to your actual question or interest, I don't know if any of this is of any help. Perhaps if I am mostly accurate it will help someone else.
Thank you for your response. Yes i have the option run beta app activated. So i do receive this work.
I was just wondering why so few tasks have been sent, and with your response i concluded that for this "test run", they are only sent to those who have actually chose to run cpu beta apps.
I'm sure a lot of people is or will be asking the same question, and your response will help a lot of people get this particular type of work.
I was just wondering why so few tasks have been sent ....
I would think it's because too few computers are 'allowed' to do test work :-).
I published the figure for 24 hours ago (741,997) in my previous message. Just now the figure is 738,475 which gives ~3500 tasks sent per day. Hopefully this will pick up dramatically as the message to make sure you allow test work gets out. Probably, as soon as confidence in the results is established, the test status for the app will be removed. Then, the test work setting will not be required.
It appears you have a host receiving work of this type, so you probably don't need this, but in case someone else stops by, at the moment, in order to get O1AS20-100T work:
1. in your Einstein web page preference for the location (venue) occupied by your host, you need to have the Einstein@home preference "use CPU" activated.
2. also on that Einstein location preference option page you need to have "Run test applications?" activated (people commonly refer to this option as the option to run beta test work).
3. Just in case they transition this work to not beta, or change the server behavior to restrict work delivery to your requested particular program, it is probably prudent in the "run selected applications" section to activate "Gravitational Wave search O1 all-sky tuning". So far in this run this setting has not been needed, as the "beta test" permission renders it superfluous.
4. your machine needs actually to request CPU work from Einstein.
I would add one additional instruction to enable getting the AVX work units:
5. Upgrade BOINC to latest version 7.6.22
I started my two hosts (windows 7) and noticed I was getting the SSE2 work units. Both had older version of BOINC loaded (6.* and 7.2.42). I upgraded to the newest version of BOINC 7.6.22 and immediately started getting the AVX work units.
I am seeing about a 15% reduction in time for the AVX work units.
I am seeing about a 15% reduction in time for the AVX work units.
Hi Robert,
Very nice to see your name on the boards again! I still remember your GPU Power Efficiency Plot of three years ago and how it helped me make a decision about GPU purchases at the time.
Thanks for your comment about upgrading BOINC. That prompted me to google for BOINC support for AVX and I found this little snippet.
Check the 7.3 build. 7.2 is still build with VS2005.
----- Rom
-----Original Message-----
From: boinc_dev [mailto:boinc_dev-bounces at ssl.berkeley.edu] On Behalf Of Erik Veit
Sent: Saturday, March 01, 2014 12:15 PM
To: BOINC Dev Mailing List
Subject: Re: [boinc_dev] BOINC 7.2.11 doesn't detect AVX
Did this ever get fixed/added to boinc? If not, when?
I have an IB i7, with the win7 64 and all the latest patches, and BOINC 7.2.42. But it still does not show AVX.
3/1/2014 6:37:23 AM Starting BOINC client version 7.2.42 for windows_x86_64
3/1/2014 6:37:23 AM Processor: 8 GenuineIntel Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz [Family 6 Model 58 Stepping 9]
3/1/2014 6:37:23 AM Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi
mmx fxsr sse sse2 ss htt tm pni ssse3 cx16 sse4_1 sse4_2 popcnt aes syscall nx lm vmx tm2 pbe
3/1/2014 6:37:23 AM OS: Microsoft Windows 7: Professional x64 Edition, Service Pack 1, (06.01.7601.00)
Thanks,
Erik
I guess it's got to be 7.3 or later :-).
I'm running the recommended version for Linux (7.2.42) and Bernd's fix allowed me to get a 64bit app but not the AVX one listed on the apps page. I'd like to see that 15% improvement as well so I guess I have to go for the development version listed on the BOINC website (7.4.22) :-). At least that's a pretty easy fix for me.
You should check BOINC's Event Log first what features it lists there and /proc/cpuinfo too.
Linux version has more or less always gotten the features from /proc/cpuinfo. Windows version used to ask the OS what features was available and the answer depended on the version of Windows you had. For example, XP was released before SSE3(+-1) so didn't know of it so BOINC didn't report SSE3 even if your processor did support it. These days Windows version checks the features itself and new features are usually added only after someone asks why BOINC doesn't support some new feature.
RE: Maybe I stumbled on a
)
Yes you did - it's called Locality Scheduling :-). It was developed initially specifically for Einstein GW searches. If you search for those two words for ID=2 (Bernd) you will find various comments about it and (in more recent times) about how it needed to be adapted (or adapted to) for the follow up searches to work when bunches of candidate signals were being looked at rather than continuous frequency bins.
I would imagine a version of LS is working right now. If you and others got data in particular frequency bins before ALL of the bins were dumped into the database, there should be enough hosts feeding on those bins to guarantee a reasonable number of quorum partners. With all the bins now available, I imagine the scheduler has such a wide choice that it might take a little while to get enough extra hosts to allow a sufficient number feeding on the one set of bins. So you will see no quorum partners until the scheduler gets back to assigning that particular set of bins to a 2nd, 3rd, etc, host.
The original prediction was that this 'tuning' run was going to take about 2 weeks. Tasks seem to be taking longer than expected and there is competition from FGRP4 and FGRPB1 so unless there is a flood of new computers it might take rather longer than 2 weeks. In any case, it really shouldn't take very long (not up to a week or more like I've seen in the past) for the second task to be issued so I wouldn't be too concerned just yet.
LS doesn't do anything like that as far as I know. That's not to say that new code hasn't been written that we don't know about. I believe that if you and some other host chosen at random happen to be assigned to the same bins, that relationship is likely to continue for some time. Check if you have the same quorum partner in multiple quorums. You should have. It will be less obvious when more hosts are feeding on the same frequency bins.
Cheers,
Gary.
Thanks, Gary. I've lost
)
Thanks, Gary.
I've lost the feel for what effects Locality Scheduling has during my time of focusing on GPU Einstein work that happens not to use it. Maybe that is the whole story here. But some of the patterns still seem odd.
There is 700.000+ tasks ready
)
There is 700.000+ tasks ready to send on the SSP.
What is preventing them to beeing sent?
Filipe It appears you have
)
Filipe
It appears you have a host receiving work of this type, so you probably don't need this, but in case someone else stops by, at the moment, in order to get O1AS20-100T work:
1. in your Einstein web page preference for the location (venue) occupied by your host, you need to have the Einstein@home preference "use CPU" activated.
2. also on that Einstein location preference option page you need to have "Run test applications?" activated (people commonly refer to this option as the option to run beta test work).
3. Just in case they transition this work to not beta, or change the server behavior to restrict work delivery to your requested particular program, it is probably prudent in the "run selected applications" section to activate "Gravitational Wave search O1 all-sky tuning". So far in this run this setting has not been needed, as the "beta test" permission renders it superfluous.
4. your machine needs actually to request CPU work from Einstein.
That last point brings up some more complexities, as it relates to your settings under computing preferences for "Store at least n.nnn days of work" and "Store up to an additional n.nn days of work". Also relevant is the current estimate of how fast your machine processes work, which is at least partially influenced by the current value for "Task duration correction factor" for that machine. Also relevant is how much CPU type work your machine already has onboard (not only from this project).
Furthermore, there is, I think, some sort of processing pipeline, which grabs a pretty small number of tasks at a time, does a bit of preliminary work, and then only offers work from that stage to a new incoming request. At any given moment, if a request comes in for which a _suitable_ task is not found in that ready-to-send pipeline, that request will be refused with a work not available message--whether or not there is a huge backing stock of that type available on the server. Somewhere there is a mechanism which lets the project control the ratio of jobs of different applications issued--so if your machine is requesting a type currently above distribution rate quota, somehow that must get denied sometimes.
Lastly there are subflavors--for example the Locality Scheduling Gary mentioned in this thread--that help govern whether a particular ready-to-send task is deemed a match to a particular requesting destination machine.
Filipe, as I'm unclear as to your actual question or interest, I don't know if any of this is of any help. Perhaps if I am mostly accurate it will help someone else.
@archae86 Thank you for
)
@archae86
Thank you for your response. Yes i have the option run beta app activated. So i do receive this work.
I was just wondering why so few tasks have been sent, and with your response i concluded that for this "test run", they are only sent to those who have actually chose to run cpu beta apps.
I'm sure a lot of people is or will be asking the same question, and your response will help a lot of people get this particular type of work.
RE: I was just wondering
)
I would think it's because too few computers are 'allowed' to do test work :-).
I published the figure for 24 hours ago (741,997) in my previous message. Just now the figure is 738,475 which gives ~3500 tasks sent per day. Hopefully this will pick up dramatically as the message to make sure you allow test work gets out. Probably, as soon as confidence in the results is established, the test status for the app will be removed. Then, the test work setting will not be required.
Cheers,
Gary.
RE: ... but in case someone
)
Thanks very much for taking the trouble to make such a comprehensive check list of things to consider. Your effort is appreciated.
Cheers,
Gary.
RE: It appears you have a
)
I would add one additional instruction to enable getting the AVX work units:
5. Upgrade BOINC to latest version 7.6.22
I started my two hosts (windows 7) and noticed I was getting the SSE2 work units. Both had older version of BOINC loaded (6.* and 7.2.42). I upgraded to the newest version of BOINC 7.6.22 and immediately started getting the AVX work units.
I am seeing about a 15% reduction in time for the AVX work units.
RE: I am seeing about a 15%
)
Hi Robert,
Very nice to see your name on the boards again! I still remember your GPU Power Efficiency Plot of three years ago and how it helped me make a decision about GPU purchases at the time.
Thanks for your comment about upgrading BOINC. That prompted me to google for BOINC support for AVX and I found this little snippet.
----- Rom
-----Original Message-----
From: boinc_dev [mailto:boinc_dev-bounces at ssl.berkeley.edu] On Behalf Of Erik Veit
Sent: Saturday, March 01, 2014 12:15 PM
To: BOINC Dev Mailing List
Subject: Re: [boinc_dev] BOINC 7.2.11 doesn't detect AVX
Did this ever get fixed/added to boinc? If not, when?
I have an IB i7, with the win7 64 and all the latest patches, and BOINC 7.2.42. But it still does not show AVX.
3/1/2014 6:37:23 AM Starting BOINC client version 7.2.42 for windows_x86_64
3/1/2014 6:37:23 AM Processor: 8 GenuineIntel Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz [Family 6 Model 58 Stepping 9]
3/1/2014 6:37:23 AM Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi
mmx fxsr sse sse2 ss htt tm pni ssse3 cx16 sse4_1 sse4_2 popcnt aes syscall nx lm vmx tm2 pbe
3/1/2014 6:37:23 AM OS: Microsoft Windows 7: Professional x64 Edition, Service Pack 1, (06.01.7601.00)
Thanks,
Erik
I guess it's got to be 7.3 or later :-).
I'm running the recommended version for Linux (7.2.42) and Bernd's fix allowed me to get a 64bit app but not the AVX one listed on the apps page. I'd like to see that 15% improvement as well so I guess I have to go for the development version listed on the BOINC website (7.4.22) :-). At least that's a pretty easy fix for me.
Cheers,
Gary.
You should check BOINC's
)
You should check BOINC's Event Log first what features it lists there and /proc/cpuinfo too.
Linux version has more or less always gotten the features from /proc/cpuinfo. Windows version used to ask the OS what features was available and the answer depended on the version of Windows you had. For example, XP was released before SSE3(+-1) so didn't know of it so BOINC didn't report SSE3 even if your processor did support it. These days Windows version checks the features itself and new features are usually added only after someone asks why BOINC doesn't support some new feature.
I forget what BOINC does on OSX, *BSD and others.