LHC@home

Why are some people keeping enormous work caches? Like this guy in here One computer

A bit over 500 WUs on a Pentium 4 3.0 GHz. Is there any sense?

---

Why are some people keeping enormous work caches? Like this guy in here One computer

A bit over 500 WUs on a Pentium 4 3.0 GHz. Is there any sense?

Well over a hundred (I stopped counting) will hit the deadline tomorrow and since he`s doing less than 10 a day!!!!!!!!!!. Maybe the admin people could stop this happening. Theres worse offenders in other projects, one in Simap with 1700 just timeing out while I wait (pending credit) for the wu to be re-issued.

---

Why are some people keeping enormous work caches? Like this guy in here One computer

A bit over 500 WUs on a Pentium 4 3.0 GHz. Is there any sense?

Well over a hundred (I stopped counting) will hit the deadline tomorrow and since he`s doing less than 10 a day!!!!!!!!!!. Maybe the admin people could stop this happening. Theres worse offenders in other projects, one in Simap with 1700 just timeing out while I wait (pending credit) for the wu to be re-issued.

I seem to remember some other problems with this user, (I think it's the same one, same user name.)

One system owned by Anonymous was reporting benchmarks of 99999 ops/sec.

I don't know it this is the same person.

We do *not* know the size of this user's cache. We know the number of WU issued and not yet returned, and that is not the same thing.

The cache is the size of the queue actually held on that computer. There are a number of reasons why the database might show an apparent cache bigger than the real one. The two most common are

1. errors in the issuing of work (so called "ghost units") where the sceduler thinks work has been issued to a client, but the client never received the work. This effect is never down to the user, so neither stupidity nor malice can apply

2. the user has reset the project on that box, making the client "forget" about it's previous cache. There can be good reasons for doing this, but in general if the client is responding at all it is considered good practice to abort all previous work and update to report it before doing a reset. This effect can therefore be down to ignorance or stupidity. I did it once by clicking on the wrong icon in BoincView, an example of stupidity - temproary I hope ;-)

3. The user has a non-standard client that lies (deliberately or otherwise) about the files it currently holds on its hard drive). Whether this is stupidity or malice depends on the user's reason for developing a non-standard client.

You can see that this user has requested batches of work on 28th and on 30th March for example. Even with a 10 day cache, at 10 WU/day the system should not have issued new work, and would not have done if the old work had still been on the user's hard drive - instead they'd have got the dreaded "won't finish in time" message.

My thoughts on how to avoid this would need a re-coding of the quota system, but I am not sure exactly how - all the alternative schemes I can think of would either clobber genuine errors much harder, or would not limit userslike this one who do actually return *some* work.

As far as I can see it is not something that the admins on a project can do anything about by changing settings, it needs new coding. And the number of these users is probably small enough that the effort would be beter spent elsewhere.

River~~

---

I seem to remember some other problems with this user, (I think it's the same one, same user name.) ... I don't know it this is the same person.

Possibly not - on at least some projects the notes for new users tell people to use Anonymous as a name if the don't want to identify themselves.

In any case, as you probably know, BOINC has no limit on duplicate names

River~~

We do *not* know the size of this user's cache. We know the number of WU issued and not yet returned, and that is not the same thing.

In that you are right, but work cache can be estimated by counting the downloaded WUs and looking the average run time from previous ones (as this user has returned those).

I won't be counting all but I presume that he has downloaded about 250 WUs at once. His average run time is about 2 and a half hours. So he would crunch those workunits 26 days. Still the deadline comes after 9 days.

---

I won't be counting all but I presume that he has downloaded about 250 WUs at once.

Impossible.

On this project the max quota is set a 100. This means that unless the user has reset or detached/re-attached they cannot download more than 100 WU in a day.

If they detached/re-attached they'd also have had to merge to get all the WU back on the same host id (is this possible while both ids have outstanding work ??)

Secondly, the scheduler checks to see if you can do the work in the time. Here the user can be cheating - if the benchmarks claim a faster crunch time than is true then the scheduler will allow too much work. This should be countered by the result duration correction in the long term.

If you are right and he has downloaded 250 WU at once, or even on the same day without a detach/reattach, then there is a bug in the scheduler quota code which is already designed to limit such things.

I had assumed he got ~600 wu over 6 or more different days.

River~~

In any case, as you probably know, BOINC has no limit on duplicate names

River~~

Thanks River.
I did not know about this, Could have just stuck with my first name. Oh well I'll just leave it as is now.

In any case, as you probably know, BOINC has no limit on duplicate names

River~~

Thanks River.
I did not know about this, Could have just stuck with my first name. Oh well I'll just leave it as is now.

Then I am glad you didn't know ;-)

- it gets confusing if people use ambiguous names and even tho BOINC allows duplicates I personally prefer people not to take advantage of that (unless they are anonymous).

And also this way I know that you are very likely the same peterthomas whose posts Ive noticed over on Einstein, where I sign myself gravy or gravywavy

~~

---

HM, guys, keep cool.

He seems not realy to cheat: His Benchmarks seem to be nearly the same than on one of my boxes, that looks similar.

May be, he is using a bad CoreClient ...

---

Supporting BOINC, a great concept !

I think LHC is an extremely important project and I love helping with it.
In fact, I love the project SO much I keep my cache set at only 4 days so I don't grab too many work units and cause the last 5,000 or 10,000 to take more time to come in than the first 80,000.
It's just foolish and stupid to grab excessive WU and delay the run, especially with BOINC you can always be working on something worthy.
Please people, do not delay the day the physicists make the Big Mistake and collapse the universe back into undifferentiated quantum foam. ;=)

