|
21)
Message boards :
Number crunching :
Can't Access Work Units
(Message 17609)
Posted 30 Jul 2007 by  FalconFly
Post: Hm, quite odd... As of now, I got 79 fresh WorkUnits in my Network. (as my Cache is only 0.25 days and many Systems still filled with MalariaControl, otherwise it would likely be more - but since I'm no "LCH WorkUnit Sniper" I rather keep things 'as is' and take them as they come) |
|
22)
Message boards :
Number crunching :
Can't Access Work Units
(Message 17601)
Posted 30 Jul 2007 by FalconFly
Post: I initially also got that, but now work is flowing, the Fix worked :) Good news is : Seems to be a batch of "long" WorkUnits, that should give you some time to successfully connect before supply runs out by the end of the day. |
|
23)
Message boards :
Number crunching :
Because you asked....
(Message 16832)
Posted 7 May 2007 by FalconFly
Post: For example, continuous, neurotic whining about the lack of WUs from lhc just begs the response I gave a few posts up. It's beyond passion, beyond hyper-passion, it's bloody sick and to not call it so does a disservice because they get the impression their behavior is normal and healthy. Although I'd rather tend to take it with humor, this isn't simple whining you're witnessing. People came here to support an Idea and since more than a year now, find the Project claiming be active, but in reality continue to find it dead as a doornail. Visible Progress is zero, updates (if any) come in at a pace that would disgrace any freeware SourceForge Developer. It's all about expectation, and if people are told to "hang in there", that's what they'll simply do (at least most of them). That's not "bloody sick", it's what you get from some of the most dedicated, best bunch of people any Distributed Project can wish for. Had they closed down and just said : We don't expect to have this baby up & running before mid-2007... ...folks would have accepted it (no other choice anyway) and checked in periodically and waited for the projected timeframe. What is wrong here is that this Project is hanging inbetween and going nowhere, for more than a year now. Noone made the decision to shut it off, yet noone made the decision to put an appropriate effort to affect the other either. That's basically what ticks people off, at least the few that remained here to date. Although someone recently called that "the best proof for a successful BOINC Project", I'd call it a "DC Community Test : how long can a BOINC Project last without any maintenance or progress made" I'm surprised it didn't permanently go offline at some point e.g. after a power outage by now, because Staff forgot it was still there. Personally, I don't come here to expect anything running anymore, it's just out of curiosity and time to spend to read through a few Forum threads a week. --------- As for personal "writing techniques", yes, Dragorath has a style of offensive and insulting writing. Instead of calmly presenting his Opinion (which often enough is absolutely valid and worth reading), he seems to "slam it onto your head with a crowbar" once a while... That's just the way it is, I may not like it but well... I've seen worse. Alot worse. |
|
24)
Message boards :
Number crunching :
Gone in a flash!
(Message 16798)
Posted 1 May 2007 by FalconFly
Post: In case someone comes across that misunderstanding in future, just show him this Image (a Picture says more than a thousand words they say) : 
|
|
25)
Message boards :
Number crunching :
Gone in a flash!
(Message 16794)
Posted 30 Apr 2007 by FalconFly
Post: *lol* Okidok, so tell me where the Setting for the Local Cache is then ? Because apparently, I've been running BOINC without knowing how to set it for more than 2 years ;) The answer : The setting is of course directly proportional to the Cache. However, it is smart enough to detect Situations where the selected amount of Cached work will result in Problems (such as missing the deadline for short-deadline Projects). This is a safety function with override Priorities inherent to the Cacheing feature, but nonetheless it remains exactly that : Set Cache to x Days worth of work. It's actually smart enough to correct for System downtimes, times where the System is up but not running BOINC and even CPU efficiency (where BOINC is running but only gets a fraction of the total CPU share). Set your Cache to 1 day and after filling up the Cache, disconnect Network cables and use the System in the same way you did in the last 2 weeks. Magically, it will run dry in exactly the time you had set as Cache. The effects of this calibration lead several folks to believe it was something else than Cacheing function, but it's plain not true. Double your Setting and witness it downloading & Caching exactly double the Work... unless it determines that this would hit one of the Criteria mentioned above and its limiting-feature cuts in. Exceptions were coded into BOINC for exceptional Projects, such as CPDN where the setting was rendered basically irrelevant and specific extensions had to be put in place to accomodate the extremely long runtimes. |
|
26)
Message boards :
Number crunching :
Gone in a flash!
(Message 16792)
Posted 30 Apr 2007 by FalconFly
Post: Indeed... It is a common misunderstanding that "Connect to Network every X days" was not the Cache setting. Apart from correction values applied to it (Up Fraction, Online Fraction, Running Fraction etc.) it is the basic - and only - local Cache setting to date. Other supplemental Cache Options are being introduced with the current 5.9.x Alpha test series. Why they erroneously named it so misleading (as the Client will make much more frequent contact when online, regardless of this alledged Network limitation setting) is beyond me. |
|
27)
Message boards :
Number crunching :
Lifesign?
(Message 16767)
Posted 29 Apr 2007 by FalconFly
Post: [irony / joke = on] 29.04.2007 23:00 UTC Yes it is going even slower than expected. It is still a unique installation of BOINC (very unique) and it's not moving ahead, therefor we give you our current To Do List: * Find database (the former LHC crew left a maze full of puzzles holding the exact location, in chunks of 2048bit blowfish encoded fragments, but we've recently solved it by splitting and issuing the decryption into SixTrack WorkUnits) * Initial Database Migration (actually that's in progress, bad news is that 44TB of Data has to be transferred via 56k, good news is that we're at 28%) * Aquire funding for a test system (as mentioned, we're attending fundraising conferences) * Get test system working with database * Ensure e-mail is working properly (trickier than it sounds, as we've deciced to code our very own EMail technology from scratch, we're currently testing it internally on a non-public Alpha level) * Test migrate again (good news : our Provider has informed us that we're optioned for a line upgrade, hopefully soon allowing a full 768k ADSL - with 44TB of Data to be moved back, our old 56k days should be history by then) * Real migration (this should be rather quick, as we plan to simply move the entire Array instead of transferring its content) * Sort out job submission over AFS by SixTrack User (to this date, this actually remains an oddball, as we - so far - haven't been able to identify what "AFS" stands for, nor where to look for the user "Sixtrack" which we couldn't find in the Userbase. Stay tuned for an update on that...) * Re-Enable work submission (at current progress speeds, we're looking at early 2015 as a realistic estimate, but given the advances we made attending conferences, we may be able to push this forward towards mid-2014) [irony / joke = off] I'm sure the Staff is working on something...somewhere :D PS. I noted a pretty cool Advertisement sporting the LHC in a Print magazine... Too bad it advertised a Network Solution company (I expected to see some BOINC Ad ;) ) |
|
28)
Message boards :
Number crunching :
Because you asked....
(Message 16722)
Posted 16 Apr 2007 by FalconFly
Post: If that's supposed to be failure for BOINC then that must be a definition of "failure" of which I was previously unaware... No, not at all. It's only that once it's complete, someone should express enough courtesy to step forward and say so ;) (otherwise, an ETA for the next event is what people use around the world) We're running around circles in this useless discussion. Let's just see what's left when it goes back online (whenever that is), everything else will work itself from there. |
|
29)
Message boards :
Number crunching :
What do we crunch for?
(Message 16721)
Posted 16 Apr 2007 by FalconFly
Post: LOL Very nice 
|
|
30)
Message boards :
Number crunching :
Because you asked....
(Message 16705)
Posted 14 Apr 2007 by FalconFly
Post: Yep, tried that and found it wasn't Network capable at that time. Anyway, the Problem is solved again and my 5.8.15, 5.8.16 and 5.9.3 Installations are in the process of recovering back to normal. |
|
31)
Message boards :
Number crunching :
Because you asked....
(Message 16700)
Posted 13 Apr 2007 by FalconFly
Post: @Keck Komputers Now that's odd (because I've heard several folks saying that over a longer timespan). Whatever BOINC Version I had installed at any given time, LHC's LTD was far exceeding 2 Million, crippling active Projects on V5.4x (seeing even 5 day cache sizes being reduced downto as little as 30 Minutes per Host), even on V5.9.3 I just had to begin suspending and resetting LHC to remove LTD's exceeding 1 Million and again crippling active Projects... Had I not manually intervened, I would have eventually seen the entire Network run dry, as active Projects reverted to "fetching no new work" as BOINC was literally starving to get work off LHC and satisfy its massive accumulated LTD. Not sure why, but - because I've heard exactly opposite statements like yours - apparently not all are affected by this (?) I'm basically left with no other choice short of detaching in order to keep my Network just running. All this regardless of keeping everything offline most of the time (feeding from refreshing caches once or twice a day) or keeping everything online 24/7. *scratches head* |
|
32)
Message boards :
Number crunching :
Because you asked....
(Message 16696)
Posted 12 Apr 2007 by FalconFly
Post: Agreed on the flow of work, but a constant flow (after seeing the last ~2 years) is not expected by anyone anymore. Having it deliver no work, however, is only "no sweat" for BOINC Installations attached to LHC only. Add other running Projects, and you'll find that their LTD is growing into the Minus, while the month-long idle LHC will amass Millions of Seconds LTD, sending all remaining active Clients deep into "Overworked" Status and even the latest BOINC Versions (expecting LHC to deliver anytime) eventually freaking out and going into "x Deadline misses" mode. So, no, it's no big deal if you know how to handle it, but it becomes when you let it run along and let it completely screw up the work scheduling over time. BOINC was designed for temporary outages / work shortages of several Projects at once. But not for a Project that technically exists but actually just sits there with no or insufficient amounts of work for a year. Looking at the minimal amount of work distributed over the last 12 month, BOINC LHC was actually not needed. A medium sized farm right in the Lab would have had more than enough time to complete it... all by itself. IMHO, Projects that just about never have work can hardly be called a success for BOINC. When it goes back into production (at whatever levels), we will see how many crunchers it still has... Good news is, at least we are still there ;) |
|
33)
Message boards :
Number crunching :
Because you asked....
(Message 16693)
Posted 11 Apr 2007 by FalconFly
Post: 8-) dont worry, the pace the work is progressing every one will some day or another detach themselves B-)Neasan will be left talking to himself ;-)then when the work finally arrives he will be the only one left crunching them ;-) LoL I've explained we are not on BOINC full time, not even close I want to second these statements. Technically, I'm only still attached to LHC by the record, but have everything suspended. While other Projects (even Beta ones) quickly kick into some action and get work going, LHC just sits there and silently accumulates Long Term Debt which doesn't help me any. Since it's been well over 3 months now (again, it's not like we've been waiting for almost a year), I would have wished for the Admins to at least temporarily shift priorities to the BOINC setup to get it started. IMHO, having it delayed until it's all shiny and runs 100% bug-free from day 1 (which it won't anyway ;) ) is nice but with no Userbase remaining...of little value. It'll be interesting to find out how many active Crunchers the Project will still have when it goes back alive... Some day in the future... |
|
34)
Message boards :
Number crunching :
Boinc farms.
(Message 16585)
Posted 20 Mar 2007 by FalconFly
Post: Did quite a number of upgrades since my original post from 17 Dec 2005 ;) 3x Athlon64 X2 4600+ EE 3x Athlon64 X2 4400+ 3x Athlon64 X2 4200+ 1x Athlon64 X2 4000+ EE 3x Athlon64 X2 3800+ 3x Athlon64 X2 3600+ EE 1x Dual AthlonMP 2800+ 1x Athlon64 3700+ 2x Athlon64 3200+ 3x Athlon64 3000+ 1x AthlonXP 3000+ Bad news is that Energy prices have increased every year, good news is that the total Power Consumption has fallen at (almost) the same rate, still trying to keep pace with the energy prices though :p Anyway, that's still 2542 Watts worth of raw computing power at my command :D |
|
35)
Message boards :
Number crunching :
Fairer distribuiton of work(Flame Fest 2007)
(Message 16407)
Posted 25 Feb 2007 by FalconFly
Post: I wouldn't make such a harsh statement looking at the numbers. While it certainly looks somewhat overstretched (35 Projects), it still leaves an average 2850 Credits per Project... Nothing big indeed but still good enough for an initial, basic Evaluation IMHO - therefor I do believe he's got a good Idea of what he's talking about, opinions may differ of course. Additionally, I kinda like the Spirit. Share what you have among many projects, be it a whole fleet or just a single Computer... |
|
36)
Message boards :
Number crunching :
LHC credits not showing up in cross-project stats
(Message 16299)
Posted 12 Feb 2007 by FalconFly
Post: *g* Arguably, though, looking at how long the move takes, it seems they either travelled and transported everything by foot, or they're getting their entire TeraByte Storage transferred to the UK via 56k. Otherwise, it should be a matter of days, not months... |
|
37)
Message boards :
Number crunching :
Welcome QMUL Admins
(Message 16132)
Posted 14 Jan 2007 by FalconFly
Post: For as long as the content is still identifyable (without going into decrypting), that's still fine with me. Plain reason being, is that I've seen worse than that... alot worse. People writing that way just should be aware however, that in writing to the public, a writer is always also presenting him/herself to the public with all consequences. The perception of that writer and the reactions will be accordingly. In extreme cases 'too lax' writers are easily put off as immature or plain incablable (unless they explain why they write the way they do). Personally - all typos aside - that's not how I would like to present myself to the public, but your mileage may vary on that ;) Bottom line : I (and others) have seen folks capable of many languages... HTML, Java, Perl, C++, Assembler, Fortran... But amazingly, at the same time unable to write their native language. And that's bad. |
|
38)
Message boards :
Number crunching :
SOME greedy users
(Message 16073)
Posted 7 Jan 2007 by FalconFly
Post: Falcon you totally miss the point. I know and fully understand that point. Still - regardless of Cache size - getting WorkUnits or not remains on one common basis : pure luck Therefor, the chance of a "short-cache" machine to get work is almost the same as for a "hughe-cache" machine. If the work is passed out while the affected System is deferring communication for x hours/days, cache doesn't matter. The only difference is : the short-cacher missed like 7000s of work, the long-cacher missed 70000s of work... but both miss. The few lucky ones (as you can read all over the Forum) are a big mix of all cache-sizes (most actually being rather small due to personal preferences). Additionally, I would ask you to consider one further, related point : Do you (or anyone) think it is reasonable to ask Users, many of which are likely active in several other projects, to reduce their Cache-size just because of a few unhappy users of a single Project ? After all, reducing a selected cache size may have implications unknown to you or me, as people have very personal requirements. Even if the few long-cachers would change, looking at the numbers, it appears that the largest portion of Work is returned rather quick. Only a limited fraction is dragged closer to its deadline limit, indicating the majority is already using rather small caches and returning work significantly before the deadline. And overall, it seems clear that even with every single User choosing minimum Cache size, the Project - given the amount of work available per batch - is far too overpowered. It would still leave Users without Workunits - there are simply too many active Hosts available (72359 as of now, 40% active would still be like 30000 - too many hungry machines for e.g. 60k Workunits to last for everyone). Bottom line : While it looks very attractive and conclusive at first sight, the impact of Users with large Cache Size isn't as large as it seems, its reduction could not solve the problem (just improve it a little bit). The only spot where I fully accept and support your point is for Users that fill up machines that eventually cannot complete the work within the deadline (either due to performance or insufficient uptime). ------------- IMHO the whole situation will only change to the better for everyone until the proposed changes are made and more work is avaiable for the hungry masses. |
|
39)
Message boards :
Number crunching :
SOME greedy users
(Message 16012)
Posted 3 Jan 2007 by FalconFly
Post: Regardless of whatever limit is posed on WorkUnit distribution, here's an advice : If you start looking like this watching or awaiting WorkUnits on your PC  ...then it's time to relax, close your BOINC Manager and chill out... Seriously. If you're lucky to catch work while it's there... great. If not... better luck next time. All the complaining is like buying a Jeep and then demanding it must go 150mph. It just doesn't work, because it isn't designed to do that. LHC is exactly the same... As of now it isn't designed to have an endless stream of WorkUnits pouring out, that's the type of Project you joined. And for as long as this [design] is not changed, all the demands and complaints are absolutely futile (Don Quichotte comes to mind). As the staff is preparing to change the design and have a rather continuous work supply, it becomes even less and less likely that they accomodate the unlucky folks that did not manage to snatch some WorkUnits with the upcoming changes. At this point, I would even go as far as to suspect they would 'recycle' previously done batches of Work just to keep the troops happy. (this unfortunate principle has been proven to work, e.g. SETI) |
|
40)
Message boards :
Number crunching :
30 hours of work availability - did u get some?
(Message 15767)
Posted 4 Dec 2006 by FalconFly
Post: Glad it worked for some :) Unfortunately my 3 Systems left active on LHC didn't check at the right time and didn't see any work, but that's back to "business as usual" ;) |
Previous 20 · Next 20
©2024 CERN