| log in |
|
61)
Message boards :
Number crunching :
Validation inconclusive.
(Message 1594)
Posted 10 Jul 2019 by Jim1348 It happens. I currently have one validation inconclusive with an Intel machine (I am on a Ryzen). But we both have a large number of valids, and no invalids. So I think the validator gets a little particular at times with different chips. |
|
62)
Message boards :
Science :
Scientific results (Comments)
(Message 1577)
Posted 9 Jun 2019 by Jim1348 Probably the best way to get known is just to list TN-Grid in the BOINC projects list. I hope they have taken care of that for the next BOINC release. Otherwise, it will be an uphill struggle. A GPU version would do it. There are volunteers around on the various projects who may have the expertise to do it, if they know about it. |
|
63)
Message boards :
Number crunching :
gene_work_generator Not Running
(Message 1551)
Posted 3 May 2019 by Jim1348 Yes, I just picked up a couple more. We are back in business. |
|
64)
Message boards :
Number crunching :
gene_work_generator Not Running
(Message 1548)
Posted 2 May 2019 by Jim1348 I will be out of work shortly. Is this being looked into? |
|
65)
Message boards :
Science :
Scientific results (Comments)
(Message 1546)
Posted 9 Apr 2019 by Jim1348 I don't understand the science, but you seem to have found one of the better biomedical applications for BOINC. It appears to have wide applicability, and is the type of thing that no single company would do. It benefits from public volunteer participation. |
|
66)
Message boards :
Number crunching :
EXXtreme Neverending deathloop wu computation Errors
(Message 1535)
Posted 5 Mar 2019 by Jim1348 I think you need to un-hide your computer. |
|
67)
Message boards :
Number crunching :
Biting off too much to crunch!
(Message 1514)
Posted 2 Mar 2019 by Jim1348 There seems to have been a whole lot of excessive WU downloading lately. My pending bin is steadily growing and has more than doubled the last day! :-( I have also seen that behavior a year or two ago. It is very strange. However, things are all OK for me now, and I have the expected number of work units (18). That is reasonable for my buffer size of 0.1 + 0.5 days, which is the default. Obviously, something gets messed up once in a while. Why don't you detach from the project, reset the buffer to the default size, and try again? It might straighten it out. |
|
68)
Message boards :
Number crunching :
Report Deadlines
(Message 1509)
Posted 15 Feb 2019 by Jim1348 From my experience, extending a task due date has more benefit than detriment. Especially when it has none, or almost zero ( I don't know of any ), impact on current users or even current tasks in process. If it is OK with the project, it is OK with me. But some projects need the result of one work unit to calculate the starting point for another. That is the case with Folding@Home in particular. In fact, they developed their own client for it (they don't use BOINC), so that as one work unit is 99% complete, they start downloading the next, in order to minimize the overlap. In effect, they keep a zero buffer. There are some BOINC ones that do something similar, except that they are not so strict in their requirements. It depends on the science. But in the extreme case of CPDN, since they have a one-year time limit, if a machine crashes and the work unit is lost, they don't even know about it for a year. So they can't send out a replacement until then. If you want to get your science done, you need something faster. |
|
69)
Message boards :
Number crunching :
Report Deadlines
(Message 1507)
Posted 15 Feb 2019 by Jim1348 Agreed Jim1348 if you're a single project researcher, but there are more projects than just one; and Boinc and the account managers are all designed and equipped to run multiple projects simultaneously. But not all projects run well with each other. CPDN is a famous example, with typical runs of 7 to 10 days (or more), and due dates of one year (ridiculous). It is best to just run it by itself, if you are willing to devote a machine to it. But I run multiple projects all the time. However, my machines run 24/7 and usually have no problem getting the work done. The complaints are usually from people who run their machines part time (especially laptops), and want the projects to accommodate their desire for long buffers. I wouldn't, since that delays the science for all of them. As far as "short turnarounds" go in relation to due dates, that's technically an irrelevant consideration because the task gets completed when the task gets completed. But the due date is relevant if the tasks don't get completed on time. Again, many people want the projects to accommodate their usage of their machines. I would do it the other way, and keep short buffers so that the machines can accommodate how the crunchers use them. Otherwise, the whole system (for all projects) is delayed, results are returned late, etc. (It is up to the projects to decide how best to maximize their output of course. I am just offering my own opinions.) |
|
70)
Message boards :
Number crunching :
Report Deadlines
(Message 1504)
Posted 15 Feb 2019 by Jim1348 I always keep the default buffer of 0.1 + 0.5 days, and like short turnarounds. You can always argue for special cases, but projects are designed to maximize the science (or should be designed that way). |
|
71)
Message boards :
Number crunching :
Report Deadlines
(Message 1493)
Posted 9 Feb 2019 by Jim1348 A five day deadline is normal. It appears that you downloaded too many initially, and that is why the last ones are having trouble finishing on time. It is probably due to inaccurate time estimates of the initial group of work units. That should be corrected over time, and after the first batch, it should be better (i.e., you download less each time you request them). That is the way the BOINC scheduler is supposed to work, and sometimes it does. But I am on Linux and Windows, and assume it will work out OK on ARM also. |
|
72)
Message boards :
Number crunching :
Can we multi-thread the TN-Grid wu's?
(Message 1489)
Posted 26 Jan 2019 by Jim1348 I think the short answer is "no", but a developer could answer more fully. However, the usual reason is to save memory. Since the work units here use less than 60 MB, there is not much reason to. You might just as well run more of them. They take less than four hours on my i7-4790 anyway under Ubuntu, and almost as fast under Windows. |
|
73)
Message boards :
Number crunching :
New TCGA workunits (TCGAz)
(Message 1454)
Posted 19 Dec 2018 by Jim1348 The 4th is STILL running at 12% completion after 377 hours (and 312 hours since the last checkpoint). All projects have stuck work units; some more than others. If the Progress % is not making any progress after a few hours (24 hours is more than enough time), then it is stuck in a loop. |
|
74)
Message boards :
Number crunching :
sse2 vs avx
(Message 1447)
Posted 18 Dec 2018 by Jim1348
The SSE2 problem for me (and Beyond) was only on the Ryzen 1700. The Ryzen 2700 is OK. Maybe you should amend your report? Thanks for looking into this. |
|
75)
Message boards :
Number crunching :
New TCGA workunits (TCGAz)
(Message 1440)
Posted 15 Dec 2018 by Jim1348 Now at 183 hours, and 156 hours since the last checkpoint (which is troubling). Still at 12%. I have seen a few of those. Before they get that far, I abort them. I think you are unnecessarily conscientious; they are duds. |
|
76)
Message boards :
Number crunching :
sse2 vs avx
(Message 1430)
Posted 11 Dec 2018 by Jim1348 Looking at the current applications it doesn't even show an fma version for Windows. Maybe v1.10 was the last fma version? I wish we could just pick the app(s) we want to run through project preferences. My Ryzen 1700 and 2700 machines are on Ubuntu 18.04, and yes the fma is version 1.10. But I used Windows earlier on an i7-3770, and it did quite well compared to Linux. But that one got only SSE2 and AVX. I think the latter was slightly faster. I agree; let us select them and be done with it. |
|
77)
Message boards :
Number crunching :
sse2 vs avx
(Message 1428)
Posted 11 Dec 2018 by Jim1348 Is fma faster than avx on the Ryzen 1700? It seems to be just slightly, though they are so close that it would take longer-term testing to be sure. I think it would be easier for the project to find the best extension for a given processor type, and just use it. |
|
78)
Message boards :
Number crunching :
sse2 vs avx
(Message 1425)
Posted 10 Dec 2018 by Jim1348 Thanks a lot. I substituted "fma" for "avx", and it is running fine on my Ryzen 1700, making it productive again. |
|
79)
Message boards :
Number crunching :
sse2 vs avx
(Message 1419)
Posted 8 Dec 2018 by Jim1348 I have a Ryzen 2700 that is only sent avx WUs. Everything is fine there. Recently I brought back my 2 Ryzen 1700 machines and after failing a few sse2 WUs I started aborting them. After a couple days they started getting only avx WUs (for a long time). Now all of a sudden they're being sent large numbers of sse2 WUs again. The sse2 WUs are unreliable and often fail after wasting a LOT of CPU time. I see the same thing. My Ryzen 1700 fails on most of the SSE2, but my Ryzen 2700 runs them OK. Both machines are on Ubuntu 18.04. http://gene.disi.unitn.it/test/results.php?hostid=26765&offset=0&show_names=0&state=6&appid= http://gene.disi.unitn.it/test/results.php?hostid=41785&offset=0&show_names=0&state=4&appid= I did not know the Ryzen 1700 had an SSE2 problem, but this is the only SSE2 project I have. It runs everything else fine. I suppose the problem will correct itself after the selection is made, so it may not be worth fixing at this point. |
|
80)
Message boards :
News :
New organism
(Message 1403)
Posted 3 Dec 2018 by Jim1348 We never had a GPU application available. OK, I must have been thinking of the optimized apps, which you have already incorporated. They are working well for me; about the same on Windows as Linux. Thanks. |