Delay for Send / Download

[Adriaan]

When my PC finishes a WU whilst NOT connected to Internet, the FAHControl shows a line with status "Send" and a line with "Download" for the new WU.
After reconnecting to the Internet, it remains uinchanged that way for useless hours !
Any remedy or work-around ?

Thanks,

Adriaan

[P5-133XL]

If you stop the client and restart it, it will do an immediate send all and download a new WU immediately (if necessary). Is that useful?

[7im]

Seems like a bug to me. Is there a ticket on this?

[P5-133XL]

To my knowledge it works just like v6. It tries to send/receive fails; waits, trays again, fails and waits longer, ... Eventually it will be hours between attempts. It is faster once you get beyond a few minutes, just to restart the client back up once you've fixed the network connectivity issue

[bruce]

It's not a bug; it's the way the FAH client is designed.

Suppose a server goes down or there's a more major interruption in the connectivity between hundreds of thousands of FAH Clients and the servers. As time passes, more an more clients finish their work and acquire a status similar to yours. If the instant that connectivity is restored, EVERYBODY tries to connect, the server would instantly be overloaded and all communications would fail. The client is designed to protect the server from that sort of overload by retrying the connections periodically in increasing intervals (known as exponential back-off) allowing the backlog to be processed over a reasonable period of time.

If the backlog is small, everyone will be connected at various times. If the backlog is huge, the server may still be saturated for a period of time. If you notice the problem and restart the slot(s), communications will resume unless the server happens to already be backlogged. Many clients will be running unattended, and they will all retry automatically until a connection can be made, but hopefully at intervals which will protect the server from being overloaded for an extended period of time.

[GreyWhiskers]

If you stop the client and restart it, it will do an immediate send all and download a new WU immediately (if necessary). Is that useful?

Easiest way for me to do that with v7 if there is an internet glitch for some reason is to PAUSE either all slots on a machine or just the one that is waiting for service then FOLD. It happens enough for me that I've gotten adept at kickstarting a stalled upload/download.

[7im]

It's not a bug; it's the way the FAH client is designed.

Suppose a server goes down or there's a more major interruption in the connectivity between hundreds of thousands of FAH Clients and the servers. As time passes, more an more clients finish their work and acquire a status similar to yours. If the instant that connectivity is restored, EVERYBODY tries to connect, the server would instantly be overloaded and all communications would fail. The client is designed to protect the server from that sort of overload by retrying the connections periodically in increasing intervals (known as exponential back-off) allowing the backlog to be processed over a reasonable period of time.

If the backlog is small, everyone will be connected at various times. If the backlog is huge, the server may still be saturated for a period of time. If you notice the problem and restart the slot(s), communications will resume unless the server happens to already be backlogged. Many clients will be running unattended, and they will all retry automatically until a connection can be made, but hopefully at intervals which will protect the server from being overloaded for an extended period of time.

You have personal experience the client will eventually resume normally?

[P5-133XL]

If you stop the client and restart it, it will do an immediate send all and download a new WU immediately (if necessary). Is that useful?

Easiest way for me to do that with v7 if there is an internet glitch for some reason is to PAUSE either all slots on a machine or just the one that is waiting for service then FOLD. It happens enough for me that I've gotten adept at kickstarting a stalled upload/download.

You're right, that is a more convienient way of kick starting the client.

[bruce]

It's not a bug; it's the way the FAH client is designed.

Suppose a server goes down or there's a more major interruption in the connectivity between hundreds of thousands of FAH Clients and the servers. As time passes, more an more clients finish their work and acquire a status similar to yours. If the instant that connectivity is restored, EVERYBODY tries to connect, the server would instantly be overloaded and all communications would fail. The client is designed to protect the server from that sort of overload by retrying the connections periodically in increasing intervals (known as exponential back-off) allowing the backlog to be processed over a reasonable period of time.

If the backlog is small, everyone will be connected at various times. If the backlog is huge, the server may still be saturated for a period of time. If you notice the problem and restart the slot(s), communications will resume unless the server happens to already be backlogged. Many clients will be running unattended, and they will all retry automatically until a connection can be made, but hopefully at intervals which will protect the server from being overloaded for an extended period of time.

You have personal experience the client will eventually resume normally?

There are two answers to that.
1) If the client is unable to contact the server(s) to upload and/or download, it will automatically retry at varying intervals.
2) If the client does contact the server(s) and starts the upload and/or download, there's a bug report (Ticket #911) to fix FAHClient because it does not resume automatically.

[k1wi]

FYI you should be able to find the delay until the next attempt by telneting into your client and sending the 'queue-info' command:

Code: Select all

  {
    "id": "02",
    "state": "RUNNING",
    "error": "OK",
    .........snip.........
    "waitingon": "",
    "attempts": 0,
    "nextattempt": "0.00 secs",
    .........snip .........
}
]

I am sure you could easily set a simple script to test a) whether your queue has waiting WUs b) whether the delay is greater than a set amount and b) whether your internet connection has returned (simple ping to an external site[s]).

[k1wi]

See here for a Linux based script, may work in OSX but I haven't tried it. viewtopic.php?p=230964#p230964