Message boards :
Number crunching :
4 hours ago - Waiting for validation - was - 97,759 - now - [27 Jan - 22:06:UTC ] -17,369 -- Good news ?
Message board moderation
Author | Message |
---|---|
Byron Leigh Hatch @ team Carl Sagan Send message Joined: 5 Jul 99 Posts: 4548 Credit: 35,667,570 RAC: 4 |
:) some thing happing -- of course it can and probable will go back up ? :( approx 4 hours ago - Waiting for validation -- was --- 97,759 -- now -- 17,369 -- I know it was , 97,759 ---- Waiting for validation -- because 4 hours ago I wrote it down also: transitioner3 kryten now Running transitioner4 kryten now Running Waiting to transition 0 Good news ? |
Astro Send message Joined: 16 Apr 02 Posts: 8026 Credit: 600,015 RAC: 0 |
I'm just happy to crunch. I don't need any validation for my efforts. (this is what people like me say, because we have slow computers, and no chance in heck of getting into a credit race with anyone) LOL Thanks for the news Byron |
Byron Leigh Hatch @ team Carl Sagan Send message Joined: 5 Jul 99 Posts: 4548 Credit: 35,667,570 RAC: 4 |
:) Hi mmciastro , thanks for your post , I agree with you :) :) |
Toby Send message Joined: 26 Oct 00 Posts: 1005 Credit: 6,366,949 RAC: 0 |
And... back up to 37,000 :) I am curious as to the nature of the phantom disk I/O being generated by mySQL. Hope they update the technical news when they figure out what it was. A member of The Knights Who Say NI! For rankings, history graphs and more, check out: My BOINC stats site |
Byron Leigh Hatch @ team Carl Sagan Send message Joined: 5 Jul 99 Posts: 4548 Credit: 35,667,570 RAC: 4 |
:) Hi Toby thank you for your post :) Toby wrote: ========================== > And... back up to 37,000 :) > > I am curious as to the nature of the phantom disk I/O being generated by > mySQL. Hope they update the technical news when they figure out what it was. =========================== - yep -- you're right - Toby - and - this morning - 6 - hours after your post ... validation - back up to 44,313 __ :( __ at - [ 28 Jan 14:39 UTC ] - [- at - 6:25 AM - Fri. - Jan. - 28 - PDT - ] - I am with you - I am also --- curious as to the nature of the phantom disk I/O being generated by mySQL. - Technical News page - January 26, 2005 - 19:00 UTC We just had a small outage to remove a fibre channel card from one of the servers. It wasn't doing anything in there and we need to have it around as a readily available spare. In other news: Thanks to random unforseen setbacks (bad CPU that needed to be replaced, jury duty, etc.) the new BOINC database server is still not ready for the prime time, but major progress has been made. The OS is installed, the RAID disk array is working, and the mysql distribution almost completely configured. After at least a week of testing, we'll start migrating data to it. Meanwhile the current database is being artificially slowed for reasons we have yet to determine. Basically, something internal to mysql caused it to suddenly read 5 megabytes/sec from the data disks. This started last Friday and hasn't stopped since. Even when there are no queries happening there are major amounts of disk I/O. Everything is working, just a little slower than it should. But also - A Big pat on the back - for Matt , David , Jeff , Eric , and all there _ at the SSL in Berkeley , California , USA - and Big pat on the back for Rom --(the man who never sleeps :) -- seems to work 24/7 _ :) they are all doing the very best they can with very -- Limited Resources -- [ money and personnel ] |
Nuadormrac Send message Joined: 7 Apr 00 Posts: 136 Credit: 1,703,351 RAC: 0 |
|
Paul D. Buck Send message Joined: 19 Jul 00 Posts: 3898 Credit: 1,158,042 RAC: 0 |
> Right now the waiting for validation is back up to 52,022. I haven't seen my > credits go up in a couple days again, but if it went down for a bit, there's > hope :) On the other hand, it could mean that they just deleted 50,000 results ... |
D.J. Schweitz Send message Joined: 29 Oct 02 Posts: 157 Credit: 871,078 RAC: 0 |
|
Paul D. Buck Send message Joined: 19 Jul 00 Posts: 3898 Credit: 1,158,042 RAC: 0 |
> UMMMMMMmmmmmm, Paul bite your tounge ;-) People tell me I have a negative attitude, but I am POSITIVE they may have deleted ... :) |
doublechaz Send message Joined: 17 Nov 00 Posts: 90 Credit: 76,455,865 RAC: 735 |
I'm wondering if the validation engine has some method of preventing starvation as I have some units still not validated after more than two weeks. On another topic, I have many work units with granted credit greater than claimed credit. I thought credit was the lowest of all the claimed for that unit. Is it instead the average? What's up? |
Pooh Bear 27 Send message Joined: 14 Jul 03 Posts: 3224 Credit: 4,603,826 RAC: 0 |
Neither the lowest or the average. It is the "middle" of the 3. Example 1: You 40.35 Person 2 45.57 Person 3 42.25 All get 42.25 Example 2: You 138.27 Person 2 20.01 person 3 141.27 All get 138.27 This is a simplistic way to average, without using a lot of processor time for averaging, since they need it for database work. It works, and no real complaints here, cause I have both fast and slow machines. The fast ones usually get more credit than claimed, and the slower ones usually get less. It comes out pretty even in the end. My movie https://vimeo.com/manage/videos/502242 |
doublechaz Send message Joined: 17 Nov 00 Posts: 90 Credit: 76,455,865 RAC: 735 |
Hm, r=(a+b+c)/3; isn't a terribly demanding calculation in comparison to select * from workunits where unit_id = xxxx;, but whatever. I don't mind the credit system, I was just confused as I thought I read in the faq that it was an average. I am a little worried about the validation queue starvation issue. Is the time the block was returned the only criterion? Meaning it won't get voided because it was validated 5 weeks late? |
Byron Leigh Hatch @ team Carl Sagan Send message Joined: 5 Jul 99 Posts: 4548 Credit: 35,667,570 RAC: 4 |
Hello every one: :) <A><B>Just in case some one may have missed this message on the front page I will repost here: for your information[/b][/url] January 28, 2005 We have turned on db_purge in preparation for the DB migration to the new hardware. This will reduce the size of the DB and so the migration will go faster. The validator will probably fall even more behind in the meantime. The migration will occur early next week. We will post the time once we have pinned it down friendly and respectful , Byron Leigh Hatch (for Carl Sagan) |
mikey Send message Joined: 17 Dec 99 Posts: 4215 Credit: 3,474,603 RAC: 0 |
> Hm, > r=(a+b+c)/3; isn't a terribly demanding calculation in comparison to select * > from workunits where unit_id = xxxx;, but whatever. I don't mind the credit > system, I was just confused as I thought I read in the faq that it was an > average. > It CAN be an average IF all 4 computers return the same unit BEFORE it is validated. In that case the formula is like you stated but you would add a "+d" within the parathensis and replace the 3 with a 4. NORMALLY the middle of the first 3 units returned is the credit granted for everyone that does that unit and returns it sucessfully. There are again exceptions though...if a unit is sent out sooo many times and then starts getting back results and a credit is granted before you return your result, you will get an error message saying too many results received. This ONLY happens after like 7 or 8 results are received. > I am a little worried about the validation queue starvation issue. Is the > time the block was returned the only criterion? Meaning it won't get voided > because it was validated 5 weeks late? > No, the validater knows that the unit is waiting and it should not be sent out again, menaing that it will wait in the queue for validating until it is validated and then credit will be granted. Normally this is when the average method as stated above comes into play. |
doublechaz Send message Joined: 17 Nov 00 Posts: 90 Credit: 76,455,865 RAC: 735 |
Good enough on the queueing. Thanks. |
©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.