 |
Czech National Team
Projekty
|
|
Právě je středa, 21.srpna 2019, 16:55 hod.
|
| Menu |
Seznam projektů |
|
|
|
|
12-digit factor of P2203 has now been found by the project...  |
|
...194611 times
|
|
| Acemd apps should be fixed |
|
We are aware of the problem and working on it. Sorry for the inconvenience.
|
|
| New version of application for Rank 10 |
Dear participants!
We deploy a new version of the application for search in rank 10 space. It will be faster than the previous version due to the earlier exclusion of some combinations that do not lead to a result - we add a filter for excluding combinations with the same rows in one position. Example of a similar combination you can view in July 2019 totals.
We expect that the results for the same workunit processed by the different versions of the application may differ and marked as incorrect. But in our estimation, the number of such results will be relatively small - about several tens, maybe 100 or 200. If you face with such workunits - post these numbers in this thread, please!
Thank you for attention for the project and participation!
|
|
| Be careful with BOINC computers on the Internet |
A lot of us use Cloud servers such as AWS, or make our home computers or our computers at work accessible on the Internet so we can control their BOINC clients remotely.
I was looking through the logs of some Azure servers I have running BOINC, and saw this on one of them:
10316 8/7/2019 11:39:23 AM GUI RPC request from non-allowed address 2.0.25.129
10648 8/7/2019 1:09:27 PM GUI RPC request from non-allowed address 2.0.42.193
10649 8/7/2019 1:09:27 PM 256 connections rejected in last 10 minutes
In fact, a similar address (somewhere in France, supposedly) tried to connect to the BOINC client on four of my BOINC machines. This has been happening since at least July.
If the BOINC client on your computers is accessible from the Internet, I advise putting your specific IP address (or addresses) into remote_hosts.cfg rather than leaving it open to the world, or doing the same in a firewall (or both). And use a strong password.
If you don't think this is important... anyone who successfully connects to the BOINC client on your computer can attach it to their own BOINC server, which can then send it tasks that can easily install malicious payloads such as key loggers, spam relays, DDOS bots, and other bad stuff.
EDIT: If this is all Greek to you and you don't know what I'm talking about, you're probably not at risk. BOINC starts off with remote access disabled. You have to explicitly go and change configuration files to enable remote access, and probably modify your firewall as well. If you haven't done that, you're okay.
|
|
| Entering Final Phase of Subfield 4 |
|
The final batch of subfield 4 is starting to rear its ugly head. This beast has 1.6M work units averaging about 2.5 hours a piece (on a 4GHz cpu).
|
|
| new GPU app versions |
I was noticing a slow down with the GPU app versions on the 15x271 data set. I found the problem - a large fraction of the discriminants were exceeding the hard coded precision. When this happens the GPU kicks it back to the CPU to handle. As a result, the GPU spent more time idling as it waited on the CPU to finish the task. A side effect of this was that the WU would also use almost an entire CPU core.
I increased the hard coded precision and tested on the troublesome data sets as well as the newest 16x271 data set. The issue seems to be fixed, but please report any unexpected behavior.
|
|
| [all] new work |
|
Think the project is closed. Travis is no longer active, or he's taking a loooooong vacation.
|
|
| New Expanded Runs for Milkyway_nbody (08/06/2019) |
Hello all,
I've just placed two new runs up onto MilkyWay@home:
-de_nbody_08_06_2019_v176_40k__dataExpand__1
-de_nbody_08_06_2019_v176_40k__dataExpand__2
These runs are going to search over a larger phase space, however, due to the technological limitations of simulating incredibly dense dwarf galaxies, a significant portion of this phase space will be skipped. This limitation has been placed in previous runs using the current version of Milkyway_nbody, however, the larger phase space will make this more apparent. We set up our lua file such that runs with abnormally long runtimes will only take a few seconds to complete and return the worst case likelihood score. As credits are calculated dynamically for Nbody, it may take a few runs for Milkyway@home to assign the proper amount of credits. We plan on adding another expanded data run once de_nbody_07_10_2019_v176_40k__data__7 converges.
Thank you for your support,
Eric
|
|
| July 2019 totals |
Dear folks!
As you know in July we started a new search - permutational diagonal Latin squares (ODLS) of rank 10. Due to lack of information about the existence of these pairs, we include into results data about found partially orthogonal pairs.
No ODLS of rank 10 found yet, but we collected the following statistics about partially orthogonal pairs from 15318 workunits processed in July :
Degree 81: 508008
Degree 82: 121883
Degree 83: 23545
Degree 84: 4979
Degree 85: 684
Degree 86: 163
Degree 87: 10
Degree 88: 4
Degree 89: 0
...
Degree 100: 0
One of the pairs with degree 88 looks some funny:
but the other - more usual:
We are still thinking about badges for new search (except "credit badges" of course) but for this month totals we want to congratulate the participants, which computers found pairs with degree of orthogonality of rank 86 or higher:
terry and [AF>France>TDM>Picardie>Oise] docmic92 (L'Alliance Francophone),
arkiss and [AF>Amis des Lapins] Phil1966 (L'Alliance Francophone),
Heikki and [AF>France>Savoie] Tutu1986 (L'Alliance Francophone),
raddoc and [AF>WildWildWest]Sebastien (L'Alliance Francophone),
Progger and [AF>Libristes]cguillem (L'Alliance Francophone),
zgf2022 and Michael H.W. Weber (Rechenkraft.net),
Boliver and zelandonii (L'Alliance Francophone),
Leonmer and LeChat51X (L'Alliance Francophone),
Solo Man and Steve Dodd (The Planetary Society),
dabarlow and Rhodan71 (L'Alliance Francophone),
DRandolph and eeeeee (Universite de Sherbrooke),
yippee0226 and dpc_kluizenaar (Dutch Power Cows),
GESUCHTMAN and arjanscholl (Dutch Power Cows),
faliqisbah and BlisteringSheep (Ars Technica),
Mark Sechin and Fateev Aleksey (SETIKAH@KOREA),
AlexxSaigon and [SG-2W]Kurzer (SETI.Germany),
Kevin (USA) and killik (Czech National Team),
Administrator and DoctorNow (BOINC@Heidelberg),
[B^S]ABoskovich and Shaman (Czech National Team),
FourOh (SETI.USA) and Ralfy (BOINC Confederation),
Casey ([H]ardOCP) and respawner (Rechenkraft.net),
saiz (Team China) and [B@P] Daniel (BOINC@Poland),
STE\/E (BlackOps) and Rudy Toody (TeAm AnandTech),
Buga1 (Calm Chaos) and BritishBob (Overclock.net),
NeoGen (AMD Users) and ReaDy (Astronomy.Ru Forum),
fix (Crystal Dream) and [SG]steini (SETI.Germany),
cc-smokey (CC-Team) and Vincent Dark (Team China),
AGG (Crystal Dream) and hoarfrost (Crystal Dream),
Werinbert (Free-DC) and Roadranner (SETI.Germany),
morgan (Team Norway) and Landjunge (Planet 3DNow!),
axels (SETI.Germany) and Paulteo (Crunching@EVGA),
Derivator (Gridcoin) and CoolAtchOk (Russia Team),
inugamikoubou@hangul and muzzdiez (SETIKAH@KOREA),
VogeL (SETI.Germany) and Spritex (BOINC@Denmark),
jozef j (Russia Team) and Kodeks IT (TSC! Russia),
citerra (Russia Team) and Dario666 (BOINC@Poland),
lydy1993 (Team China) and [B^S] fred (BOINCstats),
JagDoc (Planet 3DNow!) and kim-b-h (BOINC@Denmark),
Timothy Mullican (USA) and Dingo (BOINC@AUSTRALIA),
Gipsel (Planet 3DNow!) and Peter (BOINC@AUSTRALIA),
Soderstromm (Gridcoin) and sergamena (Russia Team),
SerGiani (Russia Team) and whizbang (Ars Technica),
Novalor (SETI.Germany) and RFGuy_KCCO ([H]ardOCP).
(Their number is 86 also!)
Thank you for attention to the project and participation!
|
|
| New Separation Testing Runs |
Hi Everyone,
Looking at all of the previous runs (including those from previous projects), there are patterns of interesting and unexpected behavior from the optimization results. In order to better understand these results, I have planned a series of extensive testing runs. These tests will allow us to learn how the optimization routine's responds to specific circumstances and inputs. I will make a comment attached to this post describing the tests & reasons for the tests in greater detail if anyone is interested.
EVERYTHING IS WORKING AS INTENDED. These results are not entirely understood, not incorrect. I don't expect to invalidate any results from this project, but I do plan on actually producing more, better results as I learn why the optimizer outputs what it does.
I am rolling out the first 2 series of tests, and have released the runs on the server.
The names of these runs are:
de_modfit_14_bundle5_testing_4s3f_1
de_modfit_14_bundle5_testing_4s3f_2
de_modfit_14_bundle5_testing_4s3f_3
de_modfit_14_bundle4_testing_3s4f_1
de_modfit_14_bundle4_testing_3s4f_2
de_modfit_14_bundle4_testing_3s4f_3
Please let me know if you experience any problems with these runs. Thank you all for your help with this project!
Best,
Tom
|
|
| firewall black listing |
It has come to my attention that some users have been black listed by the university firewall system. This usually means that the volunteer cant download tasks or even connect to the website.
We are currently looking at ways to reduce the firewall restrictions so this will stop happening. In the meantime, the work around is for me to request the IT department to white list an IP address on an individual basis.
If you or someone you know is experiencing connection problems, please let me know so I can have them added to the white list.
|
|
| Results databases |
After last server update I have also prepared NFS based folders with results databases.
So, here is rsults page where you can download all processed data from our project.
|
|
| New Separation Runs [UPDATE] |
Hi Everyone,
I just put some new Separation runs up on the server and took down the old ones. You may still see new workunits from old runs in your queues for a few days as those runs finish validating.
The names of the new runs are:
de_modfit_80_bundle4_4s_south4s_bgset
de_modfit_81_bundle4_4s_south4s_bgset
de_modfit_82_bundle4_4s_south4s_bgset
de_modfit_83_bundle4_4s_south4s_bgset
de_modfit_84_bundle4_4s_south4s_bgset
de_modfit_85_bundle4_4s_south4s_bgset
de_modfit_86_bundle4_4s_south4s_bgset
An error processing a flag in the parameter files has been fixed and updated runs have been released. These runs are confirmed to be returning results as of 10 PM on 7/24. I apologize for the inconvenience.
The names of the new runs are:
de_modfit_80_bundle4_4s_south4s_bgset_2
de_modfit_81_bundle4_4s_south4s_bgset_2
de_modfit_82_bundle4_4s_south4s_bgset_2
de_modfit_83_bundle4_4s_south4s_bgset_2
de_modfit_84_bundle4_4s_south4s_bgset_2
de_modfit_85_bundle4_4s_south4s_bgset_2
de_modfit_86_bundle4_4s_south4s_bgset_2
As these runs optimize we may see increased invalidated returns with the stripe 84 and 85 runs. This is a known issue that I believe has something to do with a data cut made in those stripes. If/when this starts happening and the stripes are sufficiently optimized, I will take them down so you all don't have to worry about crunching invalidated WUs.
If you have any questions/comments/concerns, please feel free to post them here. Thanks for all your support!
Best,
Tom
|
|
| Nbody Data Run 4 Replaced |
Hey all,
Something happened with de_nbody_07_10_2019_v176_40k__data__4 that caused it to end prematurely. As such a new run has been implemented to replace it, titled de_nbody_07_10_2019_v176_40k__data__7.
We apologize for any inconvenience.
-Eric
|
|
| 2019 SETI.Germany Wow! anniversary event: 15-29 August |
|
Every year SETI.Germany organizes an event in honor of the anniversary of the Wow! signal. This year's event (the 42nd anniversary) takes place from 15 to 29 August . Further information can be found here .
|
|
| 12-digit factor of P2203 has now been found by the project... |
|
...190818 times - still no sign of any larger factors
|
|
| CMS@Home disruption, Monday 22nd July |
I've had the following notice from CERN/CMS IT:
>> following the hypervisor reboot campaign, as announced by CERN IT here: https://cern.service-now.com/service-portal/view-outage.do?n=OTG0051185
>> the following VMs - under the CMS Production openstack project - will be rebooted on Monday July 22 (starting at 8:30am CERN time):
...
>> | vocms0267 | cern-geneva-b | cms-home
to which I replied:
> Thanks, Alan. vocms0267 runs the CMS@Home campaign. Should I warn the volunteers of the disruption, or will it be mainly transparent?
and received this reply:
Running jobs will fail because they won't be able to connect to the schedd condor_shadow process. So this will be the visible impact on the users. There will be also a short time window (until I get the agent restarted) where there will be no jobs pending in the condor pool.
So it might be worth it giving the users a heads up.
So, my recommendation is that you set "No New Tasks" for CMS@Home sometime Sunday afternoon, to let tasks complete before the 0830 CST restart. I'll let you know as soon as Alan informs me that vocm0267 is up and running again
|
|
| CMS@Home disruption, Monday 22nd July |
I've had the following notice from CERN/CMS IT:
>> following the hypervisor reboot campaign, as announced by CERN IT here: https://cern.service-now.com/service-portal/view-outage.do?n=OTG0051185
>> the following VMs - under the CMS Production openstack project - will be rebooted on Monday July 22 (starting at 8:30am CERN time):
...
>> | vocms0267 | cern-geneva-b | cms-home
to which I replied:
> Thanks, Alan. vocms0267 runs the CMS@Home campaign. Should I warn the volunteers of the disruption, or will it be mainly transparent?
and received this reply:
Running jobs will fail because they won't be able to connect to the schedd condor_shadow process. So this will be the visible impact on the users. There will be also a short time window (until I get the agent restarted) where there will be no jobs pending in the condor pool.
So it might be worth it giving the users a heads up.
So, my recommendation is that you set "No New Tasks" for CMS@Home sometime Sunday afternoon, to let tasks complete before the 0830 CST restart. I'll let you know as soon as Alan informs me that vocm0267 is up and running again
|
|
| The Audacious Project |
As you may have heard, the Institute for Protein Design was recently selected as part of The Audacious Project. This large-scale philanthropic collaboration, which is the successor to the TED Prize, surfaces and funds projects with the potential to change the world.
As a result, we are expanding our Seattle-based team of scientists and engineers who will work together to advance Rosetta, our software for protein design and structure prediction. The funding will also allow us to invest in the equipment, supplies and lab space needed to design and test millions of synthetic proteins.
What challenges will we be tackling? Watch my TED talk to find out.
All of this work — like everything we do — will depend on you, the participants in Rosetta@home. Whether it’s creating custom nanomaterials or safer cancer therapies, we rely on the Rosetta@home distributed computing platform. We cannot thank you enough for taking the time to be a part of this exciting research, and we hope you tell at least one friend that they too can play a role in the protein design revolution just by running Rosetta@home.
Thank you,
David Baker
Director, Institute for Protein Design
|
|
| New run for RakeSearch R10 |
Dear folks!
We created the first bunch of tasks for new search in rank 10 space. Currently - under Linux x86-64. Renewed search use a new application, runtime increased in several times and new application return more data than previous. If tasks processing is successful tomorrow we add details! :)
Great thanks for Daniel from BOINC@Poland for attention, scientific critical perception and help!
|
|
|
| Další |
|
|
