constant scheduler requests

[Euphoriabuzz]

Hi, Eon on my BM is doing scheduler requests every 1-2 mins

07/09/2010 12:30:37 cplan Reporting 2 completed tasks, not requesting new tasks
07/09/2010 12:30:39 cplan Scheduler request completed
07/09/2010 12:31:30 eon2 Sending scheduler request: Requested by project.
07/09/2010 12:31:30 eon2 Not reporting or requesting tasks
07/09/2010 12:31:32 eon2 Scheduler request completed
07/09/2010 12:33:32 eon2 Sending scheduler request: Requested by project.
07/09/2010 12:33:32 eon2 Not reporting or requesting tasks
07/09/2010 12:33:35 eon2 Scheduler request completed
07/09/2010 12:35:35 eon2 Sending scheduler request: Requested by project.
07/09/2010 12:35:35 eon2 Not reporting or requesting tasks
07/09/2010 12:35:37 eon2 Scheduler request completed
07/09/2010 12:37:38 eon2 Sending scheduler request: Requested by project.
07/09/2010 12:37:38 eon2 Not reporting or requesting tasks
07/09/2010 12:37:40 eon2 Scheduler request completed
07/09/2010 12:39:40 eon2 Sending scheduler request: Requested by project.

This has been going on for days now.
Is this normal as other projects seem to have a backing off period.

[ritterm]

I've noticed this, too. It's happening even when no eOn WUs are running or even in the task queue. Just being attached to the project generates these request updates every 2 minutes.

I understand that this might be necessary based on the project's needs, and, if that's the case, that's fine. However, this behavior causes the message queue to fill up and can make it difficult to find other messages that are more important.

[Saenger]

Mine is longer :P

OK, I've got even more messages cluttering the message tab:

Code: Select all

Di 07 Sep 2010 17:45:39 CEST	eon2	Sending scheduler request: Requested by project.
Di 07 Sep 2010 17:45:39 CEST	eon2	Requesting new tasks for GPU
Di 07 Sep 2010 17:45:44 CEST	eon2	Scheduler request completed: got 0 new tasks
Di 07 Sep 2010 17:45:44 CEST	eon2	Message from server: No work sent
Di 07 Sep 2010 17:47:46 CEST	eon2	Sending scheduler request: Requested by project.
Di 07 Sep 2010 17:47:46 CEST	eon2	Requesting new tasks for GPU
Di 07 Sep 2010 17:47:51 CEST	eon2	Scheduler request completed: got 0 new tasks
Di 07 Sep 2010 17:47:51 CEST	eon2	Message from server: No work sent
Di 07 Sep 2010 17:49:51 CEST	eon2	Sending scheduler request: Requested by project.
Di 07 Sep 2010 17:49:51 CEST	eon2	Requesting new tasks for GPU
Di 07 Sep 2010 17:49:56 CEST	eon2	Scheduler request completed: got 0 new tasks
Di 07 Sep 2010 17:49:56 CEST	eon2	Message from server: No work sent
Di 07 Sep 2010 17:51:57 CEST	eon2	Sending scheduler request: Requested by project.
Di 07 Sep 2010 17:51:57 CEST	eon2	Requesting new tasks for GPU
Di 07 Sep 2010 17:52:02 CEST	eon2	Scheduler request completed: got 0 new tasks
Di 07 Sep 2010 17:52:02 CEST	eon2	Message from server: No work sent
Di 07 Sep 2010 17:54:02 CEST	eon2	Sending scheduler request: Requested by project.
Di 07 Sep 2010 17:54:02 CEST	eon2	Requesting new tasks for GPU
Di 07 Sep 2010 17:54:07 CEST	eon2	Scheduler request completed: got 0 new tasks
Di 07 Sep 2010 17:54:07 CEST	eon2	Message from server: No work sent
Di 07 Sep 2010 17:56:08 CEST	eon2	Sending scheduler request: Requested by project.
Di 07 Sep 2010 17:56:08 CEST	eon2	Requesting new tasks for GPU
Di 07 Sep 2010 17:56:18 CEST	eon2	Scheduler request completed: got 0 new tasks
Di 07 Sep 2010 17:56:18 CEST	eon2	Message from server: No work sent
Di 07 Sep 2010 17:58:18 CEST	eon2	Sending scheduler request: Requested by project.
Di 07 Sep 2010 17:58:18 CEST	eon2	Requesting new tasks for GPU
Di 07 Sep 2010 17:58:23 CEST	eon2	Scheduler request completed: got 0 new tasks
Di 07 Sep 2010 17:58:23 CEST	eon2	Message from server: No work sent

So at least my puter is asking something, if only something completely futile ;)

[matt]

We've backed off the scheduler a little. Due to the nature of our current simulation, clients need frequent updates from the server in order to make sure that the work they have is still useful. As we start to do more accurate calculations and more simulations in parallel, the need for scheduler requests should decrease.

[vaughan]

Matt its a pain in the neck when you have many computers as it floods the router with network traffic.

[Chuck]

I too am getting a lot of scheduler requests.

Luckily, I have only the laptop (a dual core) running Eon2.

One thing I am finding is that with Quorums set to 1,1,1 there is an intense amount of traffic resulting in an implied OBSCENE amount of traffic at the router and WU generator.

Having run (helped admin) the older V4 BOINC system, I simply ask:

a) Is there any benefit to increasing Min Quorum to 2? (it would relieve work on WU generation and 'borgie' seems to be keeping up just fine
b) While in Windows (where my throughput was considerably slower), I was permitted 4 WUs at a time.... 2 running and 2 queued. Now in Linux on the same
hostname, but different computer ID, I am allowed 2, and only 2 WUs at a time. somewhere around 75-90% of my time is idle due to lack of WUs.
Would increasing Min Quorum to 2 and replication to 2 be a savings or more load overall ?

In the past, I have seen where a client comes in, gets 3-4-5-6 WUs and is gone until 75-80% of them are done. The expiration time is 24 hours and average turn around is typically 10-20 minutes on a slow laptop in x86_64 mode. (Server stats show turn around time as 0.01 days)

c) The ultimate question is: If a client experiences trouble, or a user does not correctly transition from say windows -> Linux and a WU or 2 are left behind to expire, is the user penalized for this and if so, how long ? (I'm not the only user with this condition)

d) What can we report to our teams to help you the most with this batch of WUs?

e) Have you considered a 'Recent News/Updates' (on the main or 'my account' page(s) for the users to follow along with official notification of what to expect so they can adjust AHEAD of time and relieve some loading on your LAN, Router, and Servers ?


Thanks,
Chuck

[matt]

To answer your questions:

a) We don't have redundant computing set up because we are able to verify the correctness of work units with far less computation than re-running them.

b) You should now be able to get a constant stream of work. You can check the number available WUs at http://eon.ices.utexas.edu/eon2/server_status.php.

c) Unfinished work units are not penalized. Our simulation scheme relies on (somewhat) randomly sampling a function, where each sample is independent of all others. When one sampling job is lost, the others are not affected.

d) More crunchers are always welcome!

e) We've added a news section to the front page. Thanks for the suggestion.