Previous study: the four day period for granting credit, you mention, would be shorter if the study was done again and most of us used a short cache.

(This brings to mind a suggestion I made years ago: use some smarts when sending out wu's to the clients. For example, 'fast turnaround' client could be used to complete a quorem, because the turn around times are recorded in the boinc databases. There are probably lots of ways to issue the wu's smarter.)

Out of work: I don't think you are correct. In my experience, when seti is indisposed and I run out of seti work, my back-up project einstein simply downloads more wu's to keep the cpu burning. I keep a small cache on the other project as well so that I don't have too many einstein wu's to process. Otherwise, I would experience a delay returning to seti when the downloads re-start.

---

May this Farce be with You

PhonAcq

I have to agree with you about the study... For example if you look to the left you will see my RAC currently 1500+ If it truly took 4 days (like marbles in a pipe, First in First out) then when I look at my "Pending Credit" on my account page. I should see about 6000+ Pending Credits. This should also hold true for just about every project. Currently my Pending Credit is about 1500+. So that said in most cases esp... in Seti the turnaround from when the Workunits are delivered and returned, you should be seeing credit in a day or less.

Things that would impact on not seeing credit in a day or less... User A has a 10 day cache and loads it up and shuts down the internet connection. User A does not plan on connecting for 9 days. User B heard that User A collects 10 days of work and then shuts off the internet connection and does not connect for 9 days. A couple of other users hear about this and it seems plausible... So guess what they start trying that also... IF enough people start doing this they defeat the purpose of returning Results as quickly as possible and then get caught in the next "un"planned outage with not enough work. It also places stress on the overloaded servers keeping track of all the crap.

Even with the "severity" of the current problems, most Seti outages take less than 24 hours to solve. So a LARGE CACHE of workunits does not really help anyone, if for some reason you hit a power outage or other unforesen issue you be the person that does not return the workunit in time. In the case of an outage, if you can not get work look at some of the other projects. Many could use some extra computer time, they are there because of Seti and BOINC.

So a reasonable number of days cache should be 3 days or less...

So other than a couple of older machines that are just used in Seti Beta for testing compatibilty for older machines (which are currently turned off to conserve electricity) my machines have work to the keep the CPU's warm and toasty...

Pappa's connect time is set at .5 days (or 12 hours of work cached) there have only been a couple of times that I wondered if the CPU(s) would get cold. One was when Seti Beta was down for a long planned maintence and Einstein was Broke... The PII 400 that only does Seti Beta made the trip fine... The faster machines needed watching.

Regards

Pappa

Previous study: the four day period for granting credit, you mention, would be shorter if the study was done again and most of us used a short cache.

(This brings to mind a suggestion I made years ago: use some smarts when sending out wu's to the clients. For example, 'fast turnaround' client could be used to complete a quorem, because the turn around times are recorded in the boinc databases. There are probably lots of ways to issue the wu's smarter.)

Out of work: I don't think you are correct. In my experience, when seti is indisposed and I run out of seti work, my back-up project einstein simply downloads more wu's to keep the cpu burning. I keep a small cache on the other project as well so that I don't have too many einstein wu's to process. Otherwise, I would experience a delay returning to seti when the downloads re-start.

---

Please consider a Donation to the Seti Project.

Just to refine my point, I don't care when I get the credit posted; that is not the reason to have a short queue.

But for the typical user (not the guy who wakes up every 10 days) a short queue will turn the wu's around faster. Then on average the number of wu's that must be kept alive on the central servers should go down and reduce the average load on the server storage. (This approach to cacheing has no effect on network traffic etc. since the number of bytes transferred back and forth is the same on a long term average. It may have an effect if the connection overhead is onerous, because now each client will make more frequent, but shorter connections.)

In short, my suggestion is to give seti (storage) a break: reduce the cache to 0.5 d and hook up to a second or third project at a low resource allocation for times when seti is sick.

