 |
|
|
1)
Message boards :
Number crunching :
Trojan boinc installation by rogue member
(Message 26957)
Posted 20 Feb 2007 by  old_user85254
Post: Thanks for this treatment of this phisher. I have copied it across to LHC and LC. Although (s)he was not active on those projects, in my view as many people as possible should know. I\'d encourage anyone who regulalry posts on other projects not mentioned already to spread the word there. R~~ |
|
2)
Message boards :
Number crunching :
Trojan boinc installation by rogue member
(Message 26956)
Posted 20 Feb 2007 by old_user85254
Post: ... some compromised computers are still running and crashing climate models. Boinc and project staff have no means of contacting the owners of these computers. ... As I understand it, cpdn can abort a job at a trickle-up. On its own this would not be much use, as the client would simply download another client. I wonder how easy it would be to have a \'badlist\' of banned users so that the scheduler would simply refuse to issue more work to them. This might prove useful in other situations as well. Just a thought. If anyone feels it is worth passing on, please repost on the BOINC forums. I also like the earlier suggestion to produce a specialised app that puts out a message to the users, though this could backfire on the lines of shooting the messenger. It might actually be less helpful but less damaging to the project just to make the machines disengage by refusing them work. River~~ |
|
3)
Message boards :
Number crunching :
No Credit for 5 Days
(Message 24810)
Posted 20 Oct 2006 by old_user85254
Post: thanks PB27, yes it answers my q & thanks Annika too |
|
4)
Message boards :
Number crunching :
No Credit for 5 Days
(Message 24803)
Posted 20 Oct 2006 by old_user85254
Post: Hi, a trickle happens each 25920 timesteps (i.e., once per model year, at 1st-4th December). Getting slightly off topic here, but is a timestep about as long (in cpu time I mean) on Sulphur and on the current model? In which case we\'d expect trickles to be around 2.5x as far apart. I\'m asking for a ballpark figure here please. R~~ |
|
5)
Message boards :
Number crunching :
Run Length - a suggestion
(Message 24802)
Posted 20 Oct 2006 by old_user85254
Post: Thanks for your comments, but I\'m afraid you greatly underestimate the work involved in doing what you described. There\'s nothing regarding climate models that can be done in \"a dozen lines of code!\" :-) I don\'t think I have made myself clear then. What I am suggesting would be a small number of lines of code would be to add something like the following immediately after the 40yr upload point: cpu_per_model_year = cpu_so_far / model_years_done ; cpu_for_next_chunk = 40 * cpu_per_model_year ; cpu_after_next_chunk = cpu_so_far + cpu_for_next_chunk ; if ( cpu_after_next_chunk > user_cpu_limit ) then quit where \"quit\" is a break jump return signal or setting of an appropriate status code as appropriate in order to make the program exit early instead of going back into the next 40 years. This encodes the user action MikeMars was suggedting, but allows it to happen safely and at exactly the right moment. No losing 39 model-years due to getting the timing wrong & no aborting after the work is done but before the upload is complete. The above was what I was saying would be a small amount of code. Deciding exactly where to place that code & testing it may well be harder. I was not intending to suggest this was the whole job. In addition of course there would be a need to add a cpu_target to the cpdn preferences, and a column in the db for it. I am under the impression that the code to pick it up already exists in the BOINC code, if not the code to pick up the project specific pref certainly exists at Rosetta. What is obviously a huge amount of work is the programming to then be able to pick up those part-complete runs and complete them on other hosts. But my impression from other threads is that you intend to do that anyway. So to make changes that allow user flexibility might be only a dozen lines of new code more than you plan to write anyway. R~~ |
|
6)
Message boards :
Number crunching :
Run Length - a suggestion
(Message 24776)
Posted 18 Oct 2006 by old_user85254
Post: Sorry, bad wording I guess. Fair enough, Les. Combined with me being a little over-touchy too, I guess. R~~ |
|
7)
Message boards :
Number crunching :
CPDN speeds on Win & Lin ?
(Message 24757)
Posted 17 Oct 2006 by old_user85254
Post: Trying it on a few PCs that are dual boot, I\'ve found Win to be about 2-5% faster than Lin. Thanks for a quick reply geophi. Looks like it is Win2k then. R~~ |
|
8)
Message boards :
Number crunching :
Run Length - a suggestion
(Message 24756)
Posted 17 Oct 2006 by old_user85254
Post: The models now running are of a different nature to the old slab and sulphur. Quite so. In due course it will be possible to restart these models from the 40-year uploads, a server based checkpoint. What I am suggesting is the other half of that option: to allow a user to cleanly exit at one of those checkpoints. It is a very small modification, a few lines of code added immediately after the server checkpoints to test whether the model should go back into the next 40 year block. I am also suggesting that it could make sense to release the \"early retirement\" option even before the code for the part runs is ready. The advantages of this over simply suggesting people can abort are - it feels like the project is allowing the variable lengths, which as I say is very good for participant morale - less chance of silly errors (like aborting in year 39 or year 70) - the software makes a clean exit at the most appropriate place - less chance of aborting at the wrong place because a participant does not understand different models (eg aborting a sulphur at 41yrs is not the way to go) - future models may have natural break points at different places, and the method I\'m suggesting means that those break points will work seamlessly with the current ones, and will break at whichever of their own break points most closely mathes participants wishes - no wasted processing time as there is with the wait for year 41 and abort method
I don\'t think it is useful to describe feedback as \"wingeing\". Nor to refer to people wingeing in response to a post that does not have a complaint of any kind in it, just a suggestion about how to do something that your users have been asking for. Maybe some of those other threads can be described in those terms, but not every suggestion is a moan in disguise. I hope mine wasn\'t taken as such. Yes it is great that nearly 2k runs have completed, and it is great that the majority of CPDN crunchers are happy to run the full 160 years. Congratulations to them for their dedication. But if you can keep another 10% of crunch power by writing a dozen extra lines of code, if you can turn the departing disaffected into grateful ambassadors for CPDN, surely that is worth it. I\'d like to see this project do even better than it already is, and am passing on an idea that worked well in another project. I hope the project programmers will consider the idea on its own merits. R~~ |
|
9)
Message boards :
Number crunching :
Run Length - a suggestion
(Message 24745)
Posted 16 Oct 2006 by old_user85254
Post: Some time back, MikeMarsUK said in a message in another thread Running the existing 160-year model is effectively just the same as running four sequential 40-year models - at 1960, 2000, and 2040 the model uploads a \'restart dump\' to the server, so you can abort the model after the upload if you need to. My suggestion is that the project consider implementing a \'run length\' option in the project specific prefs, based not on model years, but on run time on the users box. Rosetta have done this, and you can choose settings from 1hr to 1day runtime. When the app gets to a point where it makes scientific sense to stop, it checks the runtime so far, checks how many chunks it has done so far, and works out if it has time for one more within the user preferred run time. This works well on Rosetta, and a nice side effect is that you can change the run length or a task while it is running. Say it has got to 5hrs and you cut the length to 2hrs, remember to Update the project on the client, then next time the app gets to a suitable break point it will finish gracefully. There are clear warnings to participants - the software always runs one chunk so on a slower box the 1hr option very often overruns. Also, because it only ever stops at the end of a chunk, sometimes the run length falls quite a bit short of the user request. Sometimes it goes over (where for some reason the last chunk ran for longer than the average chunks before it). How the equivalent would work on this project is that you\'d offer a range of options 1month, 2mo, 3mo, 4mo, 6mo, 9mo, 12mo, 15mo, 20mo, 24mo, 30mo say. The user would select one of these. In the usual BOINC way, the user could have different settings for \"home\" and \"work\", etc. The app would be modified slightly. At each 40year boundary it would do the test to see if it had time to run another 40years of model time. If not it would terminate. The advantage of this scheme is that it is user friendly - the user sets what they want to happen. The settings automatically apply to the next kind of work you issue and you do not even have to work out how many chunks correspond to the user request because it is all done post hoc in the app. That is why it would make sense to have the range of run times extending beyond the current deadlines. Also the project has the capability of doing an SQL query on the database to find out what run lengths are popular and which are unpopular. This might be useful when deciding what length work units to produce next. On Rosetta, they have a thread of \"top ten reasons I crunch Rosetta\". The ability to choose run length comes in many people\'s top ten reasons. It is likely (in my opinion) to be even more popular here. River~~ |
|
10)
Message boards :
Number crunching :
CPDN speeds on Win & Lin ?
(Message 24744)
Posted 16 Oct 2006 by old_user85254
Post: How does the latest CPDN model compare speedwise on Windows and Linux, the hardware being the same? I\'ve got a dual boot box (Win 2k, Linux) and am wondering which would be best for this project? regards, River~~ PS: this is not an invitation for comparisons of the merits of the two systems on any other grounds than how fast they run CPDN. If that is what you hoped for, please start your own thread ;-) |
|
11)
Message boards :
climateprediction.net Science :
BBC Application
(Message 21104)
Posted 6 Mar 2006 by old_user85254
Post: thanks everyone for the replies re run length of the BBC WU. Sadly this puts the BBC expt right out of my reach, but I\'d like to thank all you folks with modern machines for doing this work, the planet needs you! River~~ |
|
12)
Message boards :
climateprediction.net Science :
BBC Application
(Message 20677)
Posted 23 Feb 2006 by old_user85254
Post: 1. Anyone know about the expected run time of the BBC app? Is it likely to be about as long as a slab, about as long as a sulphur, or somewhere between? This matters to me as I cannot conveniently run the sulphurs on many of my boxes and would prefer a shorter app. 2. Does the BBC app show up as a separate project in stats (eg BOINC stats) or as part of the CPDN stats? |
|
13)
Questions and Answers :
Unix/Linux :
Slab progress overstated
(Message 19894)
Posted 2 Feb 2006 by old_user85254
Post: Slab (hadsm3) in Linux had problems with estimates of completion under certain BOINC versions. Pre 4.4x, I think it did a good job of figuring out how far along one was in the whole model run. With 4.4x (and above?), it would give you the progress through a phase, so in your case you are 84% of the way through phase 2. This can also give silly estimated times to completion. Good call: The percentage figures exactly match progress within the phase. Historically this also makes sense as in the Classic UI the progress was reported separately for each phase - no doubt that got overlooked in the conversion to BOINC; and equally beyond doubt is that there is no point correcting this bug for these WU any more... The app is hadsm3 v 4.13, the client is 5.2.7 for Linux With the bug you describe it makes sense that the error goes with the app (slab) version rather than the client version, as percent complete is reported by the app to the client. Further conversions to estimated time to complete will be different in different client versions, but will all be wrong of course - garbage in, garbage out... Thanks for your reply, as with many bugs it all makes perfect sense once you know what is happening... River~~ |
|
14)
Questions and Answers :
Unix/Linux :
Slab progress overstated
(Message 19863)
Posted 1 Feb 2006 by old_user85254
Post: I am still running a slab model, trickles here. It is just coming up to the end of phase 2, so must be at less than 67% progress surely? But the progress indicator says 84% progress, and the command line --get_state indicates a similar fraction 0.84 completed. This is not really a big problem, as I usually esitmate progress from the trickles anyway - however I am curious if anyone else has seen this, and if anyone knows if it means anything? My windows slabs seem to give plausible progress figures, it is just this Linux one that seems to get its sums wrong River~~ |
|
15)
Questions and Answers :
Windows :
BOINC trying to download a second (and third) WU while still processing first...
(Message 19861)
Posted 1 Feb 2006 by old_user85254
Post: I have a similar issue, but notice that it only happened after I suspended the first. I saw a recommendation in another positing to suspend the current wu before switching the maching off (to avoid losing work), but when I restarted, BOINC clearly decided it needed more work to do and didn\'t wait for me to resume my first wu. I notice in your posting that you suspended both the first two wus, and so (my interpretation) BOINC found all work suspended and decided to go and find some more. It is important to understand that there is a difference between suspending a result and suspending a project. If you suspend a result, then the client is still free to run other work from the same project, including downloading new work from the same project. If you suspend a project, then no more work will be downloaded for that project. The difference is whether you click suspend on the work tab (suspends the highlighted result) or on the projects tab (suspends the highlighted project). If you have mnore than one project active, then suspneding one project can trigger new work to be downloaded for one of the other projects. In this case, disable networking first. Hope that helps |
|
16)
Message boards :
climateprediction.net Science :
Question
(Message 18855)
Posted 29 Dec 2005 by old_user85254
Post: This is a subject that has been, and still is being discussed in the community forum, <a href=\"http://www.climateprediction.net/board/viewforum.php?f=16&sid=e2126a35805e763ef7a1c66b47e80c15\"> here.</a> It is a great forum for anyone that needs and wants to know about global warming. Crunching for CPDN is about helping the scientists convince those who need to know but *don\'t* want to. Both aspects are important |
|
17)
Message boards :
Number crunching :
Credit given for workunit in progress?
(Message 18835)
Posted 29 Dec 2005 by old_user85254
Post: Well I have no problems with just getting the credit at the end... I would. Suppose the WU dies. Classic was good at returning info from a broken WU and kept a separate count of \'short\' wu. But suppose for some reason the wu cannot be returned. On the one hand the science has no data, you can say then that no credit at all is fair. On the other hand the user has made the effort, you can say full credit is fair. But in between those two extremes is something that is even fairer than either - a compromise that relfects both ways of thinking. Interim credit for interim check-ins, which you don\'t lose even if the model fails - and a bonus for finishing as that is what is useful for the science (if I remember right this is paid as a larger than normal credit for the last trickle). And that is what CPDN came up with. In my opinion it is a brilliant extension to the BOINC framework. Even if the projects Paul mentioned do not use it, someone ele someday will need it. River~~ |
|
18)
Message boards :
climateprediction.net Science :
transfers keep retrying
(Message 18834)
Posted 29 Dec 2005 by old_user85254
Post:
hi Ted. The CPDN server does not have you listed as having any credit as yet (see the stats next to the name on your post). Did you sign up for the forum under a different a/c to your crunching? Has your model made any successful \'trickles\' yet? Where did you get the credit figure from? In general you get credit soon after each trickle, tho this can take a few days if one of the servers goes down at a weekend for example. Once you get credit, so does the team you are attached to at the time. If you join a team, they don\'t get your old credit, just what you trickle while you are there. If you change teams you can\'t take your credit back either. Finally, it can take up to another 25hours for credit info to reach third party stats sites, like the excellent BOINCstats - so the sig panel below might be a day out of date already... River~~ |
|
19)
Message boards :
climateprediction.net Science :
Question
(Message 18807)
Posted 28 Dec 2005 by old_user85254
Post: The more work we do, the more data the scientists have to base their research on and the sooner (potentially) they can publish their results, making it more difficult for the public and politicians to ignore climate change that is already happening and is predicted to probably happen in the future. Spot on. Only it is not so much the public that are ignoring climate change, at least in my country, but the politicians and the oil / car / plane lobbies who are pushing them to keep their heads in the sand. River~~ |
|
20)
Message boards :
climateprediction.net Science :
How many WATTS does CPN cost??
(Message 18806)
Posted 28 Dec 2005 by old_user85254
Post: Must be a lot of people from the UK here... That figures, Ray, This is the only BOINC project where the science team is based in the UK ...only one so far at least... Not a large part of my decision making, but it counts for something; and the initial word-of-mouth when CPDN classic started was through two UK Universities and letters to a couple of British newspapers. Personally I came to BOINC from CPDN classic and only later saw the advantage of the inter-project and inter-national cooperation. But work out how many Watts it takes to heat your house. Divide by 50 (for PIII era machines) to 150 (for HT boxes), buy that many boxes and you too can have a fan heater that calculates how to save the planet while it heats your house Lowere temperatures in winter are great - you can buy more computers for the Watts you need. ;-) R~~ |
©2024 climateprediction.net