Posts by Ian&Steve C.
|
1)
(Message 9052)
Posted 12 days ago by Ian&Steve C. Post: It's not an antivirus issue. I don't run any antivirus software and I have had nothing but download errors for all YETI's issue is slightly different. he has issues downloading the app binary from the project. and that happened during the last formula-boinc sprint (when most other people we're having the same issue). from June 26-29. he had other hosts working fine during this time. the issue you're facing now is probably related to some project issue that you first reported from July 1, two days later affecting all hosts. |
|
2)
(Message 9047)
Posted 15 days ago by Ian&Steve C. Post: sounds like your antivirus settings were blocking the download. |
|
3)
(Message 9043)
Posted 18 days ago by Ian&Steve C. Post: Yes, it is very wasteful of our resources. Even with my ability to run the correct app, I more than likely will waste my computation on the task since it is unlikely I get a wingman who is running the correct app version to have my tasks validated. I waste normally half a dozen to a dozen or more tasks a day that end up erroring out after 7 other wingmen fail to run the task correctly. it's really only wasteful for the few folks who have a working application for the tasks with lc_points too high. everyone else the tasks fail almost instantly and waste no time. i think i've had more success than invalids from the batch and there have been a few instances where i got lucky to be paired (eventually) with another host with the good app and validating. at least a few of them are making it through the gauntlet |
|
4)
(Message 9042)
Posted 18 days ago by Ian&Steve C. Post: Still happening, 8 days later. That's really poor form. resends can take months to fizzle out |
|
5)
Posted 18 days ago by Ian&Steve C. Post: there's nothing "wrong" with the either the apps or the tasks, they are just incompatible with each other. the tasks from this project have certain parameters defined in the tasks, the parameter for this current issue is the number of data points making up the light curve. this is important to the app because the app sets certain arrays to be appropriately sized assuming that none of the light curves have more than 2000 points. the app has a sanity check for this, because if there wasnt, then you'd run into a situation where you're trying to load too many data points into an array that's too small for them all. this would probably at worst cause a computation error, or at best result in incorrect results that wont validate anyway. in the past they didnt think that any light curves would have more than 2000 points, so it was set as kind of an arbitrary limit. but the project gets input data from a large number of sources, and more recently they have been getting data with more points in them. the main researcher was filtering out these large LC_points units due to the limitations of the current applications, and the developers have been working to update the applications. the updates are not as simple as removing the check, the app needs to be pretty heavily modified/rewritten to be independent of any specific points value. they could just increase the limits in the app, but that's just kicking the can down the road until they hit the next limit at some point. so they are trying to rewrite the app in a way that doesnt depend on the app and sets array sizes and memory allocations in a more dynamic way. this has been a slow process because there is more than just one app source to work with (different platforms) and the resulting performance of some of the platforms has shown pretty severe regressions. the dev is still researching and working on this. in addition to this, the developers are volunteers, not full-time employees.. it was a mistake by the researcher to send over units that have LC_POINTS>2000, but i believe most if not all of the affected tasks were from the previous ~2.5M batch released last week. and it will just take time for them to fizzle out in the boinc resend process. you will still get them from time since resends are pretty random with some needing to run to deadline before being resent. they error out very quickly so they waste almost no time from your host. i wouldnt worry about it. |
|
6)
(Message 9034)
Posted 24 days ago by Ian&Steve C. Post: i'm not sure if there's a way they can identify which tasks have the problem and which dont without pulling ALL the tasks. at least they fail quickly without wasting time. |
|
7)
(Message 8940)
Posted 10 Apr 2025 by Ian&Steve C. Post:
no, it's pointless for any BOINC project. it will not do anything. |
|
8)
(Message 8925)
Posted 7 Apr 2025 by Ian&Steve C. Post: PCIe bandwidth largely does not matter. you will get the same speed with PCIe 3.0 x4 as with PCIe 5.0 x16, it doesnt matter for the applications here. GPU specs like pixel fill rate and texture rate also do not matter and have nothing to do with how the app here operates. the app here cares more about memory bandwidth and clock speed. |
|
9)
(Message 8907)
Posted 3 Apr 2025 by Ian&Steve C. Post: According to the application list the project does NOT support AMD GPU's. what are you talking about? there is clearly an AMD application for both Windows and Linux system? did you look at your link? |
|
10)
(Message 8892)
Posted 26 Mar 2025 by Ian&Steve C. Post: keep trying |
|
11)
(Message 8883)
Posted 23 Mar 2025 by Ian&Steve C. Post: probably as long as interest/funding allows |
|
12)
(Message 8879)
Posted 23 Mar 2025 by Ian&Steve C. Post: there is no defined end date. new data comes in all the time. |
|
13)
Posted 21 Mar 2025 by Ian&Steve C. Post: the stock application does not do this. you have an infection that has compromised or even replaced the asteroids binary file with an imposter. I would reset the project to delete this file and download a new file from the project. I would also suggest a thorough virus scan of the system |
|
14)
(Message 8864)
Posted 19 Mar 2025 by Ian&Steve C. Post: that doesnt have anything to do with this project or your problems. just an example that bad people did bad things. not even a distributed computing situation at all. it was a case of misappropriation of military equipment and the people were arrested, and sounds like they were discovered very quickly. the code of this project is available on a public github for review if you really dont trust it. several BOINC projects have public code like this. |
|
15)
(Message 8852)
Posted 13 Mar 2025 by Ian&Steve C. Post: 1. very few BOINC admins post updates directly on BOINC message boards. that forum is mostly for BOINC specific issues, not project specific issues. almost all project issues posted there are done so by third party user reports. BOINC is only a platform to host projects and they have no real control or interaction of the projects directly. the projects merely use their software. look at WCG, they mostly post updates on Facebook and Twitter/X or whatever. if the website itself is unreachable, i probably wouldnt expect to be able to get any direct info unless through third parties/platforms just like other projects do. |
|
16)
(Message 8845)
Posted 7 Mar 2025 by Ian&Steve C. Post: that's a Milkyway@home task and has nothing to do with Asteroids@home. |
|
17)
(Message 8836)
Posted 28 Feb 2025 by Ian&Steve C. Post: Intel Arc Battlemage (B580) should work natively since it supports FP64 in hardware. It's the previous gen Arc Alchemist that does not (A750/A770/A380/etc) Do you know if the opencl app would need to be changed at all to support it? the Einstein BRP7 app for example uses the exact same binary for all the opencl implementations (Intel/AMD/Nvidia). if the same is true here, then all that would need to be done is uploading the app (renaming it too), and configuring the server to send to compatible devices. maybe they could probe the FP64 support from the host's coproc info.. I think even right now one couldnt even attempt it with Anonymous Platform because the server wont send anything to Intel GPU devices, even if you have a working app. |
|
18)
(Message 8834)
Posted 27 Feb 2025 by Ian&Steve C. Post: it's a small asteroid. it's not going to break anything. |
|
19)
(Message 8819)
Posted 22 Feb 2025 by Ian&Steve C. Post: As someone who works collision avoidance for NASA. The reality is that we can’t even predict satellite collisions in LEO with high confidence until like 12hrs before collision, and even then the event details can change a lot in the final hours. The amount of variables involved is crazy. So why give any thought to a potential solar system scale collision that’s YEARS away. The numbers and probabilities are quite literally meaningless at this point. |
|
20)
(Message 8814)
Posted 21 Feb 2025 by Ian&Steve C. Post: you keep asking this at different projects. do you understand what an NPU is and does? if you did, you would probably realize that they are not suited for just about any BOINC project. NPUs are used for low precision inferencing on AI tasks. it's kind of like asking if you can use your bitcoin miner for BOINC. they are both ASICs designed for one thing, and unless you're doing that one thing, they wont be able to be used. the only exception would be if these integrated NPUs had built in logic in their task scheduler to recognize matching calls and instructions that could be offloaded to the NPU. but in that case, it would all be internal to the device itself, and it would be totally transparent to the project and the users with no changes needed. but since the vast majority of the work here is the double data type (FP64), the NPU would have little or nothing to do. the only project that MIGHT have any hope to use an NPU could be LLMentor-Grid, and only if they are using or plan to use low precision (4 or 8 bit) in their computations. |
Next 20