If a significant number of people actually do go to sleep for 10d at a time between connections, then my argument fails. I guess one needs to do a proper Monte Carlo analysis to see where the break-point threshold is, and then contrast it to the actual seti user statistics. (Does anybody have a table of number of hosts versus connection frequency?)

---

May this Farce be with You

Once again

I understand your point, I also understand that a lot of other "mis-information about helpful sugestions" happens... Your Key Point in Red below is Important!

Just to refine my point, I don't care when I get the credit posted; that is not the reason to have a short queue.

But for the typical user (not the guy who wakes up every 10 days) a short queue will turn the wu's around faster. Then on average the number of wu's that must be kept alive on the central servers should go down and reduce the average load on the server storage. (This approach to cacheing has no effect on network traffic etc. since the number of bytes transferred back and forth is the same on a long term average. It may have an effect if the connection overhead is onerous, because now each client will make more frequent, but shorter connections.)

In short, my suggestion is to give seti (storage) a break: reduce the cache to 0.5 d and hook up to a second or third project at a low resource allocation for times when seti is sick.

If a significant number of people actually do go to sleep for 10d at a time between connections, then my argument fails. I guess one needs to do a proper Monte Carlo analysis to see where the break-point threshold is, and then contrast it to the actual seti user statistics. (Does anybody have a table of number of hosts versus connection frequency?)

---

Please consider a Donation to the Seti Project.

One weird thing is that I now have many more d/l work units than I normally do.
I have 350 on the box and 14 more waiting to d/l. That is about 5 pages of tasks when normally i usually only see about half a page.

Up side is that now it has plenty! of work to do!.
LOL

---

We have found that some change lately resulted in the need to restart the BOINC client to pick up a new IP, and in some cases, even a reboot of the system was necessary.

---

Hi Matt,

I have noticed that your kryten computer has had some issues. I would be willing to donate an HP enterprise xlr 8500 8 cpu xeon 700 mhz computer to replace kryten.
I have had this unit for six months without any problems what so ever. If you are interested please let me know. The only thing that I require is that the computer be named seti.usa. P.S. the unit has 4 geg memory and twin 16 geg 10,000 scsi drives, and needs 220 vac to run.

Dr. Dan.

---

Hello folks

Having read this thread and note that you mention NFS, you obviously use a unix variant os. May I suggest you explore linux clustering software as a potential tool to aleviate some problems. You get inbuilt automatic process relocation -done at the kernel level so its reliable and complete-. Also automatic cluster load balancing across the entire cluster, jobs will auto-migrate to the best cpu. some versions use a "sandpit" method of process migration so you effectively grab another systems CPU RAM I/O and use it as your own... networkloads can increase but then use high speed switches to segment the network.

It is used extensively with my work here.

cheers

Hi Matt,

I have noticed that your kryten computer has had some issues. I would be willing to donate an HP enterprise xlr 8500 8 cpu xeon 700 mhz computer to replace kryten.
I have had this unit for six months without any problems what so ever. If you are interested please let me know. The only thing that I require is that the computer be named seti.usa. P.S. the unit has 4 geg memory and twin 16 geg 10,000 scsi drives, and needs 220 vac to run.

Dr. Dan.

Hi Dr. Dan,

I will make sure that this gets brought up at the systems meeting.

Eric

---

@SETIEric@qoto.org (Mastodon)

Hi Matt,

I have noticed that your kryten computer has had some issues. I would be willing to donate an HP enterprise xlr 8500 8 cpu xeon 700 mhz computer to replace kryten.
I have had this unit for six months without any problems what so ever. If you are interested please let me know. The only thing that I require is that the computer be named seti.usa. P.S. the unit has 4 geg memory and twin 16 geg 10,000 scsi drives, and needs 220 vac to run.

Dr. Dan.

Um, I just noticed the 220 VAC. We don't have 220 in the server closet, and I doubt the building manager would run it there for us. (This building was very poorly designed when it comes to the requirements of research or computer equipment.)

Eric

---

