:)

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 ?

---

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

---

:)

Hi mmciastro ,

thanks for your post , I agree with you :)

:)

---

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

:)

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 ]

---

This would explain things. The validation was rather speedy there for awhile this month, until about last weekend.

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 :)

---

> 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 ...

---

> On the other hand, it could mean that they just deleted 50,000 results
> ...


UMMMMMMmmmmmm, Paul bite your tounge ;-)

---

Click below for our Team Website

> UMMMMMMmmmmmm, Paul bite your tounge ;-)

People tell me I have a negative attitude, but I am POSITIVE they may have deleted ...

:)

---

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?

---

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

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?

---

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)

---

> 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.

---

Good enough on the queueing. Thanks.

---