problems with p2681/p2682/p2683 [sneakernetting issues]

[matheusber]

hail,

I know these WU have specific room, but I'd like to bring a question here and if people from PG could answer me, better.

I have problems, since I first begun folding bigadv WU's to upload results (proxy problems, never ever got to figure it out). So always had to get the files somewhere to send them. For a short time they got to upload fine, and every now and then it does. but this is the great minority part.

So sometimes I send results, get nothing in credits and go there (bigadv room) to ask for info. Sometimes I just see "lost", sometimes it gets ok, and sometimes I get people saying I'm cheating and trying to send twice or more the same WU. for the record, regular SMP WU's also makes me have to move the files to other places, although I can download anything no problem at all.

as for trying to solve, ok. problems on this I can handle. but to be called cheater is no good, and that's why I'm here for. What's all wrong about moving files somewhere else to upload ? I keep all needed files there, and just touch client.cfg to not use proxy anymore. and that's it. Could someone from PG or the like say what can I do to manage this. I have clients on dsl lines and are fine, SMP do all right. just my best site is not uploading ok, and I just don't want to give it up. but if this is seen as such a bad thing, all I can say I can do is drop the clients and stop folding.

this is not a complaint in any sense, I'm just trying to see what can I do before realizing I can't go on. To loose one once in a while is ok, but it this gets to frequent there is no point in using resources to loose work. If there is no way to solve, I'll just be quiet about it and not bother anyone in here.

thanks,

matheus

[7im]

I think you misunderstood what they posted. You were not called a cheater! What they said is that Pande Group has added extra security measures to help prevent cheating, and those extra security measures are making it harder to sneakernet work units.

Going forward, to be sure your sneakernet work units are credited, you must upload a completed work unit using the same User ID and System ID for which the work unit was downloaded. IIRC, the sneakernet wiki entry was updated to reflect this added security.

I'll let other people address any other questions not yet answered.

[jcoffland]

matheusber: Sorry you are having trouble.

We are working on a new client and security system which will help with this problem. We have to make sure that units are returned only by the the client we issued them to. It wouldn't be good if someone could complete a unit than hand out the results to everyone in their team. The new client will have a more portable ID that you can move around as you please.

Currently, there is an assignment ID stored in your registry or in machinedependent.dat if you are running Linux. If that does not get copied to the machine returning the unit the new servers will reject your results since they don't match the assignment ID the unit was issued to. This Wiki page discusses it: http://fahwiki.net/index.php/Sneakernetting.

[kasson]

Folding@Home has security features to protect both the integrity of the points system and the integrity of the scientific results.
One could categorize uses of Folding@Home as follows:
1. Supported configurations used in a good-faith manner. We do our best to support these.
2. Unsupported configurations used in a good-faith manner. While we are very happy if you can use an alternate configuration to donate to Folding@Home (as long as it doesn't violate the EULA or the integrity of the science or the points system), we are unable to support these configurations. Furthermore, we are unable to guarantee that configurations which work now will continue to work under future upgrades. We're not malicious, but if a configuration isn't in our specifications, we usually don't design for it. A number of users have produced how-to's that can provide some assistance. It sounds like this is the category that your problem falls into.
3. Unsupported configurations used in a manner that can damage our scientific results or the points system. This is what our security features are designed to catch.
4. Supported configurations used in a manner that damages our points system or the scientific results. We adjust our system to deal with these.

Unfortunately, we are unable to provide support for the sneakernetting configuration that you are using. You have posted about this elsewhere, and a number of users have provided feedback. We regret that posting in the specific WU forum won't help. These are issues with the configuration you're running under rather than the work units or servers involved. Sorry.

[matheusber]

jcoffland: is good to hear that there is work in progress on this. And I here say I can test it, if I may. but I do all things as said for sneakernetting. all I change is use proxy from yes to no. all other files are packed in a tar.gz and go along to where the work is then uploaded. machinedependent.dat is there for sure.

kasson: I do thank you for your time here to explain. but although I'm now in #2, I'd like to be in #1. I posted here problem using the machines and my proxy. If I try to upload using it, I always get an error message (502, 503, server doesn't have record of this wu) and this made me be in #2.

just lost another wu:

Code: Select all

[18:42:32] + Attempting to send results [December 19 18:42:32 UTC]
[18:42:32] - Reading file work/wuresults_06.dat from core
[18:42:32]   (Read 99095207 bytes from disk)
[18:42:32] Connecting to http://171.67.108.22:8080/
[02:31:07] Posted data.
[02:31:08] Initial: 0000; - Uploaded at ~3 kB/s
[02:31:08] - Averaged speed for that direction ~58 kB/s
[02:31:08] + Results successfully sent
[02:31:08] Thank you for your contribution to Folding@Home.
[02:31:08] + Number of Units Completed: 24

[02:31:15] + Sent 1 of 1 completed units to the server
[02:31:15] ***** Got a SIGTERM signal (15)
[02:31:15] Killing all core threads

this got zero also.

what can I do to make my proxy upload ? I can't think of anything as I get to send wu's as big as 2673 (about 100MB) and these bigadv can't. I just have problems uploading bigadv ones. so is really my proxy who is faulty ?

thanks again for your input. from all of you ...

matheus

ps: just to make sure all bigadv clients hare different machinedependent.dat, I just run md5sum on this file for all 4 clients I have, and all are different.

[bruce]

How can you be sure whether you're having a sneakernetting issue or a proxy issue or a duplicate WU problem? Can you eliminate one of those items from an upload and see if it works . . . then eliminate the another one and make sure one option works and the others do not. It would be a lot easier to help you if we knew the real nature of your problem.

[matheusber]

How can you be sure whether you're having a sneakernetting issue or a proxy issue or a duplicate WU problem? Can you eliminate one of those items from an upload and see if it works . . . then eliminate the another one and make sure one option works and the others do not. It would be a lot easier to help you if we knew the real nature of your problem.

Hi bruce, I sneakernet because the proxy doesn't work. My attempts using the proxy and in the machines running the WU itself. They try as soon as the WU finishes, and as in 99% of times it fails I move to other machine to send using a slower connection.

if anymore ideas you have I can make sure I can try them all

thanks,

matheus