I would like to request that the scheduling feature be given more attention to include days of week and times in half hour increments.

Running computers 24/7, many of us need downtime for our own computer housework, e.g. ,automatic backups, memory management etc. When one is responsible for several computers this may only be, for example, twice a week for half an hour. Under the current scheduling this example would mean the loss of 6 hours of number crunching lost unnecessarily every week just on one computer. I run 5 computers so this scenario currently translates to 30 hours lost every week. Multiply that by all the computers that need downtime but not every day for one hour minimum periods and a lot of calculation time is lost.

David

---

I would like to request that the scheduling feature be given more attention to include days of week and times in half hour increments.

Running computers 24/7, many of us need downtime for our own computer housework, e.g. ,automatic backups, memory management etc. When one is responsible for several computers this may only be, for example, twice a week for half an hour. Under the current scheduling this example would mean the loss of 6 hours of number crunching lost unnecessarily every week just on one computer. I run 5 computers so this scenario currently translates to 30 hours lost every week. Multiply that by all the computers that need downtime but not every day for one hour minimum periods and a lot of calculation time is lost.

David

As far as I know (at least on the Win version) there is a snooze function if you right click on the B icon in the tray. It'll suspend for an hour.

Now if you want it in the middle of the night when you're sleeping, that's a different story.

You could use a CRON job (or AT-queue / Scheduled Task as applicable) to issue a net -stop boinc command (not sure of the exact syntax since I don't use the service install).

This can be done whenever you want to start/stop boinc. This assumes that you've installed it via a service install.

---

Hi,
Apologies for the delay in acknowledging and thanking you for your responses.

Yes, it is in the middle of the night, and no, it is not installed via a service install.

I was just hoping that the volunteer programmers could perhaps consider it? Unless there is another solution ...


Many thanks,
David

---

This is under discussion on the email lists.

I'll try to dig up a link to it.


[edit]Found it...

Mailing lists

[/edit]

---

Kathryn :o)

I can't find the thread where I already complained about this issue and as it's about schedulling, I'm about to open another issue here. I'm sorry.

Consider this situation: a host only participates in one project. It has a fairly long connect every setting. Project delivers WUs with various deadlines. In particular this can be observed if a host runs SETI@home with connect every set to 5 days.

What I observed is that as WUs come in in batches host sometimes enters EDF. Then of course it runs through WUs with deadlines ending earliest. Otherwise it runs through WUs in order of arrival. As WUs have different deadlines, it happens frequently that WUs with later deadlines get crunched before WUs with earlier deadlines.

I proposed that scheduller, when running in normal mode and selecting new WU to crunch, should take whichever WU has earliest deadline. This would effectively mean that scheduller always runs in EDF for WUs in each of projects and would only round robin (in order to observe resource shares) between projects. JM7 explained that something similar is considered for new scheduller (that was sometime in 5.4 era), but doesn't seem to be done neither in 5.6 nor 5.7 series.

---

Metod ...

I can't find the thread where I already complained about this issue and as it's about schedulling, I'm about to open another issue here. I'm sorry.

Consider this situation: a host only participates in one project. It has a fairly long connect every setting. Project delivers WUs with various deadlines. In particular this can be observed if a host runs SETI@home with connect every set to 5 days.

What I observed is that as WUs come in in batches host sometimes enters EDF. Then of course it runs through WUs with deadlines ending earliest. Otherwise it runs through WUs in order of arrival. As WUs have different deadlines, it happens frequently that WUs with later deadlines get crunched before WUs with earlier deadlines.

I proposed that scheduller, when running in normal mode and selecting new WU to crunch, should take whichever WU has earliest deadline. This would effectively mean that scheduller always runs in EDF for WUs in each of projects and would only round robin (in order to observe resource shares) between projects. Currently implemented EDF would still kick in as it does now (thusly running one particular project until the deadline issue gets resolved).

JM7 explained that something similar is considered for new scheduller (that was sometime in 5.4 era), but doesn't seem to be done neither in 5.6 nor 5.7 series.

---

Metod ...