Folding Forum

statesidecoma wrote:No moving form one machine to another. NO CHANGING ANYTHING. . .

According to the Pande Group, you downloaded that WU with one passkey and uploaded it with another.

PantherX wrote:By Force I can understated -send all flag. However, I don't know how one can recover a wuresult_XX.dat file once it has been deleted by the F@H Client.

You can't.

The wuresult_xx.dat file is created after a WU reaches 100% (combining several files into one in preparation for the upload). The client keeps that file with a pointer to it in queue.dat until the server confirms that the upload has been successful. (In this case, the bug that Kasson mentioned caused the WU to not be recorded even though the server told the client that it was.) Even if you managed to restore it and somehow managed to upload it, it will be treated as a duplicate. The server knows that the WU is no longer assigned to you, even if no stats information was posted.

bruce wrote:

statesidecoma wrote:No moving form one machine to another. NO CHANGING ANYTHING. . .

According to the Pande Group, you downloaded that WU with one passkey and uploaded it with another.

I am here to tell you that it came down on ONE damn computer. There is NO sneakernetting going on. I AM JUST TRYING TO HELP GET PROBLEM SOLVED. This is common to blame the donor and try to make crap up. Just forget it.

bruce wrote:The wuresult_xx.dat file is created after a WU reaches 100% (combining several files into one in preparation for the upload). The client keeps that file with a pointer to it in queue.dat until the server confirms that the upload has been successful. (In this case, the bug that Kasson mentioned caused the WU to not be recorded even though the server told the client that it was.) Even if you managed to restore it and somehow managed to upload it, it will be treated as a duplicate. The server knows that the WU is no longer assigned to you, even if no stats information was posted.

[[Polite mode ON]]
I think that PG should go thru thier logs and recredit us for the work we did. It's not my fault their computer did not record the work we did. Apologies are nice, but not quite enough.
[[Polite mode OFF, normal mode back ON]]

According to this:

Important: The bonus scheme is based on the time that returned work units are received by our servers. We make every effort to keep these servers available to receive work, but there will inevitably be congestion or downtimes. We do not guarantee server availability. If for some reason you do not receive the expected bonus please do let us know, but unlike base points, we will generally not give recredits for bonuses. Bonuses are not guaranteed. Similar policies apply for unexpected loss of work units, etc. The bonus program has some "slack" calculated in to allow for such unexpected events.

Source

There might not be much hope of recredits, however, I think that it would be nice if base points were at least given to those who did return the P2682 WUs.

PantherX wrote:According to this:

Important: The bonus scheme is based on the time that returned work units are received by our servers. We make every effort to keep these servers available to receive work, but there will inevitably be congestion or downtimes. We do not guarantee server availability. If for some reason you do not receive the expected bonus please do let us know, but unlike base points, we will generally not give recredits for bonuses. Bonuses are not guaranteed. Similar policies apply for unexpected loss of work units, etc. The bonus program has some "slack" calculated in to allow for such unexpected events.

Source

There might not be much hope of recredits, however, I think that it would be nice if base points were at least given to those who did return the P2682 WUs.

And if you read the rest of the post there is this.

Q: What if internet problems - or Stanford server problems - delay the return of my work unit?
A: Your bonus points would be reduced accordingly, as would your reliability factor if the delay pushed the WU past the timeout. These are risks you must accept when electing to fold these units. We strive to maintain a server environment that is as robust as possible, but the 80% cutoff for reliability factor is intended to allow leeway for network-connection, Stanford server, and work unit problems.

I think it is pretty well stated there I do not expect to be credited for the 2682 I lost. I did read the entire post before I started folding bigadv WU's and new there were risk's involved and it has actually been a pretty sure bet, I really can't remember loosing any previous bigadv WU's due to issues with the server. Any previous issues the server had received the completed WU and recorded it. This time Stanford has no record of it or it's results so it is useless to them. Do I think it is a good policy, not really, but Stanford really has no way to verify you actually ran it. And before anyone says well I have a log of it, I will have to say so do I but anybody can create a log.

