Cant upload the WU in the time allowed.

[Nick200]

Thanks for all the advice.

Going through them:

1. I turn off windows update torrent by default on all the machines so that only local PCs are utilised

2. I will run the speed tests/blufferload on the weekend - and run network diagnostics and report back

3. I will cycle all my PCs by disconnecting them all then reconnecting them one by one to the router - I tried that before though with no effect - but worth another go

4. On possible clashes with updates etc, I have reverted to earlier Win10 versions on all the PCs - mostly by applying a system image from a period when I was not experiencing these connection issues. On one PC there was a failure in doing that - and I had to use diskpart to start from scratch leading to a clean 1511 build install. I don't want to have to do that again in a hurry

In doing so, I lost a lot of WUs - so, a couple of questions for you:

1. If, for whatever reason, FAHcontrol is not managing uploads effectively, it there any other way to upload completed WUs - I know the relevant work server for each WU. I could copy the WU folder to another machine, even using my work network, but I do not know how to force an upload through the command line. Is that even possible? it does strike me as a useful fall back option, though. Is that sort of redundancy something to think about for the next version of the software?

2. Related to that, I have seen one PC clear its backlog and then start accumulating unsent WUs again. So something happened there (but I was not there at the time to check what was going on). If I get a good connection on one machine, is there any way I can transfer the WUs from the affected PCs to that machine and get it to upload them?

I tied transferring a set of WUs to the work folder on one machine - but they were not recognised by FAHcontrol. Presumably some log or ini file would need to transfer as well as the completed WU files. So again, is that possible - and, if it is, what steps would I need to take to do that?

From looking at http://folding.extremeoverclocking.com/ ... =&u=661730, I am down by 500K points a day because of this. That's a fair bit of squandered science.

Naku noa, na

Nick

[Nick200]

Or put more simply an import/export function for completed or in-progress WUs ...?

[bruce]

Questions 1 & 2: No.

FAHClient is designed to work automatically ... and immediately after installation on anybody's (read: any Novice's) computer. Tools for doing the things you're asking about manually are nonexistent. I suppose this is part of a limited effort to prevent hackers from submitting bogus results. [Discouraging / preventing fraudulent methods of earning extra points have been a significant problem for "other" Distributed Computing platforms. Fortunately, it hasn't been a problem for FAH.]

Are you saying that you already know that even a single PC on a dedicated router will fail to upload the local results? If so, is that true whether there are two WUs in queue or only one?

[Nick200]

Thanks, Bruce

No, I don't know that yet as I am leaving it till the weekend to try out your suggested selective approach.

As things stand, though, none of my machines have fewer than two WUs that they are trying to upload ... one has about seven WUs, the others between three and four a piece.

[bruce]

I think that when there are more than 2, it picks two of them to share the upload bandwidth and the others just wait.

The only way I know of to get them to upload one-at-a-time is to delete all but one -- unless they're aimed at different work servers and you use your router to block connections to all but one work server.

[Nick200]

OK, so some progress.

I switched them all off - and then started each up in turn:

One PC promptly completed is uploads and is now chewing through three WUs with no uploads pending.

The second on re-start has three WUs to upload. It has uploaded two WUs with one WU showing the same connection error. I have left it to re-start upload. I'll wait and see how that goes.

The third and fourth machines have pre-empted me, in that when I rebooted them they each failed to load FAHcontrol properly, just showing a blank screen with no slots showing up. I manually started FAHclient to see if that would work, but it just threw up a CMD window and reported that the three slots were not configured. I tried several reboots to see if that would prompt it to load properly - but no.

So for these two machines I tried to save the work folder by renaming it but the uninstall program removed everything. Next time I will move it to a brand new location, do a full uninstall - and then re-save the work folder back to the default location before running the install program. I have a sneaking feeling, though, that that will simply re-create the problem rather than save all the previous work and start uploading it. We shall see... if it happens again, I will report back.

So, I am left wondering whether this means the original installation was in some way flawed and whether that was at the root of my upload problems.