---

I think LHC is an extremely important project and I love helping with it.
In fact, I love the project SO much I keep my cache set at only 4 days so I don't grab too many work units and cause the last 5,000 or 10,000 to take more time to come in than the first 80,000.
It's just foolish and stupid to grab excessive WU and delay the run, especially with BOINC you can always be working on something worthy.
Please people, do not delay the day the physicists make the Big Mistake and collapse the universe back into undifferentiated quantum foam. ;=)

---

Is differentiated quantum foam the same as ordinary matter? ;)

---

Is differentiated quantum foam the same as ordinary matter? ;)

Beats the hell out of me friend.
Hopefully, an attempt at mild humor doesn't have to come with The Math here :)

---

Is differentiated quantum foam the same as ordinary matter? ;)

the answer depends entirely on your definition of the term "ordinary matter". :P

How does this discussion about quantum foam aid the original question about cache sizes?

---

Gaspode the UnDressed
http://www.littlevale.co.uk

Is differentiated quantum foam the same as ordinary matter? ;)

the answer depends entirely on your definition of the term "ordinary matter". :P

and of the terms "differentiated", "quantum" and "foam" when used together

I won't be counting all but I presume that he has downloaded about 250 WUs at once.

Impossible.

On this project the max quota is set a 100. This means that unless the user has reset or detached/re-attached they cannot download more than 100 WU in a day.

If they detached/re-attached they'd also have had to merge to get all the WU back on the same host id (is this possible while both ids have outstanding work ??)

Secondly, the scheduler checks to see if you can do the work in the time. Here the user can be cheating - if the benchmarks claim a faster crunch time than is true then the scheduler will allow too much work. This should be countered by the result duration correction in the long term.

If you are right and he has downloaded 250 WU at once, or even on the same day without a detach/reattach, then there is a bug in the scheduler quota code which is already designed to limit such things.

I had assumed he got ~600 wu over 6 or more different days.

River~~

Actually, it would be possible, but not with one CPU core... The quota lists

Maximum daily WU quota per CPU

But in an SMP box which has more then 1 CPU, or a dual core proc like an A64 X2, which counts as 2 seperate CPU cores, it should, all holding as such allow one to then grab more WUs. Course even with a dual core box, that would be 200 (100 for each CPU core), not 250...

I'm rather certain that this is as advertized, and limited per CPU, not user account? With multiple comps in a farm, one could grab more per day...

---

First, as has been said, check you have the same email address (case sensitive) on all projects. This can be changed, if need be, on the project preferences page. While you are changing emails to get them to match, try if possible to keep the email unchanged on the project you joined first

If you later need to change your email address, do it for all projects as close in time to each othert as you can.

A) If you have just one box that is connected to all your projects, the CPID will align itself on that box, and over a period of time will come right on all the others.

B) If you have one project that is represented on every box, it will all come right for the other projects.

If you have a mesh of different project combinations then it will eventually come right, unless the combinations can logically fall into two separate groups - I suggest going for one of the two cases (A) or (B) above to make sure.

If you use boincstats (or suchlike) then you may or may not need to change the url that generates your stats after the CPIDs have aligned.

hope that helps. good luck
If all your clients are version 5+ then the eventual CPID will be the one that belongs to the project you joined first. With earlier clients this was not always the case.

---

I won't be counting all but I presume that he has downloaded about 250 WUs at once.

Impossible.

On this project the max quota is set a 100.

But in an SMP box which has more then 1 CPU, or a dual core proc like an A64 X2, which counts as 2 seperate CPU cores, it should, all holding as such allow one to then grab more WUs. Course even with a dual core box, that would be 200 (100 for each CPU core), not 250...
...

You are right of course, I'd overlooked multicores. With a 4 cpu box (or 2 cores with HT) you could get 400 WU per day.

The actual limit is 100 per cpu up to a max of 4 cpu, so nobody could get 500 wu in a day without some detaching trickery.

River~~