I really think that leaving the deadline at 4 days will almost require me and others to stop doing these tasks since Sophie tasks always run first so I have to wait until almost the 3rd day to run these. Either that the scheduler will not send out as many tasks and I will run out of them so fast that I won't be able to get new ones. Please at least watch how many abort due to deadline because I believe you will see a big increase in this if the deadline is shorter.

Saying Sophia tasks always run first may be true only if you don't use an app_config file. With an app_config file, you can always allow TRP to run immediately.

Following your theory, why don't you reduce the deadline to 1 day ?
The question is not the task duration but the availability of computers for this particular application. The shorter is the task, the higher is the number of WU received so the total workload received in one batch remains the same. Reducing the deadline of short tasks is a nonsense : it only makes participants' work very difficult, as they should drastically reduce the work buffer size used by the BOINC application for ALL projects and select computer by computer the PrimeGrid subprojects to be run if they want to complete the WUs in time.
Other point : I don't know how long is the week-end break in your country, but in mine, it's around 60 hours, so it will be very difficult to complete a 3-day (72h) deadline.
You must consider that a lot of computers running BOINC don't work 24/7 and aren't 100 % available for an unique subproject.

I agree that the 1-day idea is a little sarcastic, but running your project gives headaches.

Please have a look on the participants' point of view : I really think that you misunderstand the way BOINC application works on THEIR computers.

Suppose that I have a 1 day buffer and 2 cores active. I will roughly receive WUs for a total of 48h workload. If the WU duration is 2 hours, I will receive 24 WUs. If it's only 1 hour, I will receive 48 WUs. As the 48 new WUs will complete in the same time than the 24 old WUs, there is absolutely no reason to reduce the deadline.

Reducing the deadline as you do in your project has an unique effect : force all WUs to run in high priority, with the risk of not completing in time. May be it's your goal, but let me tell you that this is a nonsense in a time-sharing environment!

Side question;

Will there be android Work Units again?[/b]
____________

One final question:

If you were making the decisions, how long would you make the deadlines, and why?

IF you have a dedicated crunching machine that works 24/7, you really should take Michael's advice and set your BOINC work cache from .2 days to 0.

We're going to reduce the deadline for TRP-Sieve tasks to three days. Currently it's 4 days, despite these being very short tasks.

If you were making the decisions, how long would you make the deadlines, and why?

I have an Atom 270 notebook, it runs 2-3 hours every evening. So I can't crunch anything on it because a shortest WU is TRP-sieve, but the deadline is not enough to crunch on this PC even TRP-sieve WUs.

So I think reducing the deadline is not a good idea if there aren't strong arguments.

This is the notebook which last connected to PrimeGrid in April of 2014? I was going to ask how long the tasks took on your notebook

These computers are VERY slow and can only contribute a tiny amount of computing power to our project (or any project). Furthermore, unlike the argument for creating Android apps, there's also very few computers like this, so their aggregate computing power is also miniscule.

It should be noted that there are inherent BOINC limitations in the number of sub-projects we can run.

The reason for shorter deadlines isn't as much for quicker results as it is for faster validation (or challenge cleanups)

If you're running multiple projects simultaneously, you're just asking for trouble.

Is it fair to ask us to modify our project because SETI isn't reliable or SIMAP only has work periodically? (Yes, I know SIMAP shut down -- but it's a good example.)

I've changed the thread title from "Reducing TRP-Sieve deadline to 3 days" to "Reducing TRP-Sieve deadline to 3 days, or increase everything to 4 days?"

I want to expand this discussion to include the possibility of increasing all 3 day projects to 4 days -- the exact opposite of reducing TRP-Sieve from 4 to 3 days.

I was used to work with the same figures (0.5 day + 0.5 day), and I usually have around 1 day of work in queue for each project or subproject. When a queue decreases to its lower limit, I'm receiving a bunch of new WUs. But Primegrid behaviour is very strange : GPU tasks duration is underestimated whilst CPU tasks duration is overestimated, so the planned execution time for both is playing yoyo in a 1 to 4 range. When high, I have only a few WUs in queue. When low, I'm receiving a lot of WUs, so they turn to high priority, monopolize the resources and fall out of time. A real mess! The only solution I've found is to reduce the buffer size: I'm now at 0.2d + 0.2d and it runs. Using lower values is risky as I don't have a permanent Internet link to all Project servers.
You should understand that, as soon as computers have several WUs in queue, there is no relation between deadlines and task duration. If PRIMEGRID reduces its deadlines, participants will have to reduce their pending workload, that will effect ALL other projects.
I will try to go to 0d+0d. If not satisfactory, I will stop crunching for Primegrid.

