Let's suppose this could be made possible in a simple way. Let's have a look at the files in one ARP1-task.

There are typically 11 files in a task that is sent to a client.
One filename ending in ".input", 1,785 bytes.
Three filenames ending in ".", all three files having a size of 659,852 bytes.
Three filenames ending in ".7z", all three files varying in size between ± 14 - 21 MB.
Three filenames ending in "d01", "d02" and "d03", all three files having a size of 12,485,444 bytes (± 12 MB).
One more filename ending in ".", this file having a size of 49,385,088 bytes (± 49 MB).

The filenames ending in "." aren't compressed, they contain raw NetCDF Data Format data. They are either small (659,852 bytes) or large (49 MB). My guess is that it is too 'expensive' on resources to compress the larger one and 'a waste of time' to compress the small ones, including the file with its name ending in ".input", of course.
The files with their names ending in ".7z" are already compressed (LZMA); uncompressed, two of them are sized 87,327,860 bytes and the third one comprises 92,575,412 bytes. They contain, all three, raw NetCDF Data Format data, too.
Finally, the files with their names ending in "d01", "d02" and "d03" also contain raw NetCDF Data Format data.
(BTW, compressing the larger one of 49 MB could be an option, I don't understand why this wasn't done in the IBM days. It would take up ± 12 MB.)

So, before compressing, the server has, in bytes:

       1785 (1 file, filename ending in ".input")
    1979556 (3 files, filename ending in ".", sized 659852)
  174655720 (2 files, filename ending in ".7z", sized 87327860)
   92575412 (1 file, filename ending in ".7z")
   37456332 (3 files, filenames ending in "d01", "d02" and "d03", sized 12485444)
   49385088 (1 file, filename ending in ".")
  ---------
  356053893 total ≈ 356 MB

Since the server already compresses the large files, aside from the 49 MB file, there's no need for the server to compress the 11 files even further before creating the task that will be sent to a client.

Then the server would need to combine the already compressed files and the smaller files - and optionally compress the 49 MB file - which could then take up one huge download of ± 102 MB. (The fixed sizes are 1,785 + 3 * 659,852 + 3 * 12,485,444; the other sizes are 3 * approx. 14-20 MB (averaging a total of 50 MB) + approx. 12 MB.)

That's it, one large bundle with 11 files in it, some of them already compressed, others too small to make the effort, saving milliseconds of server time.

Adri

Thank you to both adriverhoef and ericinboston for the insights and analysis. This does answer some questions and still leaves some questions on the table. I feel there is a better way for these work units to be sent but I am sure the developers have their reasons. But, things could still change/improve!

Well, one point that Adri has been missing is that putting several files into a single .ZIP/.7z file doesn't mean that they need to be compressed/decompressed, again. After all, these kind of files are referred to as "Archive" files and it is quite common to use such archives for the last +40 years to combine files for a single download, going back to the days of dialup BBSs...

However, I am pretty sure that there is a reason why the developer of the ARP1 application (after all, it is THEIR project, not WCG/Krembil's) have chosen to supply multiple, partially compressed .7z files, partially apparently uncompressed .txt files, probably depending on how that source data is generated and processed. It would require a lot of additional work for WCG to change the upload (server side)/download (client side) process to handle the combining the files before upload and extracting after download, fitting in the standard BOINC procedures.

Yes, it is a pain where the sun doesn't shine, but people in general shouldn't be so greedy and just try to grab what ever they can with no regards to the system over all. It seems that the "community" part in World Community Grid doesn't ring a bell in a lot of folks mind...

Ralf

And after everything we are going through, do you want Krembil making changes to anything?

I say we want them to make changes, if changes are not made for example new projects cannot be added or existing projects that currently have no work can't have work sent out when it becomes available