Posts by elbea64
|
21)
Message boards :
Number crunching :
Not requesting tasks
(Message 895884)
Posted 17 May 2009 by  elbea64
Post: But aren't they based on each other or at least debts are based on the DCF/runtimes especially the work fetch priority as it's needed to know how much work is done in a given time to determine if there's need for more work. That would make sense in my case too, as it looks like Milkyway had a such high priority that Seti hasn't any priority to get work. i don't know if i made clear what i want to say - i see a calculation chain: FLOPS -> DCF -> Estimated times -> STD/LTD OK and there i see my error STD/LTD depends on runtimes but not vice versa I hope i'm right on a cursory view |
|
22)
Message boards :
Number crunching :
Not requesting tasks
(Message 895867)
Posted 17 May 2009 by elbea64
Post: I did that some minutes ago and couldn't use the info but there was a lot of info about debts and so i remembered that it's possible to reset them and so i did even when the estimated times looked good. And see ... Seti is requesting work again. Thanks for your efforts :) |
|
23)
Message boards :
Number crunching :
Not requesting tasks
(Message 895865)
Posted 17 May 2009 by elbea64
Post: The exit code -202 i7 was my error when i tried to run two instances of BOINC because of major scheduling problems between Seti and Milkyway, this PC is now running better than before. The other one doesn't request work. Theres Milkyway attached too, but as Milkyway doesn't provide work all the time there are sometimes tasks and sometimes not but Seti doesn't request work either. I resetted all settings i'm aware of. It's set to request work and i believe it has no local settings at all. I changed the venue to be shure that isn't the problem. I think i missed something. If switched to version 6.6.28 again - i had some problems with it when it was a dev-version. But the problem persists, still not requesting work |
|
24)
Message boards :
Number crunching :
Not requesting tasks
(Message 895837)
Posted 17 May 2009 by elbea64
Post: I have a core i7 that suddenly doesn't request new tasks. I have only 3 spare tasks left so i'm in a little hurry :) I've a clean cc_config, i've reset local overrides and no additional idea what i can do |
|
25)
Message boards :
Number crunching :
Am I the only one???
(Message 895831)
Posted 17 May 2009 by elbea64
Post: I think you can use the sse2 version of the ak v8 if it is for your P4s use cpu-z to determine your cpus capabilities |
|
26)
Message boards :
Number crunching :
Multithreaded AP app?
(Message 894896)
Posted 15 May 2009 by elbea64
Post: BOINC can't schedule single threaded apps very well. If i think of apps that use different amounts of cpu on different cores or worse on different hardware (cpu<->gpu), i believe scheduling will completely break. My wish would be to separate things even more!
everything on a per "calculation unit" basis (cpu/core/gpu/...) |
|
27)
Message boards :
Number crunching :
Question re Systray Icon
(Message 893906)
Posted 12 May 2009 by elbea64
Post: I understood that he set the client to another port but couldn't use BOINC Manager to monitor/control it i used the select computer to connect to localhost a lot because BOINC Manager doesn't recognize non-standard-ports of the client. I used different ports because i connected over NAT to different hosts but wasn't using any tunneling, just port forwarding |
|
28)
Message boards :
Number crunching :
Question re Systray Icon
(Message 893897)
Posted 12 May 2009 by elbea64
Post: Under Advanced -> Select Computer -> Host Name you can use the format <host>:<port> to connect to another port. I sadly didn't find a way to set a default port. |
|
29)
Message boards :
Number crunching :
Different caches of work at 2 projects
(Message 893611)
Posted 11 May 2009 by elbea64
Post: The queue size makes no sense per project. The basic setting telling how frequently the user will allow BOINC to connect to the projects to fetch and report work is clearly a machine setting. This drives part of the queue size, and was the original basis of the queue. If a computer will only be attached to the internet once a week (as some dialup situations require), then attaching to a project with 3 day deadlines is clearly a mistake.Your point makes only sense if you only take not regulary network conections into account, i think this is the least used reason for having a cache, the most used reason is in my eyes project outages which are namely project dependant. All work is fed to the CPU or CUDA from one queue per resourceThat is the next design error CPU and GPU are completely different systems it would make much more sense to treat them as different hosts with completeley separate settings even though they're in the same case. It would make scheduling so much easier and the way it is actually (not) working shows clearly the problems with scheduling different systems, they will never fit together and when there will come more different hardware - next is ATI - things will become worse. And think about HT of core i7, it will be best if you run very different projects on hardware core and virtual core. and the resource scheduler makes decisions of what to process next based on what is in the queue, the estimate of wall time remaining to process, and the time to computation deadline. Note that computation deadline is always earlier than the report deadline, and based on the client settings.And exactly those estimates will be far easier if the scheduler has only one system with the same runtimes. To schedule two or more systems with that big differences in runtimes is very hard when not impossible, especially when there are no adequate client settings available. So actually it's a fight to get the system running the projects i like on the hardware i like against BOINCs system of mixing and messing it all up. Different hardware needs different settings! I like the idea of BOINC, but to contribute my ressources does not mean that i will ever give away every control of how it's used, they're still my systems and so it's my decision. I agree that there has to be a system that simply works for beginners and those who aren't interested very much but that must not be a constraint it has to be a option that can be disabled for those who want to have more control over their ressources. The best is, that a system of separated ressources will leave enough room for combined managing even over different hosts, grouping by processor and/or gpu will be easily possible and each group can have their own settings, so for example i can switch the virtual cores of my i7s to a more efficient project at once. |
|
30)
Message boards :
Number crunching :
Different caches of work at 2 projects
(Message 893534)
Posted 10 May 2009 by elbea64
Post: I don't think it's a feature, i think it's a design error as different projects or just different apps of the same project have different requirements they need different cache settings. I think of Milkyway, that has a deadline of 3 days where i can't see the sense of a possible 10 day cache setting. I can even think of projects where it would make sense to cache parts not time |
|
31)
Message boards :
Number crunching :
Validation inconclusive
(Message 891958)
Posted 6 May 2009 by elbea64
Post: That result wasn't looking very interesting so didn't look deeper into it. Now i have PMed him about the problem with his PC. It's not clear to me if it is a question of stock or opt app. perhaps it's a general problem. The second result indicate a little that it's not a problem of a specific app although it's different to the other inconclusives |
|
32)
Message boards :
Number crunching :
Validation inconclusive
(Message 891940)
Posted 6 May 2009 by elbea64
Post: I have one of my inconclusives validated too. It was a stock app against opt app inconclusive and validated against another opt app. And another one that looks more interesting. These are two opt apps and one rendered to invalid while mine is inconclusive. I think the other was inconclusive too for a while so it could validate inconclusive together with mine |
|
33)
Message boards :
Number crunching :
Validation inconclusive
(Message 891867)
Posted 6 May 2009 by elbea64
Post: You didn't say "representative", but you certainly gave the implication in your last post to me that you spotted a trend among stock apps; a trend from a select group of results proffered in this thread, which suggests you are taking this select group as a representative sample as you've begun building hypothesis for possible explanations. You are, of course, allowed to find this all "interesting", but I'm just trying to keep people focussed on the bigger picture so that they don't get lost in the many, many details.The trends i see are always based on the available data which must not be representative. To investigate trends the available data has to be interesting at least for me. I see it like ccappel, i don't want to be the one who produces problems which is very subjective and influences the trend i (may want to) see. But this is all ok for me at this point namely because of the non-representative data. As available data will grow or better explanations of this are available i will refine my vague point of view, add aditional possibilities or drop others that went impossible. At the moment i would tend to Josef W. Segur's explanation with the addition of a small "please not me" ;) Just to be clear, I did not state that heat issues were the definitive cause of the problem. I only threw that suggestion out there as another possibility.I understood exact this and i see this clearly as a pssibility! I think it's not the strongest yet but far away from being dropped. Talk about interesting findings - interesting that people run away with a claim without examining its context or intent.I don't understand what and/or who you mean? I think i've looked into it with a adequate focus. The only thing I am trying to get across, but seem to be viewed as being argumentative insteadYes, i felt that way. I said it's interesting - you said there's nothing interesting with a argument i can't agree fully but that sounded like the argument. I tried to explain my point - you made it ridiculous. And now i understand the last quote: a software error isn't my personal favourite but i can think of situations where it shows up that late, perhaps because of some odd WUs going around someone mentioned somewhere i can't find anymore. If i saw you argumentative by mistake i'm sorry. There's shouldn't be anything too interesting about that, considering its the CPU that records the results and returns them. An overheating or malfunctioning CPU can produce bad results even if using the same stock app as someone else.I think i now understand what you wanted to say but earlier i read this as the ultimate argument that there's nothing about it. Nothing offending here, i'm just curious if you can follow my thoughts or did i miss something. |
|
34)
Message boards :
Number crunching :
app_info.xml for CUDA and astropulse
(Message 891577)
Posted 5 May 2009 by elbea64
Post: @Martin P I'm sure someone had helped you if you asked for more assistance! No one wants to reinvent the wheel if a simple link would do the trick. Did you get it to work? @KWSN Sir Clark Some more information is needed - OS, CPU, GPU, BOINC ... |
|
35)
Message boards :
Number crunching :
BOINC main page dead?
(Message 891557)
Posted 5 May 2009 by elbea64
Post: It's working for me including forum |
|
36)
Message boards :
Number crunching :
Validation inconclusive
(Message 891511)
Posted 5 May 2009 by elbea64
Post: I didn't say it is representative i said it's interesting. My explanation why it is interesting is very weak regarding interpretation of having a reason why this happens, but it's a strong reason to find it interesting for me. What i've said is not even a theory, it's a possibility that has the same weight as the possibility of overheated cpus. There's a argument that speaks against overheatet systems. Such systems will more likely produce errors than valid results that don't validate against others. But that's simply one of many arguments and doesn't mean that it won't be overheatet systems i don't know, but want to know - that's what i call interesting |
|
37)
Message boards :
Number crunching :
When should Seti jetison the weak?
(Message 891311)
Posted 4 May 2009 by elbea64
Post: storage is not a problem neither financial nor technical bandwidth is expensive if it is technical realizable at all |
|
38)
Message boards :
Number crunching :
Seti on CPU and MilkyWay on GPU
(Message 891303)
Posted 4 May 2009 by elbea64
Post: Cache could be the "problem", i'll try that when my seti work will be 2 days or less. At the moment i've seen another behavior that helps staying busy at MW as it seems that boinc is always requesting work when it's "crazy". When it's normal it only asks when the current work is done |
|
39)
Message boards :
Number crunching :
Validation inconclusive
(Message 891289)
Posted 4 May 2009 by elbea64
Post: Yet there are only inconclusives with stock app involved and now there's one with two stock apps which makes it's rather likely that it's the stock app producing inconclusives and i find that is interesting. If you think of, that most people that will see inconclusives are those more interested and therefore very likely run opt apps makes it even more interesting. It's very likely that a lot of stock app users never will see a inconclusive because of less interest than opt app users so it's likely that there are a lot of inconclusives between stock apps that will never show up here. so statistics is very interesting here And besides of temporary malfunctioning hardware, there could be programming errors, errors in specific hard-/software combinations or hardware design errors that come out with inconclusive validations and for them it's very interesting if it is the stock app or one of the opt apps |
|
40)
Message boards :
Number crunching :
Task pages unavailable
(Message 891244)
Posted 4 May 2009 by elbea64
Post: For me too last update i've seen is 3. May about 14:00 UTC for different hosts |
Previous 20 · Next 20
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.