Posts by Grenadier

21) Message boards : Number crunching : Orphan WU (Message 10584) Posted 4 Oct 2005 by Grenadier Post: For that matter, I got credit for the unit, indicating that others crunched it. So there will be no reason for a reissue, and that probably explains why it shows up as a dead link when I click the WU. Basically, the result is an orphan, not the WU.
22) Message boards : Number crunching : Orphan WU (Message 10583) Posted 4 Oct 2005 by Grenadier Post: <blockquote>I wouldn't worry. The WU has been issued to your machine, but if it isn't returned by the deadline then it'll be issued to another machine in time. It'll appear on your results pages, which is reasonable, since it has been issued to you. </blockquote> That's kind of the point though. It's been on there for months, with no re-issue, and now the link is a dead link. The result is tied to my machine, but the work unit doesn't even exist any more.
23) Message boards : Number crunching : Orphan WU (Message 10580) Posted 4 Oct 2005 by Grenadier Post: I've got this WU/result on a machine of mine that is no longer active. I'd like to delete the host. Can someone clear this WU? http://lhcathome.cern.ch/workunit.php?wuid=251916 It shows as "not found" but the result is still in my history.
24) Message boards : Number crunching : Can't get new work (Message 9777) Posted 31 Aug 2005 by Grenadier Post: <blockquote>NO - I will NOT play that game with cache size. It defeats the whole concept of a cache.</blockquote> Agreed, cache management could be better. But it is what it is at present. Saying that they are not the same thing is incorrect. They are the same thing, for now. Saying they shouldn't be the same thing, I can get behind. :-)
25) Message boards : Number crunching : Resigning due to short deadlines (Message 9776) Posted 31 Aug 2005 by Grenadier Post: <blockquote>Because the "Manager" is not managing to the user's set preferences.</blockquote> How so? Just because the method is being widely misunderstood and misinterpreted doesn't mean it's not doing it's job. <blockquote>If/when the WU deadlines improve to reasonable settings, I will resume crunching.</blockquote> Just because you find them unreasonable doesn't make it so. Since the work is still getting done, the deadlines must be reasonable to enough participants to make the project feasible. It only becomes unreasonable when the work isn't getting done. Not simply because one or more users says so.
26) Message boards : Number crunching : Can't get new work (Message 9767) Posted 31 Aug 2005 by Grenadier Post: <blockquote>Cache size is not the same as connection type or interval.</blockquote> At the moment though, it is the same. The cache size is the time between connections. Also, LTD numbers seem to get more accurate (and less inflated) with a lower cache. If you have a constant connection anyway, try a 0.5 day connect time (or even 0.25).
27) Message boards : Number crunching : Resigning due to short deadlines (Message 9766) Posted 31 Aug 2005 by Grenadier Post: Why not just let the BOINC Manager do what it was designed to do? If it goes to EDF mode, so what? The resulting LTD for LHC will mean that the other projects get their fair share of CPU time later, and it should all even out in the end. What's the obsession with micro-managing the manager?
28) Message boards : Number crunching : BOINC Version 4.72 (Message 9200) Posted 6 Aug 2005 by Grenadier Post: Keep in mind that 4.72 has had its own set of problems discussed on the various project forums, and is still a development version.
29) Message boards : Number crunching : only 10 k WU's left (Message 8745) Posted 20 Jul 2005 by Grenadier Post: 88799. Guess we're good for another week or so. :-)
30) Message boards : Number crunching : new work is here!!!! (Message 8346) Posted 7 Jul 2005 by Grenadier Post: Guess the userbase is big enough still, huh?
31) Message boards : Number crunching : Surely a pointless request (Message 8315) Posted 5 Jul 2005 by Grenadier Post: The minimum is one work unit. It doesn't really get 1 second of work. It gets at least that many seconds of work.
32) Message boards : Number crunching : New work soon (Message 8230) Posted 30 Jun 2005 by Grenadier Post: > Well, the news says 20K, the staatus line says 125,000 ... so, I am not > looking a gift horse in the mouth ... IIRC, they have different definitions at LHC for "jobs" and "work units." A job is multiple work units, I believe, explaining the larger number on the status line.
33) Message boards : Number crunching : new work is here!!!! (Message 8211) Posted 29 Jun 2005 by Grenadier Post: > Status page says: > Up, 35960 workunits to crunch Up to 49123 and climbing. Wonder how high it will go?
34) Message boards : Number crunching : no work from project (Message 7962) Posted 4 Jun 2005 by Grenadier Post: How long are you letting them sit? I've seen the progress bar sit on 100% for pretty much all of the projects, while it "finishes up". Basically, the calculation of a progress bar is not perfect, and they all usually sit on the end for a few minutes, since they are not truly done. By interrupting and restarting them, you may be restarting that last few minutes of work.
35) Message boards : Number crunching : no work from project (Message 7942) Posted 3 Jun 2005 by Grenadier Post: I think they are running short test jobs through, which explains the miniscule number of jobs that sporadically pop up. Either that, or they're cleaning up old jobs that didn't complete for whatever reason, so they can get the results off everyone's accounts and the server. I would think 30,000 1-million turn jobs would take at least an hour or so to get sucked up. :-)
36) Message boards : Number crunching : shorter deadline please! (Message 7933) Posted 3 Jun 2005 by Grenadier Post: Second the vote for using decimal portions of days. The Einstein folks were strongly suggesting 0.5 for quite a while, and probably still are. As long as you are not on dialup, having a really full queue becomes counter productive. It screws up the scheduler, and the chances of all projects being down simultaneously is pretty low. I was running 0.5 for quite a while, but just took some of my slower machines out of the farm, and got it back to 1.0. At 1.0, there are still plenty of WU's available, and I never enter deadline mode, since the smaller backlog insures that that situation does not arise. I'd suggest starting at 0.5, and nudging it up if you see yourself running low and avoiding deadline mode. Of course, if you're on dialup, this advice may go out the window. I'd still suggest a smaller queue, with more frequent connections, if that is an option for you.
37) Message boards : Number crunching : shorter deadline please! (Message 7922) Posted 2 Jun 2005 by Grenadier Post: > Please set the deadline to 7 day as PAH or EAH does.. This will make your problems worse. > If not the first LHC-WU will be crunched in 7 days with CC 4.43 and higher ; > because of the deadline-handling of the client the faster deadlineWU is > crunched first, or you have to suspend all other project. No, it will be crunched when your long-term debt on other projects is lower than the debt for LHC. If you're stuck in deadline mode, it's for a reason. You likely have too much work queued up for your system to handle, and/or a work unit that is going to miss it's deadline. Stop downloading so much work, and you'll have fewer problems. > Why the rules are not: > First: obey the resource shares > and second (!) : is there a deadline-conflict Those are the rules. But the resource shares are being obeyed long-term, not on an hourly basis. It's keeping track of what time each project used, and then playing catch-up later for the ones that didn't get their fair share. But this goes out the window in deadline mode. > Or how I can change the following restriction of the client:? > New CPU scheduler policy: earliest deadline first This happens when you have too much work in your queue, or when one WU is in danger of missing its deadline. Reduce your queue size to avoid this in the future. If you're running more than one project, change it to 1 day or less. (0.5 is often suggested, especially if running Einstein.) For now, just let it catch up and clear the queue of these late WU's. -Gren
38) Message boards : Number crunching : The Anticipation is Growing...... (Message 7892) Posted 31 May 2005 by Grenadier Post: Here's hoping they dodge the bug that Predictor tripped on with the newer clients. Whenever a PP@H unit pauses, it basically hangs. From the looks of things, they just rolled back to an older client in order to fix things, as it was at least partly the PP client that was at fault.
39) Message boards : Number crunching : please fix the deleter .... (Message 7835) Posted 26 May 2005 by Grenadier Post: Seems like there is still some more "tail" work to be done. For example: http://lhcathome.cern.ch/workunit.php?wuid=1646 I've got 4-5 others like this that have been around for months. I'm assuming they get stuck because of too many errors or something?

Previous 20

LHC@home