| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Active Research
Forum: Mapping Cancer Markers Forum
Thread: Mapping Cancer Markers - Problems Thread |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 264
|
|
| Author |
|
|
LAZA74
Advanced Cruncher Germany Joined: Sep 28, 2008 Post Count: 56 Status: Offline Project Badges: 
|
Looks like the WUs cause more trouble in the last days.
---------------------------------------- I got two more not-finished with different errors: MCM1_ 0004085_ 7774_ 0-- and MCM1_ 0004089_ 7112_ 1-- Result Log Result Name: MCM1_ 0004085_ 7774_ 0-- <core_client_version>7.2.42</core_client_version> <![CDATA[ <message> process got signal 8 </message> <stderr_txt> Commandline = ../../projects/www.worldcommunitygrid.org/wcgrid_mcm1_7.32_x86_64-pc-linux-gnu -SettingsFile MCM1_0004085_7774.txt -DatabaseFile dataset-17_72_SDG_v1.txt Settings File DateOfDesign = 11/08/2013 Designer = PMCC_OCI WorkOrderID = 4085_7774 DatasetID = 17_72_SDG_v1 NumberOfGenesInStartingSignature = 17 NumberOfGenesInSignatureMin = 10 NumberOfGenesInSignatureMax = 20 GroupVectorValues = {A}{B}{C}{D}{E}{F} ExplicitStartingGeneSignatures = A B D F StartingGeneSignatureAlgorithm = randomFixedLengthSearch SearchAlgorithmNumberToCreate = 1 SearchAlgorithmSequentialStartPosition = 5 RunPermutationAlgorithm = 1 PermutationGroups = A PermutationGroupsForReplacement = G PermutationAlgorithm = replaceFromRandomlyToRandomlyGreedy PermutationsNumIterations = 60500 OptimizationAlgorithmFrequency = 0 0 1 FBeta = 1.5 SimAnnealIMax = 20000 SimAnnealAlpha = 0.9996 NReps = 10 TrainFrac = 0.7 NFolds = 10 VMethod = LOO ModelType = SVM FitnessFn = 0 MinFitness = 0.61 SvmArgs = "-v 0 -c 0.1 -t 1 -d 2 -r 0" SvmLearnLimit = 500000 RSeed = 399767774
and: Result Log Result Name: MCM1_ 0004089_ 7112_ 1-- <core_client_version>7.2.42</core_client_version> <![CDATA[ <message> process exited with code 193 (0xc1, -63) </message> <stderr_txt> Commandline = ../../projects/www.worldcommunitygrid.org/wcgrid_mcm1_7.32_i686-pc-linux-gnu -SettingsFile MCM1_0004089_7112.txt -DatabaseFile dataset-17_72_SDG_v1.txt Settings File DateOfDesign = 11/08/2013 Designer = PMCC_OCI WorkOrderID = 4089_7112 DatasetID = 17_72_SDG_v1 NumberOfGenesInStartingSignature = 18 NumberOfGenesInSignatureMin = 10 NumberOfGenesInSignatureMax = 20 GroupVectorValues = {A}{B}{C}{D}{E}{F} ExplicitStartingGeneSignatures = A B D F StartingGeneSignatureAlgorithm = randomFixedLengthSearch SearchAlgorithmNumberToCreate = 1 SearchAlgorithmSequentialStartPosition = 5 RunPermutationAlgorithm = 1 PermutationGroups = A PermutationGroupsForReplacement = G PermutationAlgorithm = replaceFromRandomlyToRandomlyGreedy PermutationsNumIterations = 58274 OptimizationAlgorithmFrequency = 0 0 1 FBeta = 1.5 SimAnnealIMax = 20000 SimAnnealAlpha = 0.9996 NReps = 10 TrainFrac = 0.7 NFolds = 10 VMethod = LOO ModelType = SVM FitnessFn = 0 MinFitness = 0.61 SvmArgs = "-v 0 -c 0.1 -t 1 -d 2 -r 0" SvmLearnLimit = 500000 RSeed = 399807112 [17:00:14] Initializing ]]>
NAS - Eigenbau
----------------------------------------Xiaomi Mi 10T [Edit 1 times, last edit by LAZA74 at Apr 30, 2014 6:22:14 AM] |
||
|
|
seippel
Former World Community Grid Tech Joined: Apr 16, 2009 Post Count: 392 Status: Offline Project Badges: 
|
LAZA74,
Both work units you listed were able to be completd by your wingmen, so the work units themselves should be ok. The signal 8 error is a floating point exception and code 193 is a segmentation violation. Are you overclocking? If so, that may be causing the issue. Seippel |
||
|
|
LAZA74
Advanced Cruncher Germany Joined: Sep 28, 2008 Post Count: 56 Status: Offline Project Badges:
|
Thanks for your respond, Seippel.
----------------------------------------I changed the base clock from 200 to 202 MHz, and pushed the CPU +2% up. Now i changed it all back to "Auto" and will have an eye on it. More problems in FAAH with also Signal 8 may be indicate a hardware problem?
NAS - Eigenbau
Xiaomi Mi 10T |
||
|
|
seippel
Former World Community Grid Tech Joined: Apr 16, 2009 Post Count: 392 Status: Offline Project Badges:
|
If you see additional problems, you may also want to run some hardware checks (memtest86 or other). I'd wait to see if you have the problem without overclocking though. Running WCG more fully utilizes your computing resources, so it's not uncommon for problems to crop up here that aren't seen elsewhere under lower usage.
Seippel |
||
|
|
Speedy51
Veteran Cruncher New Zealand Joined: Nov 4, 2005 Post Count: 1220 Status: Offline Project Badges: 
|
I was under the understanding that mcm1.dataset-17_72_SDG_v1 which is a 31.94 meg file was a one-off download? This appears not to be the case. Yesterday or the day before I returned all of my Mapping Cancer tasks and I have just downloaded a fresh 24 tasks and the above file also downloaded. This is not an issue me as I have plenty of data but I can see this being a issue for people on limited bandwidth. Just thought I would let you know. As long as you have Mapping Cancer tasks in your queue the big file is not required to be downloaded. These are my observations
----------------------------------------Here are the lines out of my message log 2/06/2014 4:42:12 p.m. | World Community Grid | Started download of mcm1.dataset-17_72_SDG_v1.txt 2/06/2014 4:43:26 p.m. | World Community Grid | Finished download of mcm1.dataset-17_72_SDG_v1.txt 2/06/2014 4:43:27 p.m. | World Community Grid | Starting task MCM1_0004680_7599_0  |
||
|
|
seippel
Former World Community Grid Tech Joined: Apr 16, 2009 Post Count: 392 Status: Offline Project Badges:
|
Speedy51,
Your observations are correct. The dataset files for MCM1 will change multiple times over the life of the project. Once work units start with a new dataset, there generally won't be any need to run work units with the old dataset. For this reason, the client will delete it once you have no more work units running that need it. This is in contrast to files that span the entire life of the project (such as CEP2's qcaux.zip which is not deleted even if no CEP2 work units are running at that time). Seippel |
||
|
|
Speedy51
Veteran Cruncher New Zealand Joined: Nov 4, 2005 Post Count: 1220 Status: Offline Project Badges:
|
Thanks for the feedback Seippel.
----------------------------------------Every time a new copy is download is the name changed? I didn't note the name of the last file. When this happens again I will check. The way I look at it is to save bandwidth would it not make sense to keep in the project folder until a new one is downloaded to replace it? As you say the qcaux.zip file isn't deleted and it is over twice the size of the dataset file that is in question. 66.1 meg I am talking about 33.1 meg being kept in that the project folder [Edit 1 times, last edit by Speedy51 at Jun 3, 2014 5:22:40 AM] |
||
|
|
Falconet
Master Cruncher Portugal Joined: Mar 9, 2009 Post Count: 3265 Status: Offline Project Badges: 
|
What I think Seippel meant is that for each type of workunits the is a different dataset, but you won't be seeing new 33.1 MB files every time you download a new workunit. It only happens when it is of a different type.
----------------------------------------AMD Ryzen 5 1600AF 4C/8T 3.2 GHz - 85W AMD Ryzen 5 2500U 4C/8T 2.0 GHz - 28W Intel Z3740 4C/4T 1.8 GHz - 6W |
||
|
|
Speedy51
Veteran Cruncher New Zealand Joined: Nov 4, 2005 Post Count: 1220 Status: Offline Project Badges:
|
What I think Seippel meant is that for each type of workunits the is a different dataset, but you won't be seeing new 33.1 MB files every time you download a new workunit. It only happens when it is of a different type. This could be the case. Where I am coming from is if we can keep the dataset file in the project folder until a new copy is download it will save on bandwidth. I only noticed this issue when I completely run out of tasks. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
I think it most likely that the file would have a new name each time. Think about it. The new file has to be downloaded as soon as you get a WU that needs it. But you're going to have existing WUs that need the old one, and they have to all finish before the old file can be deleted. In an extreme case you might have WUs for three or more versions of the file on your machine. So long as they are deleted when you no longer have any WUs that need them, that will save space. The only disadvantage of that strategy is if you mix projects and sometimes have no MCM1 WUs at all. That might cause the file to be deleted and then downloaded again when you get another WU of the same "type".
All these decisions are trade-offs, but this sounds reasonable to me (as I would expect!). |
||
|
|
|