... they stopped using V1.57 and have gone back to V 1.52!
No they haven't. V1.57 is the beta test app (BRP6-Beta-cuda55) and V1.52 is the standard non-test app (BRP6-cuda32-nv301). You must have changed your preferences so that BOINC no longer has permission to run test apps. You would be advised to re-enable that setting as the test app uses cuda55 libs which gives significantly faster crunch times.
Is there a document or thread somewhere that explains how to read the stderr.txt file for E@H tasks?
Unfortunately, not that I know of.
Quote:
I know how to read my other projects but I can make no sense out of the reported result for E@H task that have been proclaimed invalid. I have tried to compare my result with the validated result and the output looks identical.
I'm not familiar with what gets included in this file for other projects, but here, (as far as I know) there are no actual results/answers in the file that would allow you to see differences between your task and any 'companion' one. Stderr.txt seems just to be informational messages about crunching progress. The actual 'results' are uploaded separately (I believe) and my understanding is that they are not human readable (at least not easily). I'm pretty sure I've see others (Richard Haselgrove springs to mind) talk about 'trapping' results in the small window of opportunity whilst they are being uploaded but I've never tried it or even taken any real notice of exactly what to do to achieve this.
Quote:
I must be missing something in the file. I have produced invalid results on this computer 12291110. It doesn't invalid on all tasks just some. I am wondering if these old GTX 670's can't hack processing E@H on the cards along with other projects at the same time. My GTX 970 machines have no problems.
You call 670's old??? :-). I have a couple of older 550Ti's and I think they're still OK :-). I have a bunch of HD4850's crunching away at Milkyway. They've been running for 7 years there. I guess they're kinda old!!! :-).
My strong feeling (even though I don't own one) is that a 670 should be fine for crunching here. I have 650's and a 650Ti and don't see any reason not to use them. I'd be very surprised if there wasn't some hardware related reason why you are getting some invalids with the 670. I have around 50 GPU's all crunching with the beta test app and none of them are producing significant numbers of invalid results. To me it doesn't seem likely there is any 'cross-platform' type of validation issue.
Yes, Richard Haselgrove often has me look at the results file (the science part that gets returned) for Seti@Home to determine just why an invalid got flagged. You look into the slot directory that the task ran in after it completes computation before the 5 minute upload timeout executes and uploads the file then deletes it. You just copy it to another non-BOINC directory for looking at later at your leisure. I have learned enough about the results structure to see some of the obvious mismatches with the validated results.
I think that the cards or computer must have just glitched or something. Nothing has changed in the card or computer parameters since I put it together. I returned good results right after startup, had a couple of good days, then had a couple of bad days and then returned to producing good results again after I noticed the invalids and posted this question.
There certainly is no issue with overclocking or temperature. I'm running two tasks per card across 3 projects. I have good system cooling and the card temperatures are running around 52-55C fully loaded at all times. The 670s's actually run cooler than my 970's even though they dissipate more watts. The 970's are of course running a lot faster and produce more heat because they are doing more work.
I just looked at the validation logs and forwarded that information to the scientist. It seems your faulty GPU is reporting a value that is considered out-of-bounds for a valid result. We are checking if there is an explanation from the scientific point of view but I suspect the card can't do math anymore (at least the kind of math BRP6 needs).
I suspect the card can't do math anymore (at least the kind of math BRP6 needs).
or just does not get the answer right when running clock at the current speed.
If a thought-to-be good CPU or GPU is getting wrong answers, first resort is often temperature-related (look for lint in the cooling fins, check the temps) and if there is nothing to fix there, second resort is turn the clock(s) down. I give the same answer whether it is severely overclocked, slightly, or not at all. And just because it runs some other work OK is not in itself evidence that slower might heal. Not all computation poses the same speed problem to the part.
I have GPUs at clocks that run fine on some projects and get computation errors almost immediately on other projects. Backing off the GPU core clock allows them to all run.
Think of it as running a game and it had some tearing on the game image or odd colored blocks. Thats a bad computation and the wrong color'd pixel was displayed. Here it produced some odd number the project doesn't like.
Well that's all fine and that .. I have two other 670's on the shelf I can try. Trouble is how do I determine how BOINC enumerates identical cards. Add to the confusion that E@H doesn't report the core speed in the stderr.txt file like Seti does for example for easier identification of small core running speed differences. More confusion is that a invalid result in the cases of the longer running BRP6 tasks have been run on both cards during the processing because of how BOINC moves waiting tasks to the first available card when the project resource rotation moves the task back active. From looking at the valid BRP4 tasks which can finish on the same card before being switched out to other projects, I believe card #1 is doing valid math making card #0 being the bad culprit. This is going to take some detective work unless someone points me at a simple way to determine which card is #0 according to BOINC. Any suggestions??
I've been busy showing a house-guest round Yorkshire the last couple of days, but I thought I felt my ears burning - and it certainly wasn't the sun.
Quote:
I'm pretty sure I've see others (Richard Haselgrove springs to mind) talk about 'trapping' results in the small window of opportunity whilst they are being uploaded but I've never tried it or even taken any real notice of exactly what to do to achieve this.
So, this is what happens at the end of a job. I'll use task PM0134_04961_330_0 - Binary Radio Pulsar Search (Parkes PMPS XT) v1.52 (BRP6-Beta-opencl-intel_gpu) as an example.
1) A science result file is put into the Einstein project directory. (In fact, for BRP6, two science files, in this example called PM0134_04961_330_0_0 and PM0134_04961_330_0_1)
2) stderr_txt is copied into the master client_state.xml record for your BOINC installation, and merged with the result timing data etc.
3) The science result file(s) are uploaded immediately to the Einstein data server - a simple file transfer, and very quick. If you happen to be watching the Transfers tab in BOINC Manager, you'll see them flash past. Or you can inspect the Event Log later:
08/07/2016 18:07:30 | Einstein@Home | Started upload of PM0134_04961_330_0_0
08/07/2016 18:07:30 | Einstein@Home | Started upload of PM0134_04961_330_0_1
08/07/2016 18:07:31 | Einstein@Home | Finished upload of PM0134_04961_330_0_0
08/07/2016 18:07:31 | Einstein@Home | Finished upload of PM0134_04961_330_0_1
One second, the pair of them. I said it was quick. And as soon as the upload has completed, the science data is deleted from your machine.
4) At this point, the Task status shown in the Manager is changing from 'running' to 'uploading' to 'ready to report'.
5) Some time later (up to an hour later, or when new work is needed, or when you click the project 'update' button), the task completion is 'reported'. This transfers the control and statistical data for the task to the project scheduling server, via a file called 'sched_request_einstein.phys.uwm.edu.xml': this contains stderr_txt, but does not contain the science data uploaded at step 3.
6) On receipt of the completion report, the scheduling server is alerted to the need to validate the uploaded science already present in its data vault.
So, what to do when things are going wrong on the validation front? The simplest way is to suspend networking when you see that a task will finish soon - or simply pull the network cable, if you prefer. If the science data file can't be uploaded, none of the other steps can happen either - and you have all the time in the world to copy them. Do remember to re-enable networking, or plug the cable back in, when you've finished.
I did that for my sample task. The _0 data file looked like this: I don't think we're going to have much success reproducing the validator processes manually.
Yes, Richard Haselgrove often has me look at the results file (the science part that gets returned) for Seti@Home to determine just why an invalid got flagged. You look into the slot directory that the task ran in after it completes computation before the 5 minute upload timeout executes and uploads the file then deletes it. You just copy it to another non-BOINC directory for looking at later at your leisure. I have learned enough about the results structure to see some of the obvious mismatches with the validated results.
Each project is free to choose its own result file format. SETI uses an XML structure which is easy to decipher by eye: as the sample I've just posted shows, Einstein's format is denser and more technical.
Again, each project sets its own timetable: Einstein has a one-minute timeout, compared to SETI's five. And that timeout is for the reporting stage: you can rely on 'sched_request_setiathome.berkeley.edu.xml' (with embedded std_err_txt) remaining accessible for five minutes before it's over-written by the next one, but that doesn't help with science result validation. You still only get
08/07/2016 18:39:19 | SETI@home | Started upload of blc3_2bit_guppi_57451_71786_HIP117779_OFF_0030.11738.0.18.27.107.vlar_1_0
08/07/2016 18:39:23 | SETI@home | Finished upload of blc3_2bit_guppi_57451_71786_HIP117779_OFF_0030.11738.0.18.27.107.vlar_1_0
four seconds to catch it. Better to use the network trick.
Trouble is how do I determine how BOINC enumerates identical cards.
BOINC labels tasks by device number while running:
You could, as here, run different projects on each card, and use the SETI information to deduce, by elimination, the identity of the one which Einstein is running on. Or suspend all tasks except enough to fill one card, and apply the finger test - which card is still running hot?
And don't forget coproc_info.xml:
Quote:
1
GeForce GTX 970
...
13
1
0
0
1
GeForce GTX 750 Ti
...
5
6
0
0
I know I run GPUGrid on my fast card, so BOINC device 0 is in PCIe bus_id 1 (on this motherboard). And so on.
RE: ... they stopped using
)
No they haven't. V1.57 is the beta test app (BRP6-Beta-cuda55) and V1.52 is the standard non-test app (BRP6-cuda32-nv301). You must have changed your preferences so that BOINC no longer has permission to run test apps. You would be advised to re-enable that setting as the test app uses cuda55 libs which gives significantly faster crunch times.
Cheers,
Gary.
RE: Is there a document or
)
Unfortunately, not that I know of.
I'm not familiar with what gets included in this file for other projects, but here, (as far as I know) there are no actual results/answers in the file that would allow you to see differences between your task and any 'companion' one. Stderr.txt seems just to be informational messages about crunching progress. The actual 'results' are uploaded separately (I believe) and my understanding is that they are not human readable (at least not easily). I'm pretty sure I've see others (Richard Haselgrove springs to mind) talk about 'trapping' results in the small window of opportunity whilst they are being uploaded but I've never tried it or even taken any real notice of exactly what to do to achieve this.
You call 670's old??? :-). I have a couple of older 550Ti's and I think they're still OK :-). I have a bunch of HD4850's crunching away at Milkyway. They've been running for 7 years there. I guess they're kinda old!!! :-).
My strong feeling (even though I don't own one) is that a 670 should be fine for crunching here. I have 650's and a 650Ti and don't see any reason not to use them. I'd be very surprised if there wasn't some hardware related reason why you are getting some invalids with the 670. I have around 50 GPU's all crunching with the beta test app and none of them are producing significant numbers of invalid results. To me it doesn't seem likely there is any 'cross-platform' type of validation issue.
Cheers,
Gary.
Yes, Richard Haselgrove often
)
Yes, Richard Haselgrove often has me look at the results file (the science part that gets returned) for Seti@Home to determine just why an invalid got flagged. You look into the slot directory that the task ran in after it completes computation before the 5 minute upload timeout executes and uploads the file then deletes it. You just copy it to another non-BOINC directory for looking at later at your leisure. I have learned enough about the results structure to see some of the obvious mismatches with the validated results.
I think that the cards or computer must have just glitched or something. Nothing has changed in the card or computer parameters since I put it together. I returned good results right after startup, had a couple of good days, then had a couple of bad days and then returned to producing good results again after I noticed the invalids and posted this question.
There certainly is no issue with overclocking or temperature. I'm running two tasks per card across 3 projects. I have good system cooling and the card temperatures are running around 52-55C fully loaded at all times. The 670s's actually run cooler than my 970's even though they dissipate more watts. The 970's are of course running a lot faster and produce more heat because they are doing more work.
I just looked at the
)
I just looked at the validation logs and forwarded that information to the scientist. It seems your faulty GPU is reporting a value that is considered out-of-bounds for a valid result. We are checking if there is an explanation from the scientific point of view but I suspect the card can't do math anymore (at least the kind of math BRP6 needs).
RE: I suspect the card
)
or just does not get the answer right when running clock at the current speed.
If a thought-to-be good CPU or GPU is getting wrong answers, first resort is often temperature-related (look for lint in the cooling fins, check the temps) and if there is nothing to fix there, second resort is turn the clock(s) down. I give the same answer whether it is severely overclocked, slightly, or not at all. And just because it runs some other work OK is not in itself evidence that slower might heal. Not all computation poses the same speed problem to the part.
I have GPUs at clocks that
)
I have GPUs at clocks that run fine on some projects and get computation errors almost immediately on other projects. Backing off the GPU core clock allows them to all run.
Think of it as running a game and it had some tearing on the game image or odd colored blocks. Thats a bad computation and the wrong color'd pixel was displayed. Here it produced some odd number the project doesn't like.
Well that's all fine and that
)
Well that's all fine and that .. I have two other 670's on the shelf I can try. Trouble is how do I determine how BOINC enumerates identical cards. Add to the confusion that E@H doesn't report the core speed in the stderr.txt file like Seti does for example for easier identification of small core running speed differences. More confusion is that a invalid result in the cases of the longer running BRP6 tasks have been run on both cards during the processing because of how BOINC moves waiting tasks to the first available card when the project resource rotation moves the task back active. From looking at the valid BRP4 tasks which can finish on the same card before being switched out to other projects, I believe card #1 is doing valid math making card #0 being the bad culprit. This is going to take some detective work unless someone points me at a simple way to determine which card is #0 according to BOINC. Any suggestions??
I've been busy showing a
)
I've been busy showing a house-guest round Yorkshire the last couple of days, but I thought I felt my ears burning - and it certainly wasn't the sun.
So, this is what happens at the end of a job. I'll use task PM0134_04961_330_0 - Binary Radio Pulsar Search (Parkes PMPS XT) v1.52 (BRP6-Beta-opencl-intel_gpu) as an example.
1) A science result file is put into the Einstein project directory. (In fact, for BRP6, two science files, in this example called PM0134_04961_330_0_0 and PM0134_04961_330_0_1)
2) stderr_txt is copied into the master client_state.xml record for your BOINC installation, and merged with the result timing data etc.
3) The science result file(s) are uploaded immediately to the Einstein data server - a simple file transfer, and very quick. If you happen to be watching the Transfers tab in BOINC Manager, you'll see them flash past. Or you can inspect the Event Log later:
One second, the pair of them. I said it was quick. And as soon as the upload has completed, the science data is deleted from your machine.
4) At this point, the Task status shown in the Manager is changing from 'running' to 'uploading' to 'ready to report'.
5) Some time later (up to an hour later, or when new work is needed, or when you click the project 'update' button), the task completion is 'reported'. This transfers the control and statistical data for the task to the project scheduling server, via a file called 'sched_request_einstein.phys.uwm.edu.xml': this contains stderr_txt, but does not contain the science data uploaded at step 3.
6) On receipt of the completion report, the scheduling server is alerted to the need to validate the uploaded science already present in its data vault.
So, what to do when things are going wrong on the validation front? The simplest way is to suspend networking when you see that a task will finish soon - or simply pull the network cable, if you prefer. If the science data file can't be uploaded, none of the other steps can happen either - and you have all the time in the world to copy them. Do remember to re-enable networking, or plug the cable back in, when you've finished.
I did that for my sample task. The _0 data file looked like this: I don't think we're going to have much success reproducing the validator processes manually.
00000000 1F 8B 08 00 00 00 00 00 00 0B 95 99 4B 8F 1C C7 .‹........•™K..Ç
00000010 11 84 EF 04 F8 1F FA 42 40 86 C1 46 65 3D B2 AA .„ï.ø.úB@†ÃFe=²ª
00000020 F6 28 4B 80 7C 91 04 C1 3E 13 B3 BB 43 99 80 40 ö(K€|‘.Ã>.³»C™€@
00000030 0A 24 2D C9 FF DE 5F 64 F5 3C 04 9D 48 DB B2 B8 .$-ÉÿÞ_dõl
00000050 69 FB EA A7 77 4F FF 39 7D 7C DE BE 3B 7D 3A FF iûê§wOÿ9}|Þ¾;}:ÿ
00000060 F2 F3 C7 0F BF 9D FF F6 F2 C5 AB ED BB 0F 9F 3E òóÇ.¿.ÿöòūû.Ÿ>
00000070 3F 6C 96 92 35 AF DB 57 D9 1E DB 38 5B EB CF E5 ?l–’5¯ÛWÙ.Û8[ëÃÃ¥
00000080 F4 7C 9E E3 69 9C 9E E6 B9 9C ED EC 27 2B F5 39 ô|žãiœžæ¹œÃì'+õ9
00000090 BE F3 CD E9 F3 F9 61 CB C9 FC 75 EA AF D3 F8 97 ¾óÃéóùaËÉüuê¯Óø—
000000A0 E5 87 9A 1F 6C FC 3D A5 87 94 F4 91 6F FF 38 3F 凚.lü=¥‡â€Ã´â€˜oÿ8?
000000B0 3D 6C E7 77 EF 3F 7D E6 1F 8F EF DE 9F 3E FE EF =lçwï?}æ..ïÞŸ>þï
000000C0 CD D7 3F FD E8 6F 6C 6F F9 CD EF EF DE 3F 7F F8 Ã×?ýèoloùÃïïÞ?.ø
000000D0 FD D3 9B 3F 86 BF F1 FA 26 7E F3 FA EB F3 E7 D3 ýÓ›?†¿ñú&~óúëóçÓ
000000E0 EB 0F BF 9E DF 3F FD F2 FA DD FB CF E7 5F DE FC ë.¿žß?ýòúÃûÃç_Þü
000000F0 FC EB 7F F7 F3 1F E7 30 F8 D3 8F DB CF EF 3E 6F üë.÷ó.ç0øÓ.ÛÃï>o
00000100 EF 9E 31 6B A9 A5 D3 78 7E FB 5C 4F A7 C7 F4 3C ïž1k©¥Óx~û\O§Çôž.Û.
00000130 36 7F 1C F3 29 3F 8F 32 CE 4F A5 9D 9F CB E3 DB 6..ó)?.2ÎO¥.ŸËãÛ
00000140 C7 27 6B 8F CF 27 1F B3 CC 27 7F 7A 1E AD 3D E7 Ç'k.Ã'.³Ì'.z..=ç
00000150 97 2F 5E BE 70 DB 47 6A CD DD 9A CD D2 37 B7 EE —/^¾pÛGjÃÃÅ¡ÃÃ’7·î
00000160 7B 4D 9E 5B 5A 7F B6 B4 37 6B AD A6 9A C9 DE DC {Mž[Z.¶´7k.¦šÉÞÜ
00000170 F2 9E 7D 98 B7 91 BD CF BE E5 CC AF 73 DD 2C EF òž}˜·‘½Ã¾å̯sÃ,ï
00000180 C5 52 DD 30 6A DE F7 9E 7B 1F 23 F3 B8 31 B6 9E Ã…RÃ0jÞ÷ž{.#ó¸1¶ž
00000190 6A DD 6B B5 31 6B 2B 86 65 D9 CC 56 72 6A C3 6A jÃkµ1k+†eÙÌVrjÃj
000001A0 71 6C 26 9E 3E AD 27 B3 EC CB 66 1A 61 33 CD 26 ql&ž>.'³ìËf.a3Ã&
000001B0 9B B8 D9 E7 CC 69 94 5C CC 6D 6B B5 B7 3D F7 3A ›¸ÙçÌiâ€\ÃŒmkµ·=÷:
000001C0 53 2E B5 F4 30 59 BC D7 E1 C3 6B C9 03 93 D6 F8 S.µô0Y¼×áÃkÉ.“Öø
000001D0 65 4E 33 0F 9B 32 59 06 DF C3 64 2E 2D 1F 26 07 eN3.›2Y.ßÃd.-.&.
000001E0 70 70 1E DC 6B EF 5B F3 31 F6 51 6B 2E F8 7D 78 pp.Ükï[ó1öQk.ø}x
000001F0 59 26 CF 29 75 B4 69 32 89 B5 32 7B 97 C9 F0 B2 Y&Ã)u´i2‰µ2{—Éð²
00000200 94 1E 5E E6 E4 E1 65 CD 7B 9D DD F9 C2 E8 8E E3 â€.^æäáeÃ{.ÃùÂèŽã
00000210 AD CE B2 7B 9B 4E AA 7C 2C 2F 6D 14 1E 3A 47 F3 .β{›Nª|,/m..:Gó
00000220 C6 07 88 21 15 1B FC AF 18 DE 91 FA CE F7 30 69 Æ.ˆ!..ü¯.Þ‘úÎ÷0i
00000230 B3 DB 36 0E 2F 79 A8 3B AE D4 B2 B5 39 8C 87 8C ³Û6./y¨;®Ô²µ9Œ‡Œ
00000240 54 C3 60 D4 87 5F 4C 6F 9D 8C 7A D4 A7 E0 E2 E0 TÃ`Ô‡_Lo.Å’zÔ§à âÃ
00000250 6F B3 45 E0 A9 94 A8 4F CA D7 C0 A9 9C DB 18 72 o³Eà ©â€Â¨OÊ×À©œÛ.r
00000260 8D C0 F3 C0 EF 3C 49 44 B6 C3 4B 00 46 BD F1 BA .ÀóÀïsM-wk
000002D0 25 E5 CD DA 3E 95 31 4C 3A A5 55 32 CB D8 53 9D %Ã¥ÃÚ>•1L:Â¥U2ËØS.
000002E0 19 20 03 4B 2A DA B2 A7 7D F4 7A 01 91 4C 26 BE . .K*Ú²§}ôz.‘L&¾
000002F0 DE 13 48 1C A0 BB 50 2E E0 43 DB F0 DB 2E 93 63 Þ.H. »P.à CÛðÛ.“c
00000300 5A 95 49 F0 5F 65 D2 AC EE 5E 3B F6 2A 3F 22 C1 Z•Ið_eÒ¬î^;ö*?"Ã
00000310 64 15 18 99 5F 7B 08 9B 3D 7B EE 4D F0 F5 21 08 d..™_{.›={îMðõ!.
00000320 CC 3A 2D F5 59 01 CB 66 9D 4F D7 16 36 81 D9 56 Ì:-õY.Ëf.O×.6.ÙV
00000330 5F BE 98 73 C7 47 99 24 55 35 93 CC E2 7B 26 13 _¾˜sÇG™$U5“Ìâ{&.
00000340 77 60 AF FA 36 28 A8 7A 26 20 A3 D9 A6 81 37 1F w`¯ú6(¨z& £Ù¦.7.
00000350 45 26 FB A8 16 26 4B 9D 32 19 35 77 7C B6 D2 29 E&û¨.&K.2.5w|¶Ò)
00000360 D3 D6 08 6F F7 DE C9 2E 98 3E 6A 6E 9D D6 35 A7 ÓÖ.o÷ÞÉ.˜>jn.Ö5§
00000370 6B 9B 6A 4E AA F8 EC 2C A9 24 D5 DC 66 1B 61 32 k›jNªøì,©$ÕÜf.a2
00000380 F7 55 73 DB 21 A2 34 DA 28 AD 77 B0 2C E6 08 DC ÷UsÛ!¢4Ú(.w°,æ.Ü
00000390 47 8F 2F 64 F2 EB 9A EB 80 3D 04 76 60 2F F8 83 G./dòëšë€=.v`/øƒ
000003A0 BA 19 F5 E1 B7 E1 25 E9 20 11 7E A1 8E 54 BB F7 º.õá·á%é .~¡ŽT»÷
000003B0 E1 79 FA 86 3F EA E4 DE 0D 23 97 D0 C1 56 11 03 áyú†?êäÞ.#—ÃÃV..
000003C0 F1 98 0D BC CC 3E 5A 01 B7 26 A8 D2 41 74 69 18 ñ˜.¼Ì>Z.·&¨ÒAti.
000003D0 ED CA 2A 36 E7 6E 10 C3 A4 39 3A 85 A7 E8 AD 12 ÃÊ*6çn.ä9:…§è..
000003E0 C4 35 F2 60 23 30 95 89 73 94 A9 0E 22 89 A9 67 Ä5ò`#0•‰sâ€Â©."‰©g
000003F0 68 04 4E 08 3F 01 C0 32 09 C3 5D FD AC 8D BE 83 h.N.?.À2.Ã]ý¬.¾ƒ
00000400 1A 7D A4 8D AE 2D 7B E7 5F 4B BB 1A 95 85 9C 29 .}¤.®-{ç_K».•…œ)
00000410 5E 2F D1 43 7C 9A 3F 4D 04 A6 7C 26 9A 2B 8C 42 ^/ÑC|š?M.¦|&š+ŒB
00000420 A7 17 3E B2 52 1A 75 A5 0D C5 9A A9 EE 19 FE 69 §.>²R.u¥.Åš©î.þi
00000430 A3 5D 4A D4 73 2E 0A 84 4A CB 64 E9 7C 21 AB 71 £]JÔs..„JËdé|!«q
00000440 E6 08 93 69 A5 13 50 5E 88 18 CC 09 44 4E 07 13 æ.“i¥.P^ˆ.Ì.DN..
00000450 BA CD 01 7D 5B 2E 07 7D 60 D2 93 7C 04 BB 83 B4 ºÃ.}[..}`Ò“|.»ƒ´
00000460 F9 9E 80 19 3E 14 CF 00 27 A7 7D FA CA A6 12 1C ùž€.>.Ã.'§}úʦ..
00000470 36 A9 87 F0 4A CA A9 51 E1 2B D6 28 49 B9 01 5E 6©‡ðJÊ©Qá+Ö(I¹.^
00000480 48 4A A5 06 9F 8F 9C B7 BA D3 4E 70 2E 4C 5B 53 HJ¥.Ÿ.œ·ºÓNp.L[S
00000490 E0 BD C1 55 61 B3 D5 03 9B B4 B1 83 F7 52 BD 80 à ½ÃUa³Õ.›´±ƒ÷R½€
000004A0 13 FA 09 13 D6 0F EA 58 44 3C F9 C1 60 2A 60 91 .ú..Ö.êXD7&1ߺ.sENË
00000520 4E 68 D0 AB 35 72 69 25 89 45 E6 18 82 62 DB C5 Nhë5ri%‰Eæ.‚bÛÅ
00000530 84 61 13 E6 BB CE 0B 60 48 C7 74 75 99 13 12 D9 „a.æ»Î.`HÇtu™..Ù
00000540 6B C9 E6 6D F6 32 36 CB 68 19 F6 8E C8 53 4E 40 kÉæmö26Ëh.öŽÈSN@
00000550 97 C0 94 08 22 67 DE 84 49 71 C7 65 50 02 70 BA —Àâ€."gÞ„IqÇeP.pº
00000560 8E F4 8E CD 71 0D B7 E6 D5 4D 99 1C 9A 69 14 70 ŽôŽÃq.·æÕMâ„¢.Å¡i.p
00000570 2C 93 D4 0A 52 06 CF 42 0D 89 E9 0B EB 00 DB 83 ,“Ô.R.ÃB.‰é.ë.Ûƒ
00000580 3B 88 93 11 32 95 CE 9C E1 7D 8D 7F 7E 92 0E A8 ;ˆ“.2•Îœá}..~’.¨
00000590 2F 9B A8 0E 80 0D AF 10 6A 15 79 B8 34 40 45 24 /›¨.€.¯.j.y¸4@E$
000005A0 6C 19 26 CE 6B 5E 00 AC D5 E7 42 26 3C 43 E0 41 l.&ÃŽk^.¬ÕçB&.î.®â€.üÓ
000005C0 54 C4 90 29 93 8E 12 06 40 66 09 FA C4 66 42 0A TÄ.)“Ž..@f.úÄfB.
000005D0 D5 A3 CF 53 45 87 29 A1 B0 B5 20 49 E7 AA 68 76 Õ£ÃSE‡)¡°µ Içªhv
000005E0 1D 42 04 4E 8F 41 EA 99 2F AB 89 61 5D 74 14 C4 .B.N.Aê™/«‰a]t.Ä
000005F0 27 3F 09 3D FC 44 85 C8 CB 34 24 B8 C0 61 E3 3F '?.=üD…ÈË4$¸Àaã?
00000600 55 16 27 2A A0 5D 86 DA 8A 3C CB 20 8F A8 4A 1F U.'* ]†ÚŠVTÄ.n.[Y˜.p#
00000970 9B 79 67 D2 64 8F 9C 13 0A A0 A6 08 7F 9E E5 8D ›ygÒd.œ.. ¦..žå.
00000980 EA EA 01 42 63 90 26 A2 90 EE 98 55 12 9E 6C DA êê.Bc.&¢.î˜U.žlÚ
00000990 32 19 8D 84 49 A6 85 D6 72 FE 3E C5 47 6B A1 44 2..„I¦…Örþ>ÅGk¡D
000009A0 EC 64 BF A9 2D FA 27 C6 13 52 5E D4 4E A2 91 13 ìd¿©-ú'Æ.R^ÔN¢‘.
000009B0 4D CB 46 16 DA B5 90 C9 A6 E6 7D F4 79 67 5F 15 MËF.Úµ.ɦæ}ôyg_.
000009C0 30 18 BF 0C 16 90 84 98 13 7B AF 21 B9 8A 8E 64 0.¿...„˜.{¯!¹ŠŽd
000009D0 A7 46 4C 9C CA 3C A1 B1 41 0C 51 E8 7A 12 72 98 §FLœÊ
00000CC0 56 C9 D3 D2 6F F4 C2 0D 98 53 9A 90 3D C1 C4 C0 VÉÓÒoôÂ.ËœSÅ¡.=ÃÄÀ
00000CD0 F0 BC CE 67 F7 73 97 38 44 E1 35 36 09 48 05 CD ð¼Îg÷s—8Dá56.H.Ã
00000CE0 45 0F 17 5D 83 28 0F 8A 22 50 E4 92 73 41 C1 EA E..]Æ’(.Å "Pä’sAÃê
00000CF0 28 12 83 4E E0 77 DA FB A6 C4 F1 55 5E 8B 35 92 (.ƒNà wÚû¦ÄñU^‹5’
00000D00 AE B0 50 7F D7 65 65 D7 4E C7 C0 D7 75 3E 0E 27 ®°P.×ee×NÇÀ×u>.'
00000D10 B5 44 F7 78 AC 2C BE E6 19 7D 03 86 18 0E 39 AE µD÷x¬,¾æ.}.†..9®
00000D20 CD B4 F1 DD F0 59 93 5C 0F C1 57 88 51 FA 47 27 ôñÃðY“\.ÃWˆQúG'
00000D30 F4 34 75 19 09 93 16 DD E3 B1 9C 7A 78 09 DF A1 ô4u..“.Ã㱜zx.ß¡
00000D40 B6 AA AE F3 34 79 03 97 7C DD EF 3A 92 F2 30 98 ¶ª®ó4y.—|Ãï:’ò0Ëœ
00000D50 48 21 D4 A1 6B A6 9A 1E 5E AB 69 29 42 BA 75 B9 H!Ô¡k¦š.^«i)Bºu¹
00000D60 69 87 9B 45 5A A9 64 89 CF 11 1C FC A5 B4 5E A5 i‡›EZ©d‰Ã..ü¥´^Â¥
00000D70 05 57 C9 C1 49 68 AD 38 48 88 2E 18 AD 53 35 47 .WÉÃIh.8Hˆ...S5G
00000D80 79 EB 0E 88 66 4E 17 C5 81 76 10 B0 0D A1 63 D2 yë.ˆfN.Å.v.°.¡cÒ
00000D90 EC 8C 5F 5C 54 DB 75 C1 88 C2 2C 93 25 EE 8E 36 ìŒ_\TÛuÈÂ,“%îŽ6
00000DA0 C4 F0 53 58 0F 42 14 5E 04 31 BB 3B EF B8 D6 37 ÄðSX.B.^.1»;ï¸Ö7
00000DB0 7A A1 D2 ED D2 1B 26 69 42 B1 3C 1F C9 5C BA 48 z¡ÒÃÃ’.&iB±GG
00000DF0 10 9C 66 CB 17 DF D9 49 66 71 5B 16 B3 DF 96 34 .œfË.ßÙIfq[.³ß–4
00000E00 B6 EC 35 BA B5 FF 0C 65 97 A5 FB D6 3F 62 16 B5 ¶ì5ºµÿ.e—¥ûÖ?b.µ
00000E10 C4 5C 2F 42 2C 76 5E D6 0A 48 59 B9 CC A9 1F 26 Ä\/B,v^Ö.HY¹Ì©.&
00000E20 ED 72 72 05 3E 53 B7 63 D3 FA D9 D8 D1 29 F2 15 Ãrr.>S·cÓúÙØÑ)ò.
00000E30 46 21 8B 6C C2 E3 53 8B 36 0B 29 B9 9E 9A 47 22 F!‹lÂãS‹6.)¹žšG"
00000E40 FB 98 91 65 2D 16 5A 91 42 B1 13 A6 76 0A 88 80 û˜‘e-.Z‘B±.¦v.ˆ€
00000E50 59 AB D7 35 29 AB 20 F5 78 5B B3 BA 1C 5A 87 F7 Y«×5)« õx[³º.Z‡÷
00000E60 6C 4D 34 12 10 93 5F 2F C8 56 E0 B6 BC E4 87 D7 lM4..“_/ÈVà ¶¼ä‡×
00000E70 23 61 D5 4A 40 CA DB FC 62 05 23 27 7D 8D 1F D0 #aÕJ@ÊÛüb.#'}..Ã
00000E80 B2 78 5D 1A D5 25 95 86 6A AD BD 4F 24 58 AE 47 ²x].Õ%•†j.½O$X®G
00000E90 A8 D8 A1 BB 4E 26 E2 60 95 47 AF 16 E0 CC A4 37 ¨Ø¡»N&â`•G¯.à ̤7
00000EA0 81 5B EC 10 25 80 C9 7C F5 98 68 F4 24 01 0E 01 .[ì.%€É|õ˜hô$...
00000EB0 0F 37 5D FC 06 31 A7 3F 11 BB 36 7B 65 92 1F D4 .7]ü.1§?.»6{e’.Ô
00000EC0 38 3C EA 62 A1 61 C4 D2 10 36 53 5B 36 53 10 BB 8¶nñ.ôú¢j.à Š.4Vt
00000FD0 9C D7 EE A4 FE D4 AB 28 8B 9D 4A E7 85 30 69 B1 œ×î¤þÔ«(‹.Jç…0i±
00000FE0 47 C7 4D 1C 0D B3 CE CB 82 03 1A 05 6E 3E B6 D3 GÇM..³ÎË‚...n>¶Ó
00000FF0 83 E2 66 70 01 D2 B6 07 B7 D3 F2 70 10 40 68 31 ƒâfp.Ò¶.·Óòp.@h1
00001000 29 F9 DE 2A BA DE 48 63 53 EF 7B 98 14 EA D2 8E )ùÞ*ºÞHcSï{˜.êÒŽ
00001010 B8 A1 E6 4C 4A 5A E8 FE 8D 74 C5 67 66 19 3B 95 ¸¡æLJZèþ.tÅgf.;•
00001020 8A AC 05 55 D3 0A A0 2C A1 89 62 59 05 92 EC A2 Š¬.UÓ. ,¡‰bY.’ì¢
00001030 40 2C CD 43 E7 35 C6 7D 21 D8 2F 7E 45 A7 8D AC @,ÃCç5Æ}!Ø/~E§.¬
00001040 2D 68 42 CF 01 A3 57 DF FC F0 FD B7 AF 5E BE F8 -hBÃ.£Wßüðý·¯^¾ø
00001050 3F 84 59 F6 6A C7 21 00 00 ?„YöjÇ!..
(output from the HxD Hex editor: the actual file is raw binary)
RE: Yes, Richard Haselgrove
)
Each project is free to choose its own result file format. SETI uses an XML structure which is easy to decipher by eye: as the sample I've just posted shows, Einstein's format is denser and more technical.
Again, each project sets its own timetable: Einstein has a one-minute timeout, compared to SETI's five. And that timeout is for the reporting stage: you can rely on 'sched_request_setiathome.berkeley.edu.xml' (with embedded std_err_txt) remaining accessible for five minutes before it's over-written by the next one, but that doesn't help with science result validation. You still only get
four seconds to catch it. Better to use the network trick.
RE: Trouble is how do I
)
BOINC labels tasks by device number while running:
You could, as here, run different projects on each card, and use the SETI information to deduce, by elimination, the identity of the one which Einstein is running on. Or suspend all tasks except enough to fill one card, and apply the finger test - which card is still running hot?
And don't forget coproc_info.xml:
I know I run GPUGrid on my fast card, so BOINC device 0 is in PCIe bus_id 1 (on this motherboard). And so on.