MM, with 188 PV pages, do a random sampling and click on the WU names to see if the wingman has arrived... no wingman, no validation. Not expecting you to hit the "Try Validation" if it shows when there is a wingman, but then expect it to eventually catch up, no later starting as of a few hours after knreed arrives to the office.

Overloaded... maybe just not enough validators running on HCC [each science has it's own]. Last I read, knreed had added a validator to HCC, so guess there's at least 2 running. At 890,000 results yesterday, it is over 10 per second now. My general observation is that anything I have of Zero redundant, no wingman required, pretty much instantly validates, so as what I said before, think it's FTM confined to HCC if there's backlog.

Pretty much what I thought but I had to ask..
Thanks Sek for the info!

edit: Down to 140 pages now..

The two validators are keeping up. The long pending validation lists are due to wait times for wingman.

We would like to reduce the 7 day return window except that with the end of CFSW and near end of HCMD2, this is our only 'short' project. If we were to reduce the 7 day return window, there will be more users who cannot return any results within the allowed timeframe.

Even thought we want to keep them short, we are going to start putting multiple images into workunits. We are up to 1.3 million results per day and I will get very nervous as we approach 1.5 million results per day. Since we are working on Linux and Mac GPU now and we expect them to contribute a similar boost as Windows, we need to ensure we don't overwhelm the database. Unfortunately, this means pushing the CPU average time out to ~3 hours or so as we put two images into the workunits.

In the longer run we are also looking at ways to handle differently sized workunits within the same application. The goal here would be to put 3-4 images in a file for GPU processing and only 1 for CPU users. However there are some challenges involved in that so that will be awhile before we can implement.

The GPU was set up to do that since we needed to have a backup plan in case the response was immense (which it has been). We are currently rebuilding the CPU version to support multiple images and we will be moving it through alpha/beta testing in the nearish future.

However, this will simply run 1 image all the way through and then run the 2nd image through. We are not able to 'stagger' them so that one is using the GPU while the other is using the 'CPU'. That would be a very significant re-write of the application. This will reduce the number of 'transactions' that occur between client and server and on the database, but it will not further increase the efficiency of application on your computer - that will remain constant.

Knreed, good info and thanks..