Instructions for coding new clients?

[wheelguy12]

Good suggestions all UF, just not suited to my ancient slow CPU. I have a pair of very fast GPUs, so am limited to the work loads available for those - and, as someone explained earlier - the client has no choice about what work units it receives from the server. Would the PG project benefit with smarter communication between the client and server? I think so, but adding such logic would probably take away more than it would return in terms of benefit to the project since relatively few people would see improved performance.

[uncle fuzzy]

You can't pick your WU, but you have some control by choosing small/normal/big and with or without -advmethods, at least with the CPU. You might try size changes with the GPU to see what you get. It's easy with v6 configuration. You need to add a max_packet_size entry to the slot configuration for v7. I'm just not sure how much the GPU WUs vary in size.

[wheelguy12]

ah - thank you for explaining that. I'll try it when I get home and see how much the estimated complete times increase.

[MtM]

Fuzzy is correct ( if I read him right ), the gpu wu's are all pretty equal in size still and therefore afaik gpu slots/clients do not use the max packet size argument.

[GreyWhiskers]

FWIW, I've looked at some 675 of my recent Nvidia Core 15 WUs, of which about 630 have been P6801.

The download sizes range from 19,218 bytes to 44,106 bytes. The Upload sizes range from 327,193 bytes (can't figure that one out - but the WU completed normally. A one-of-a-kind p6800) to 2,514,498 bytes (typical size of the 630 p6801 WUs).

I don't know how the big/average/small packet sizes work, but all the Nvidia downloads have been tiny - less than 46K. The processing causes the uploads, though, to be much bigger.

If you were queuing up a day's worth of p6801s for each of two GPUs, that could amount to uploading ~55 Mbytes (say, 11 WUs from each GPU at 2.5 Mbytes each). Don't know what kind of strain that would put on your service.

Code: Select all

                              Project  Points   PPD on GTX560ti @ 950 MHz #Atoms   Download size Upload size
Project: 11218 (Run 2, Clone 67, Gen 22   912.0                  19,218.7    264.0      19,217.0 1,073,808.
                                  6801  1,348.0                  14,378.7    634.0      44,106.0 2,514,498.
                                  6800  1,298.0                  13,676.0    627.0      43,171.0  327,193.0  Confirmed U/L size
Project: 11241 (Run 2, Clone 74, Gen 39   912.0                  19,218.7    264.0      19,238.0 1,073,131.
Project: 10943 (Run 1, Clone 68, Gen 13   925.0                  19,028.0    247.0      20,272.0 1,000,848.

[VijayPande]

In general, caching is bad, to the extent that they slow down WU completion, since we need WUs back as fast as possible. It would be best for the project for donors not to cache and that is in part why we have a QRB bonus (you're better off points-wise with QRB running a freshly assigned WU, rather than a cached one).

[wheelguy12]

I understand that caching is bad in general. Just trying to figure out how to handle situations like this where I have regular once a day internet and a couple of fast GPUs.

I set max_packet_size for both GPUs to 100,000,000 - so, we'll see what happens. May be no change at all based on GW's analysis. Once connected, speed is not an issue as I connect to Verizon at 5mbps-15mbps (depending on signal strength).

<edited to add> Looks like GW's conclusion still holds true. At least at present, the work units I am getting with the huge packet size setting have not changed in size.