In our previous batch of workunits, volunteers reported download speeds ranging from 14kB/s to 100kB/s when pulling down work from our servers. We've since updated our distribution system so individual workunits will be orders of magnitudes smaller, and thus download speeds should be greatly increased. If you volunteer your computer for the current batch of workunits and are still experiencing problems, please let us know and we will diagnose the issue further.

Also, the initial workunit may take longer than usual to download since we have a new application version to distribute, but all subsequent downloads should be much quicker.

My downloads are 4k just like in May.

I do appreciate the effort, though.

That is unfortunate. However, since most workunits will be less than 100kB in size (as opposed to 10MB) you should notice that you are able to download more workunits per hour and contribute more to the project.

As mentioned in the initial post, the application files are still about the same size (500kB-35MB), but those will only be downloaded as often as we release a new application.

(EDIT: application file sizes)

I'm now downloading for more han 3 hours for the 1st wu and still have more than 17MB to go. (actual file sbd_1.41_windows_intelx86.core has 29,86MB, the size of the other files you'll know are much more than the mentioned 1MB)

[duplicate post deleted]

Can the number of tasks in process for a host be increased from the current setting of 1?
____________
Reno, NV
Team: SETI.USA

I apologize that the application files are still taking a long time to download. We've addressed the issue for individual workunits, but we'll need to look at more systemic causes for why our servers cannot handle large downloads volumes. This should only be a concern when we push out new application versions, but it's enough of a bottleneck that we will continue to devote our time and energy to resolving the issue.

Also, zombie67, I've removed the limit on the max number of workunits in progress.

Thanks!

Edit: Out of work already? More to come?
____________
Reno, NV
Team: SETI.USA

It will probably be at least several weeks before a significant number of workunits are generated, but there may be some occasional small jobs in between.

i suggest you pack it all together using 7z http://www.7-zip.org/ :



7-Zip 4.65 Copyright (c) 1999-2009 Igor Pavlov 2009-02-03

Listing archive: sbcl_1.41

Method = LZMA
Solid = -
Blocks = 1
Physical Size = 5958480
Headers Size = 164

Date Time Attr Size Compressed Name
------------------- ----- ------------ ------------ ------------------------
2011-06-29 17:41:15 ....A 31313944 5958316 sbcl_1.41_windows_intelx86
core

ports are available for MAC-OSX, several linux branches, AIX, Solaris...

just in case anyone not happy - source-code is available too!


could save a LOT of bandwith for all of us..

It will probably be at least several weeks before a significant number of workunits are generated, but there may be some occasional small jobs in between.

Yesterday I got one single wu, runtime less than 20 minutes, but download time overall was much more than 4 hours. Maybe you should give credits per download time instead of calculation time, I would have gotten more than the 7cr for this wu. I hope, next time no new application is needed.

Decreasing the size of the files we distribute is a great way to tackle the issue (especially given the compression ratio for the sbcl core!), but we also need to troubleshoot the core factor that's limiting our transfer speeds. This will allow us to better scale the system in the future.

As for batch sizes, I consider anything less than 100,000 workunits to be fairly small for any type of grid resource, but that ultimately depends on how long each workunit runs. To answer your question directly 7ri9991, most of our recent batches have been insignificant in size.

And finally, I (strongly) don't perceive that the next round of workunits will require an update to our application, but I can't say definitively.