Please note that I'm only running short tasks, as a single PrimeGrid long task require more than 50% of resources availability of 1 thread to complete in time.
As example, an openCLPPSsleeve WU takes 4 hours to complete on my IMAC, and I have 1 WU running and 8 WUs in queue. Total working time: 36h. For heating protection, my GPU doesn't work when I'm using the computer. So I should clear this queue in around 3 days if running only this subproject. But I'm using BOINC, based on multi project distributed computing. If running only 2 projects and 2 Primegrid subprojects in Parallel with GPU WUs, only 25% of GPU resources are available for this single subproject, so it will not take 3 days but 12 to clear the queue and get new WUs. Look at the deadline! This has no sense in a multi project environment, except if Primegrid plans to monopolize 100% of participants resources for its own project.

The Primegrid deadlines already are ridiculously short. Don't try to reduce them any more. The most important Challenge for this project is to make participants' life easy.

I was used to work with the same figures (0.5 day + 0.5 day), and I usually have around 1 day of work in queue for each project or subproject. When a queue decreases to its lower limit, I'm receiving a bunch of new WUs. <snip>

4 days deadline will be a gift for weak computers and users who didn't use their computers very often

You're right: in order to get 0.5+0.5, I've set buffer sizes to 0,5d/1d.
Yesterday, I tried to go down to 0/0. The queues have been reduced to the minimum, but, as some project servers (and my Internet connection) are not 100% available, I spent long times without work. So I absolutely need a reserve of work.
I went back to 0.1d/0.2d. With 3 CPU threats active, I should have between 7,5h and 15h of total CPU load and between 2,5h and 5h of GPU load. Please note that I'm running 2 projects at 100-100 and that the GPU don't work when the PC is used.
FALSE: after an automatic update, the total CPU workload is now 164h for Primegrid (7 WUs for 4 subprojects) + 3 hours for another project (6 WUs), and the GPU workload is 25h for a single Primegrid subproject (6 WUs in queue + 1 in progress).
Running 24/7 in absence of other use, the maximum available time per project and per day for my PC is 24h x 3 threats x 0.5 = 36h, and 164h correspond to 4.5 days.
With 4-day deadlines, it's already hard to complete in time. With 3-day deadlines, I'm completely out.

My point of view:
24/7 machines: if a buffer set according to the CPU power, no problem for both DLs.
9/5 business/office desktop machines: 4 days DL means serious problem (buffer must be set under 0.9), 3 days DL means unusable application (or buffer < 0.1)

A wise solution should be to multiply all deadlines by a factor of 2 or 3.

Well, I'll admit, I am now a bit confused. I run a mix of projects, primegrid is assigned 50% of 4 cores running at 50%. The next three projects (ATLAS, Einstein, VirtualLHC) take up a combined 25%. Einstein usually sends me GPU tasks. My 3 low priority projects take up the remaining 25%. I run 0/0.

I run PoP and PSP both of which are relatively long WUs.

My point of this is that I don't see the kind of scheduling difficulties that apparently happen to other users. I don't expect the BOINC scheduler to honor the priorities strictly, but in general, it does pay attention to the overall assignments. So why am I not having the same issues as other, not that I am complaining :-)?
____________
Thanks,
Jim

So therefore, I have no problem with either setting of TRP.

Grrr...I messed up.

I described my LLR machine, not my sieve machine.

I run two sieves, TRP and ESP. They both take about 40 minutes to run on an old MacPro. Prime grid is allocated 50% of a 4-core system which is operating at 50%. Einstein, VirtualLHC, Milkyway and Seti share the remaining 50%.

I have never had a problem with getting enough sieves to run. I am running at 0/0. I do not anticipate much change if TRP Sieve goes to three days.

Jim

Personally I have stopped bothering with Prime Grid tasks simply because they don't allow enough time. If I go on holiday there are too many tasks that run out of time or have to be run as high priority when I get back.

These days I only work for projects that allow 14 days.

Cutting your already stupid 4 days to 3 is just going to alienate more people. And what for? The numbers have been prime or not since before the start of the universe and still will be in another few days. What's the rush?

When I am away from my machines, I just turn them off. That is as much for security's sake as anything, but it does try around the problem that Nick has.
____________
Thanks,
Jim