@SETIEric@qoto.org (Mastodon)

Hi Matt,

I have noticed that your kryten computer has had some issues. I would be willing to donate an HP enterprise xlr 8500 8 cpu xeon 700 mhz computer to replace kryten.
I have had this unit for six months without any problems what so ever. If you are interested please let me know. The only thing that I require is that the computer be named seti.usa. P.S. the unit has 4 geg memory and twin 16 geg 10,000 scsi drives, and needs 220 vac to run.

Dr. Dan.

Um, I just noticed the 220 VAC. We don't have 220 in the server closet, and I doubt the building manager would run it there for us. (This building was very poorly designed when it comes to the requirements of research or computer equipment.)

Eric

You guys are being offered a free server, and can't make that happen?

---

http://www.setiusa.net

What about putting the server on UPS with 220V output, which is capable running on 110V input too?

Peter

A kind email to HP would probably resolve this problem.

Most 220vac switched mode power supplies can be changed to the lower 120vac voltage by moving some wire links within the power supply.
If you are really fortunate it may even have an internal switch which makes it even easier!

I must stress that for safety reasons this must be done by a qualified electronics engineer as ALL sm power supplies retain high voltages in the storage capacitors for long periods of time after the power feed has been removed from them!

Hope this is of help.

Regards,
Graeme.

---

How about just replacing the powersupply with the 110 variety. A free server for the cost of a power supply.

---

SETI@home classic workunits 5,429
SETI@home classic CPU time 73,472 hours

Not sure what the rage is about. We don't have 220 in our server closet. This is not a formal server closet but basically a former janitorial storage closet that we retrofitted (at much of our own expense) to put in air conditioning and as many 110 breaker circuits in there as possible. As Eric stated already this building wasn't built for such projects as ours. All of our servers, new and old, run just fine on 110, so we haven't yet needed to deal with 220.

To get 220 could be expensive, and definitely time consuming (central campus has to be called and scheduled, and we're at their mercy about how many weeks/months before they show up).

- Matt

---

-- BOINC/SETI@home network/web/science/development person
-- "Any idiot can have a good idea. What is hard is to do it." - Jeanne-Claude

So, this is just a nice way to say: No, thanks?

So, this is just a nice way to say: No, thanks?

Well, no - when everybody is in one place we'll still discuss if we want this or not. So no decisions yet. But this all is making it clear to us that we need to update our hardware wants/needs list with some accurate detailed information.

- Matt

---

-- BOINC/SETI@home network/web/science/development person
-- "Any idiot can have a good idea. What is hard is to do it." - Jeanne-Claude

The rage in the matter. Everyone that does seti would like to see things fixed over there so we can proceed forward in reading data.. Newcommers will come here, see that there's problems, get tired of it and move on, hence hurt the project. DrDan is offering a fix to kyrten's problems. Why not try and figure a way to make his server work, and take his offering. You won't see that kindof offer comealong all the time coming from a fellow cruncher. But, anyways.

---

So, this is just a nice way to say: No, thanks?

Well, no - when everybody is in one place we'll still discuss if we want this or not. So no decisions yet. But this all is making it clear to us that we need to update our hardware wants/needs list with some accurate detailed information.

- Matt

Easiest solution would be to swap out the power supply in the system with a 110 VAC. even a server-grade power pack, if it's not a hot-swap type, shouldn't run more than about $150-200 USD. All you'd need is a screwdriver and about 20 minutes. There'd be no need to worry about re-wiring the building. 220VAC, 110VAC, doesn't really matter it all gets converted to 12VDC by the time it gets to the mainboard anyway.

---

Without Weapons, Just Another Airline - 2W1

So, this is just a nice way to say: No, thanks?

Well, no - when everybody is in one place we'll still discuss if we want this or not. So no decisions yet. But this all is making it clear to us that we need to update our hardware wants/needs list with some accurate detailed information.

- Matt

OK. I was just a bit worried there. Looked like you turned the offer down very quickly.