@Grandpa_01,
Anyone can have a log, but if you were lucky enough to have a recent backup, you also have the work unit itself to send in to prove you did the work. I was looking at one of your previous posts here and I noticed that you run SMP as a service. I was curious as to how you ran the service with the -send flag? And for everyone else, does the send flag work as expected when called by a service?

BTW, I wasn't one of the unlucky ones, but I think I would feel the same way as Mactin. Although I understand the complexities involved on Stanford's end in trying to right it, it is still one of those things that just makes you say !&$%#@!#@#@ <insert favorite curse here>

GeneralRavel wrote:@Grandpa_01,
I was looking at one of your previous posts here and I noticed that you run SMP as a service. I was curious as to how you ran the service with the -send flag? And for everyone else, does the send flag work as expected when called by a service?

:

No I was not able to get the - send flag to work. And even if I could have it would not have done any good. The file was sent to Stanford when it was sent the first time, and Stanford acknowledged they had received it in the log I posted in my first post in this thread. But If I am understanding it correctly the Stanford servers did not keep a record of it.

[02:34:10] Folding@home Core Shutdown: FINISHED_UNIT
[02:34:13] CoreStatus = 64 (100)
[02:34:13] Sending work to server
[02:34:13] Project: 2682 (Run 8, Clone 2, Gen 18)


[02:34:13] + Attempting to send results [August 11 02:34:13 UTC]
[02:40:02] + Results successfully sent[02:40:02] Thank you for your contribution to Folding@Home.
[02:40:02] + Number of Units Completed: 146

[02:40:09] - Preparing to get new work unit...
[02:40:09] Cleaning up work directory

Did qfix find some result file left to rebuild the queue for upload ?

toTOW wrote:Did qfix find some result file left to rebuild the queue for upload ?

when I attempted to run the -send flag it would not work, I would get a Windows promp mesage that fah6.exe had stoped working properley and had shut down. The flags I tried were -send, -send all, -send 9 all got the same Windows prompt.

I'm talking about this procedure : viewtopic.php?f=19&t=6042 ...

toTOW wrote:I'm talking about this procedure : viewtopic.php?f=19&t=6042 ...

I did not do that procedure. By the way I can not get the download link for qfx in the link you provided to work. The only file left in the work folder is wudata_04_prev it is a cpt file and is 27,583kb in size. So I am assuming everything else was deleted when fah received the Thank you message from Stanford.

Grandpa_01 wrote:No I was not able to get the - send flag to work.

Come on, folks. We've said it many times and in many places. The -send flag is virtually a useless option. If you restart the client, it performs the exact same uploading procedures, which may or may not work for exactly the same reason. The only advantage of the -send flag is that it will NOT resume work processing a WU. A simple restart will either resume work on the current WU or download a new one, while simultaneously doing a -send all.

And even if I could have it would not have done any good. The file was sent to Stanford when it was sent the first time, and Stanford acknowledged they had received it in the log I posted in my first post in this thread. But If I am understanding it correctly the Stanford servers did not keep a record of it.

That's what I understand, too. In any case, when the WU was uploaded, any record of it being assigned to you was destroyed, so uploading it again would have failed, even if you could recover a copy of it that could be re-uploaded. As far as the server is concerned, if somehow I had a copy of your finished WU and I tried to upload it, the server would discover the same thing -- there was no record of it being currently assigned to me so it would be rejected. The same would be true for you, once it had been uploaded the first time.

I'm sorry, but I believe that if PG should be manually giving credit in this case given that they know the server choked and the person is supplying a log showing that it completed. It is not the individual's fault here!

P5-133XL wrote:I'm sorry, but I believe that if PG should be manually giving credit in this case given that they know the server choked and the person is supplying a log showing that it completed. It is not the individual's fault here!

I have 20 fake fahlog's showing completions (typed up in notepad) from last week. Where can I send them to get credit?

Sorry, no safe way to verify the results. And as mentioned above, the bonus system has a little slack built in, so an occasional server outage is already built in to the points benchmark. You already got the points.