These tasks take less than 40 minutes on average to finish. 3 days (10800 minutes) divided by 40 says approximately 270 (or more) on average can be done for a machine that is 24x7. If you machine runs 8 hours a day instead of 24 you can still do 90 or more in 3 days. I am unsure where the logic of having to have 4 days is. These are sieve tasks, they help keep the LLR tasks cleaner by removing known composite numbers. In it's current iteration it will never find a prime from this.

I say put it at 3 days. I understand about outages and stuff, but since tasks need two people to validate so you most likely will be the second man in, so what. Even if delayed by a day and someone else gets the same task it still is in the database for a few days before deleted and you will still get your credit.

Keeping the LLR releases cleaner is a mighty important job for the sieves. Yes 4 days work, but if timed out slow down the process, then 8 days then 12 days. Now at 12 days and 3 day deadline you have to get an extra chance at a wingperson if it times out that many times giving you a better chance at the work being completed.

I am unsure why this became a discussion anyway, ESP sieve is a little longer in completion time and goes 3 days and I have never seen anyone complain about it. This just became an issue because PG announced they were making the change instead of just doing it. I bet not many people would have even noticed the change.

I agree.

Jim

3 days to get the LLR cleaner sooner.

Poll!

If this is simply to help clean up after challenges, then I don't see why it is a problem in the first place. If it were something like SOB, then maybe. I have a 2P AMD rig that takes a couple months to complete those work units. So, I can see the hurry to finalize the stats reporting. (though still not fair for those whom don't care about the challenge) But for a very short work unit? That is just silly to be concerned about...

I don't see any other reason to demand a short deadline. I do see more problems arising by shortening it than good. If the tasks go into panic mode due to becoming "high priority" then BOINC will pause GPU work to squeeze every ounce of CPU time out to complete work. This happens even if you reserved a full core for GPU work. Reducing the deadline will only increase this potential headache. If anything, deadlines for the shorter work units should be increased as there is no needed rush for them.

I typically keep a 0 or near 0 cached. I also tend to run multiple projects. Very rarely do I run into the above issue, but it does still occur from time to time. I would think encouraging the potential scenario above with shorter deadlines would be counter productive as that would suspend greater work being done on the GPU's even if someone was only attached to PG. Just my $.02.
____________

Personally I have stopped bothering with Prime Grid tasks simply because they don't allow enough time. If I go on holiday there are too many tasks that run out of time or have to be run as high priority when I get back.

These days I only work for projects that allow 14 days.

Cutting your already stupid 4 days to 3 is just going to alienate more people. And what for? The numbers have been prime or not since before the start of the universe and still will be in another few days. What's the rush?

Regarding TRP-Sieve, increasing or decreasing by one day won't make any difference to me.

For longer tasks like SoB or GFN-WR, please don't ever increase the deadline period unless a change in the tasks warrants doing so. I see too many people who decide for whatever reason to load up on a cache of tasks - I'm talking dozens of 'em. Not only do they not complete most of the tasks before the deadline, they haven't even begun work on the vast majority of them. I realize that the thread topic is about TRP-Sieve, but I'm getting the impression that some people would like all deadlines increased over what they are now.

I run zero or close to a zero buffer of downloaded tasks. My machine normally runs 24/7/365 with a typical cable internet connection.

I agree that PrimeGrid should try to accommodate a good cross section of people with different types of hardware, intermittent internet connections, and perhaps limited computer 'on' time. Just don't try to accommodate everyone with the worst case scenario of task crunching.

It's like eating at a restaurant buffet (for us gluttons) - don't take what you can't finish. If you run out of food, come back for more after you've finished eating what you have.

I have the same feeling. I'm in trouble using Primegrid on all my computers as the deadlines are too short. But there may be another problem behind.

I'm running openclPPSsieveMAC on an iMac / AMD GPU / BOINC 7.4.36, and no other project or subproject uses the GPU. My working conditions require a reasonable buffer size (6 to 12 h of work).
Then the deadline is a problem because it receives a lot of openclPPSsieveMAC WUs at each Primegrid download, representing 10 to 12 times the maximum buffer size. There is no problem for cleaning: it's immediate when a WU complete.

Is there anybody able to explain why ?

In my computers, the cleaning is immediate but the execution isn't (due to waiting list and time sharing). I don't bother about deadlines, except when they become critical to empty the waiting list in time. It's already the case for a lot of "short" Primegrid subprojects. A week-end may last up to 110 hours, and running more than 8h/threat or 8h/GPU in each available working day is totally irrealistic in a timesharing environment.