No Tasks?

You can check server status from the "Status" link on the primary navigation bar. Currently it shows that two animations are at 99%. This in 99% of the cases means that we're already waiting for the last WU's to arrive (meaning there's no more work to go around) and once they do, the animation encoding will begin. The use of the farm is somewhat sporadic at times, depending on the artists' need for rendering power.

Why is it that the last two percent seem to always creep by?

It's called "the tail" in desktop grid computing and it usually has to do with the last WU's having been passed to computers that are either offline or not on at all. We do try to "burst out" some extra WU's towards the end of a session (the tail indeed used to be even longer a couple of years ago when Renderfarm.fi started), but this phenomenon is extremely difficult to avoid completely.

Well, I'm seeing some ultra slow atoms pass by which only have tasks which end with: cancelled by server. These kind of computers slow the project down by a lot.

I've been curious if multi-threading has affected the tail of sessions.

Not complaining at all. Multithreading is the bomb. Over time I've seen much improvement with in "the tail" and single threading, but have noticed that new sessions seem to take longer to finish than they used to.

Of course I don't have any objective proof, it just "feels" that way. Has anyone noticed that the last few workunits seem to take longer than the old single core sessions? Maybe the algorithm needs adjustment(?).

Maybe the last WU's should be edited manually by the admin to release them to a new volunteer when it's not uploaded within a few hours. 

A new feature what might improve the tailtime: from all the WU's done in a project, take the average time for each WU to finish and multiply that by 2, or 1.5. If a client exceeds that time (average x 1.5/2/2.5/or something else) the last WU's are send to new volunteers. This new deadline might be send out after the overall process has reached 85%/90%. 

Deadlines are mostly too far ahead, while some units take 60 seconds deadlines are multiple hours. I know that's hard to inplement because each unit is different, still I think deadline times can be decreased by 20%. Slower clients might suffer from the shorter deadlines, I believe that single core clients might not be up to the task anymore...

Hmm, session-based deadlines. I like that idea. I'll write to Janus about it. There is some functionality in the system for avoiding the last workunit stalling, but it doesn't appear to work too well yet.

Oh, also: There is a new bug in the system which has occasionally required me to go manually tweak the session. Something with .zips corrupting. This has at times caused a delay as it has taken a while for us to notice the problem.

I also want to know what these files are that keep failing,

Here is the boinc image, http://www.flickr.com/photos/67415315@N03/6194371905/in/photostream/

Please help

Hm, so there are some problems in downloading? Those are:

1. Windows zip binary that packs the png

2. Windows unzip binary that unpacks the rendering client

3. A middleware program that handles the connection between BOINC and Blender

What firewall are you using, and have you configured it allow BOINC through? Are you participating in other BOINC projects, and do they work? I'm also seeing some odd behaviour in your computer's task list. It seems as if your BOINC keeps detaching and re-attaching to the project.