and that difference is intended specifically to reward users whose models might fail before completion; this method is computationally onerous and has ultimately resulted in the weekly updates.

I'm not too familiar with the way CPDN operates. But why wouldn't the sensible approach to credits be to only reward successfully completed work units?

That way, in the case of CPDN offering week-long work units, there would be much less bandwidth needed if reporting on a daily basis for only the ones which have been successfully completed.

Also, it raises another question in me. If a user is rewarded for half of a work unit which then fails, and another user receives that unit and completes it, why should both be rewarded for the same work done? That seems to undermine the credits given out altogether.

But why wouldn't the sensible approach to credits be to only reward successfully completed work units?

For some model types it is known that some tasks will go off piste and generate an impossible climate. -ve pressure is one example. At this point the task will crash through no fault of the cruncher or their computer. If this happens after twelve out of thirteen zip files have been returned to the server it hardly seems fair to deprive a cruncher of their credit for this task. In these cases it certainly makes sense to give reward for the work on the tasks that has been completed.

If a user is rewarded for half of a work unit which then fails, and another user receives that unit and completes it, why should both be rewarded for the same work done?

CPDN uses statistical models to look at the data. This reflects the fact that the same task run on two different machines can produce different results. Again to me fairness is the reason. Also many other projects send the same work unit out twice, only granting the credit when the result is confirmed by a second computer.

Ah, that makes sense when you explain it that way. Thanks for the reply.

But why wouldn't the sensible approach to credits be to only reward successfully completed work units?

Awarding credits for patricianly finished tasks started way back more than 10 years ago in the days of the 160 year models. In those days it would take 8 months to a year to complete one model. Asking crunchers to wait that long to see any reward was considered unfair so the trickle system was created whereby a credits were awarded for each trickle sent by the model in progress.

---

Ah, that makes sense when you explain it that way. Thanks for the reply.

I also posted in the Gridcoin forum, that some of the concerns have been already addressed by CPDN - SSL and external stats and some of the limitation when it comes to future demands or the credit system here. However some demands may simply not be met. A wish list by grdcoin might be useful to see whether some balance could be achieved so CPDN stays whitelised in Gridcoin. But CDPN is heavy and valuable project and priority is to keep it running, not meeting other projects demands. My understanding is that Gridcoin values science and gives credit(cryptocoins) for that, not the other way around. I'm available to help to the extend possible for a user of CDPN and Grdcoin - that is why I'm active on Grdicoin forum and IRC trying to clear things up.

Also, it raises another question in me. If a user is rewarded for half of a work unit which then fails, and another user receives that unit and completes it, why should both be rewarded for the same work done? That seems to undermine the credits given out altogether.

Just to be clear, if a task fails at the half way point on one computer, and runs through to success on another, the one that fails at the halfway point will get about half the credits of the one that completed successfully.

Besides the occasional impossible climate scenarios that crash part way through, some of the models are sensitive to anything other than a clean shutdown, and may crash when starting back up. So if you get a sudden power outage that takes the computer down in the middle of a task, there is some non-zero probability that the task will crash at, or soon after startup. Once again, no fault of the person or computer, so the credits given will be based on how many trickles have been uploaded from that task.

I am not sure if it is just my account but access to the tasks pages are now very slow. Is this due to the new database since the upgrade?

Individual task pages seem to load quickly. Clicking on Tasks from <my account> seemed to take a long time but I am in the middle of a GB of data uploading that had been stuck until this morning so not sure if my experience is that relevant.

Here the same. It seems to depend upon the number of tasks, so cleaning up the database would help. My list shows tasks from 2010.

Obviously variable, just now it was a lot quicker than this morning. Don't know if that is because I am not uploading data or because maybe fewer people are accessing the database now than when I looked this morning. Tasks page loaded almost at once this time.

Hi,
when at the task list page I click on the "Show IDs/Show names" under Task Name column the order of tasks lists also changes

Sorry for quoting myself, but this issue seems not to have been resolved. It is still very hard to find latests WUs by names as the order changes somewhat random.

Can it be done like this:
The latest WUs on the first page and the order does not change when playing with "Show IDs/Show names"

Only the last 20 trickles are shown. There used to be a page showing all trickles. Where can I find it?

See my post here, which is in the thread: No trickles on webpage

As an update to that post, as part of the correspondence with the project people, the missing (currently hidden), page is going to be restored.
All part of the fine tuning.

Hi Bernard

I think that I mentioned this before, possibly last year soon after the upgrade started. But, as you say, it's still not right. I've just emailed them again.
It may be on the Still-to-do list, but if not, hopefully it is now. Or in a few hours.

Thank you, I found it.