Does anyone have any suggestions about how to repair a FAH installation rather than having to re-install it? As I would rather not lose unsent WUs completely...

So, for tomorrow, I will do some network performance tests - and again will report back.

Naku noa, na / Kind regards, from

Nick

[7im]

There is no fixing a client, because it so rarely breaks. No one has bothered to figure out that very complicated process. It was designed to be super simple to install. But that also made it super complex to break out portions of the client. It was not designed to have work folders saved and restored. Actually has some security against that to prevent malicious code.

In the rare instance a client needs fixing (usually from too much donor tinkering) the solution is uninstall and reinstall.

[bruce]

The installer asks a question about whether you want to save the data or not. (It works as long as the corruption you're trying to fix is not in the data, itself.)

There are a lot of possible pitfalls from trying to save the data yourself, and (as 7im said) the client is more or less designed to prevent you from doing just that ... to say nothing of the EULA.

I've found that in may cases, reinstalling without uninstalling will fix an over-tinkered installation -- particularly when it's the same version.
Obviously if it doesn't fix it, you'll have to uninstall.

[Nick200]

Hi Bruce

Yes, that's what I found. I was finding that not ticking the data box on uninstalling meant that the problem persisted. I just wanted to see whether moving the data, uninstalling, then moving the data back before re-installing would have a different effect - e.g. rebuilding indices etc.

But that aside, something must have happened over night as none of the clients now have outstanding WUs waiting to upload. I wish I knew what had happened to fix this for me. All I did was leave them to run unattended while we slept - and so cannot claim to have had anything to do with the change.

I will keep watch as I have no confidence that the problem will not recur as I have no idea what caused it.

Was there any server-side magic performed over night by the sys admins?

I will do the network performance tests on Sunday...

[bruce]

I can think of two possibilities.

1) Whatever was disrupting the uploads got fixed and they all uploaded.
2) They all were due to expire at about the same time and the client deleted them.

I can check if you give me the PRCG numbers but your logs will also tell you.

[Nick200]

Hi Bruce

Thanks - logs show they all uploaded without being deleted. Which is good. I kook forward to returning to full folding ...

Nick

[Nick200]

Quick update.

Can't now say that the problem has entirely disappeared or been fixed.

Over the weekend, a couple of the machines got stuck with up to 3 WUs each waiting to upload. This happened on both Saturday and Sunday, but on each day the problem disappeared as each machine managed to upload them all by evening.

It looked a couple of times as though I was back to square one - but the problem only persisted for about 6 hours. No clue as to what might have changed in the ether to let them finally gurgle on their way down the pipe to Stanford - but glad they did. I think exiting, killing off the processes and then re-starting FAHcontrol may have helped as he uploads were stalled at one point - and I just re-started the upload process...

[bruce]

I think exiting, killing off the processes and then re-starting FAHcontrol may have helped as he uploads were stalled at one point...

Possibly, but I doubt it.

It's more likely that there was a server problem which somebody fixed. Do you know which server(s) or which project(s) and approximately when?

[Nick200]

Seems to be a regular weekend thing with unsent WUs piling up from Friday night through to Monday.

What I have noticed, though, is that, if I reboot a stuck machine, that can sometimes unblock whatever it is that is holding the WUs back. The stuck WUs then all happily upload alongside each other, often with up to six WUs vying for bandwidth on one machine.

I am on build 14316 - and will feed this issue back to Microsoft through the Insider Hub. To what extent Is Microsoft a FAH supporter/sponsor?

[Nick200]

A follow-up questions,as I have noticed in today's batch of uploads following reboot several instances of:

Code: Select all

06:04:52:WU02:FS00:Server responded GOT_ALREADY (434)
06:04:52:WARNING:WU02:FS00:Server did not like results, dumping
06:04:52:WU02:FS00:Cleaning up

Does that message mean my machine has been working on the same WU pointlessly or that someone else pipped me to the post? Either way it has deprived me of points. What gives?

I can send the full log, but it will probably need editing down as it's likely to be over 60K. Let me know if that will help