Folding Forum

Joe_H wrote:The flag "max-packet-size small" refers to the size of the WU downloaded from the servers, and corresponds to 5 MB in V7. Once processed the results file can be much larger.

Hmm, atleast going by v6.34's description, the packet-size description are:

Acceptable size of work assignment and work result packets (bigger units may have large memory demands) -- 'small' is <5MB, 'normal' is <10MB, and 'big' is >10MB (small/normal/big)

While the limits is possibly different in v7, based on this description the max upload-size with a "small"-setting should be 5 MB.

So, OVV should never have gotten any 28 MB-uploads at all.

Well the V7 description is just the following:

max-packet-size small Configures the slot to get small WUs (~5MB)

In practice, as I have posted, it appears to apply only to the download size of the WU, I have received Project 7808 WU's on my MacBook configured with "small". At that point the WU is just over 1 MB in size. The upload size of the completed WU was definitely much larger at around 20 MB. I have not looked into whether this is considered a "bug" or they found it was difficult to predict the size of the completed WU that would be returned.

As for V6, I do know that the completed WU's I returned were definitely larger than the limit that was set by "normal" or "small". I might still have some old logs on my machine at home since the V6 install did not need to be removed to put on V7.

FYI, just noticed this info on a different thread:

jcoffland wrote:The HTTP_GATEWAY_TIME_OUT and HTTP_BAD_GATEWAY errors indicate that the client was able to communicate the data to the proxy but the proxy lost its connection to the server. It's difficult to tell what's going on here. My best guess is that the proxy is trying to do something that the server doesn't understand. The F@H WS and CS (servers) only understand a very basic HTTP protocol. If the proxy were to use methods not supported by the WS/CS but that were part of the HTTP 1.1/1.0 standard it would fail.