work units not sending. Also, idle not working properly

[bruce]

I can't talk you through the router settings, but we did have a report (maybe about Dec '13) that there was an advanced feature --- manybe called something like "smart filtering" or "stateful analysis" or something that defaulted to enabled but you could turn it off (i.e.-set it to "normal") and the problem went away.

The Server sends a confirmation message which gets discarded by the router. I think it looks like a redundant message or maybe it violates some protocol or maybe it's an empty message. I can't find the earlier report right now.

[Volnaiskra]

That sounds promising, bruce. Do you think it could be one of these?

NAT Filtering
SIP ALG
port forwarding
port triggering

[bruce]

port forwarding and port triggering are probably disable and they're NOT it.

I'm not sure about the other two. Are either/both turned off?

[P5-133XL]

NAT filtering, if on, could be a cause of incoming blocked packets from folding servers.

This option determines how the router deals with inbound traffic. The Secured option provides a secured firewall to protect the PCs on LAN from attacks from the Internet, but it may cause some Internet games, point-to-point applications, or multimedia applications not to work. The Open option, on the other hand, provides a much less secured firewall, while it allows almost all Internet applications to work.

SIP ALG:

SIP ALG is an application level gateway (proxy server specific for voice over IP (VOIP)) designed to better deal with VOIP control signals (SIP) getting through the routers NAT and firewall. If you are not using VOIP disable. On or off, It shouldn't cause any problem for non-VOIP traffic.

[Volnaiskra]

ok, I've set NAT to "open". Exciting - this seems promising!


I'll report back.

[Volnaiskra]

I was so hopeful, but setting NAT filtering to open didn't do it. I already have 2 'unsent' WUs. I don't need to also disable NAT (Network Address Translation), do I?

I'm trying SIP ALG now

[P5-133XL]

No, NAT translation shouldn't be a problem.

Are you connecting to your computers wirelessly? Is Wireless turned on but unsecured?
Do you have someone on your network using Bittorrent or another P2P application?
Have you configured QoS on your router.

[Volnaiskra]

Both PCs connect using cat cable (main PC uses cat6e). Other devices such as my wife's laptop, which is also folding, connect via wifi. All to the same router

No one here uses torrent or p2p. I leave Steam running, which sometimes downloads game updates.

No, I haven't set up QoS. Should I? These are my current settings:

[P5-133XL]

Steam is not a problem. At this point, I would not turn on QoS for it would complicate things but if there is a maxed out connection then it is worth turning on. Configuring QoS can be difficult to do well.

Is the Wifi secured? I'm speculating but wondering if something is using all the bandwidth (which is why I asked about P2P), preventing reliable communication by folding. One possibility is that, unbeknownst to you, someone else is using your WiFi connection and stealing large amounts of BW. Check to see if there are more machines connected to your router than you know of. Many routers also have the ability to keep track of how much data is going through them each month...

If you are using cable then you should be able to contact your ISP support and have them run a check for a bad line. They will be able to notice is there is too great of a power drop or if there is excessive noise from their equipment to your cable modem.

[Volnaiskra]

SIP ALG is not it either - I have two more 'unsent' WUs since disabling it.

Yes, the wifi is secured with WPA2-PSK [AES]. I can see 3 devices connected via cable (2 PCs and a Tivo), and 3 to wifi, which would be 2 android phones and my nvidia Shield (if the laptop were turned on, it'd be 4).

I don't imagine that it's the internet connection. Everything else is fine. I rarely get dropouts or anything like that. If video streaming etc. can manage fine, then surely a little "WU upload completed" message shouldn't have too many problems, right?

I mean, sure, we sometimes max out the bandwidth here. If, say, my wife is watching a video, and I'm downloading steam. Or, as was the case overnight, Adobe Creative Cloud is downloading several applications. But surely FAH is supposed to work in an environment where people are using their internet normally.

The annoying this is that none of this would be a problem if FAH didn't get so confused by it. The science is being done, and the points are being awarded. If only FAH could deal with these unconfirmed uploads in a better way (eg. restart the upload process or confirmation query, and/or ignore them completely after x days), rather than freaking out and downright breaking once there are too many of them, then I could just ignore this issue and move on with my life.

[P5-133XL]

I don't have any answers. Wish I did. Very few people have the connection reliability issues you seem to have on a constant basis. So I speculate and ask questions to see if I can figure out why you are different. So far, I obviously haven't asked the right question, yet.

[bruce]

The last time we had a similar report was a long time ago. Eventually somebody with the problem was able to do a packet trace on the last part of an upload and it was turned over to one of the developers for analysis. The fundamental question is whether the "Acknowledging WU Received" packet from the Server to the Client is being corrupted or dropped entirely somewhere ... and if so, where.

[Volnaiskra]

Is there some way I can do a packet trace?

[Volnaiskra]

My 'unsent' cores stacked up again, resulting in FAH greying out and locking. I forcibly closed it, deleted all of the work folders, restarted PC, and it's right as rain again. Since there doesn't seem to be any known solution to my problem, I guess I'll just get in the habit of purging the work folders from time to time. But thanks for all your help, guys.

But I'd also like to report this as a bug. Because regardless what's causing the "acknowledging WU received" packets to be lost, I'm sure FAH could deal with such situations better, rather than getting confused and breaking down each time. I'm no software developer, but surely one or more of the following methods could feasibly prevent these situations becoming so problematic:

1. if there's some sort of limit to how many WUs FAH can handle at one time before bugging out, then raise the limit
2. Periodically check for WUs that have been 99%+ sending for more than several days. When found, restart the upload process
3. Periodically check for WUs that have been 99%+ sending for more than a several days. When found, check against the database to see whether they were actually accepted
4. Periodically check for WUs that have been 99%+ sending for more than a week or so. When found, move them into some sort of quarantine area where they won't conflict with regular FAH operations
5. Periodically check for WUs that have been 99%+ sending for more than a week or so. When found, treat them as losses and delete their work files.

Is there somewhere I can post this as a bug/feature request? Or could one of you guys do it for me?

[PantherX]

By chance, do you remember how many WUs you had in your queue before it greys out? Is it the same number always?

1) Assuming that the number of WUs in your queue is causing the issue, you could change this setting:

Code: Select all

  max-queue <integer=16>
    Maximum units per slot in the work queue.

2) AFAIK, if the acknowledgement isn't received, it will automatically attempt to upload next time. Does this not happen in your case?

3) Not going to happen since the database can only be accessed by Administrators and Moderators. By make it available to the Public, it creates additional load which is undesired.

4) This is already present to a certain extent. If the WU is still present and the expiration deadline is reached, it is deleted from the queue. You just have to wait long enough for the WU to expire.

5) Not going to happen since the only time a finished WU is deleted is when the expiration deadline has been reached. Not before that since occasionally, a Server may go offline so the WUs are kept until the Server comes back online and the WUs are sent successfully. This creates a "buffer" to allow time for unforeseen circumstances to be dealt with.

Regarding the suggestions, you can post them here. However, please do read this post (viewtopic.php?f=24&t=25609) which states how the suggestion(s) would be evaluated.