So I've been pulling my hair out trying to figure out why I've had such issues trying to load the GPUGRID website or communicate with the project via BOINC. it seemed like only one computer could make a connection, and if that computer was running BOINC, all other systems at the house could not load the GPUGRID website, nor communicate via BOINC. in all instances I was able to successfully ping gpugrid.net from any system, so it wasn't a DNS problem.

It's because of 1 and/or 2 things.

1. it seems like on the gpugrid server side, their network is only allowing 1 connection at a time from a single IP address.
2. the 30 second default cooldown after a schedule request is not long enough to release the connection so another computer from the same IP can communicate, so all attempts get blocked.

I have solved my problem using a brute force method to force cooldowns longer than default, to 10 mins. now suddenly all systems can reach the project though the website and BOINC. but if I have just one system using the default 30 second cooldown, it hogs the connection and no one else can communicate.

please make your default cooldown longer and/or allow multiple connections from a single IP address. this wreaks havoc on people running multiple computers from the same location. there's no need to keep pinging for more work every 30 seconds when WUs run for 30min to many hours.

---

This has been the case for many years - I've posted about it before. It's also aggravated by the way that all functions operate on a single server (Grosso). So uploads and downloads also trigger the lockout - I can see another machine trying to download a task while I type this.

The current tasks are actually shorter than has been common at this project, which aggravates, as (obviously) has been the influx of new volunteers from SETI.

Obviously, volunteers with just a single computer won't know what all the fuss is about!

Count me in as afflicted also. Sure would like a solution from the project end.

I only run 4 GPUs on 2 hosts and have had that happen. I wonder if it is a built-in defense against DOS attacks?

That is what we postulated a long time ago.

But it could just be that one lone server doing all functions just can't support the required https connections that the influx of new users has caused and the server loading to increase beyond what was originally configured.

I am not aware of an explicit limit set in the server. It can be anywhere (including ISP throttling). Does it affect the web pages too?

Yes. One computer doing a task operation (upload, report, download) can prevent another computer accessing these message boards. Or reading/writing here can prevent another computer doing task operations.

Edit - perhaps we should say that the problem happens at the 'connect' phase, when our device is attempting to open a TCP/IP connection to Grosso. I'm pretty sure it's something in the server operating system or web server components, long before any of the BOINC software comes into play.

I have solved my problem using a brute force method to force cooldowns longer than default, to 10 mins. now suddenly all systems can reach the project though the website and BOINC. but if I have just one system using the default 30 second cooldown, it hogs the connection and no one else can communicate.
please make your default cooldown longer and/or allow multiple connections from a single IP address.

I can't find any cooldown command in my cc_config. How does one implement this fix???

Should this be set 0 or 1???

<report_results_immediately>1</report_results_immediately>

Should this be set 0 or 1???

<report_results_immediately>1</report_results_immediately>

It should be set to 1 for GPUGrid, but this property is set by the GPUGrid project in the tasks (so this option has no effect on GPUGrid tasks, until it's set by the project).
Look for <report_immediately/> in the client_state.xml and you'll find similar records:

<result>
    <name>2c1dB00_379_1-TONI_MDADex2sc-0-50-RND9291_0</name>
    <final_cpu_time>0.000000</final_cpu_time>
    <final_elapsed_time>0.000000</final_elapsed_time>
    <exit_status>0</exit_status>
    <state>2</state>
    <platform>windows_x86_64</platform>
    <version_num>210</version_num>
    <plan_class>cuda101</plan_class>
    <report_immediately/>
    <wu_name>2c1dB00_379_1-TONI_MDADex2sc-0-50-RND9291</wu_name>
    <report_deadline>1590700376.000000</report_deadline>
    <received_time>1590268377.505087</received_time>
...

I have solved my problem using a brute force method to force cooldowns longer than default, to 10 mins. now suddenly all systems can reach the project though the website and BOINC. but if I have just one system using the default 30 second cooldown, it hogs the connection and no one else can communicate.
please make your default cooldown longer and/or allow multiple connections from a single IP address.

I can't find any cooldown command in my cc_config. How does one implement this fix???

Should this be set 0 or 1???

<report_results_immediately>1</report_results_immediately>

Ian was asking Toni to change the server default to a longer period.

31 seconds is just too often.

Both Ian and myself use a proprietary GPUUG client that offers a configurable cooldown period for any project through a special configuration file. With that we have been able to tame both Milkyway and GPUGrid.

That is not available with the standard client.

You could probably script something to get the job done with boinccmd though. Like project update, wait, disable networking, wait 10mins, Re-enable networking, project update, wait. Something like that. I’d have to look at all the command options available to see if there’s a more elegant solution than this off the cuff guess

---

I've seen a somewhat similar problem where if one of my computers was uploading a GPUGRID output file, my other computer was blocked from sending ANYTHING to the internet, such as a request to view a certain webpage. In my case, persuading my ISP to install a different brand of ADSL modem was what it took to fix this problem.

I'd be curious to find out if this symptom is specific to hardware as in your ADSL modem.

I wonder if everyone who is afflicted is an ADSL subscriber. I'm sure there are plenty of folk over in Europe with fiber connections that are immune to the issue.

Or those on cable modems in fact?

Or those on cable modems in fact?

I am on cable modem, and I havn't noticed this problem so far.

Or those on cable modems in fact?

I am on cable modem, and I havn't noticed this problem so far.

Interesting. I'm assuming you have at least two or your hosts simultaneously crunching GPUGrid and using the same internet connection?

[Edit] The only project website or any website in fact that I have this issue with is GPUGrid.

But I am really curious now if only ADSL modem subscribers have the issue.

@Ian, are you on an ADSL internet connection?

Or those on cable modems in fact?

I am on cable modem, and I havn't noticed this problem so far.

Interesting. I'm assuming you have at least two or your hosts simultaneously crunching GPUGrid and using the same internet connection?

four hosts simultaneously

Are you positive it's not the upload bandwidth being saturated?

Are you positive it's not the upload bandwidth being saturated?

I'm sure about it. I have this problem on my symmetrical 1Gbps fiber optics internet connection. Earlier I had an ADSL (through an old phone line copper wire) with 50Mbps download 15Mbps upload bandwidth, which had the same problem.

...use a proprietary GPUUG client that offers a configurable cooldown period for any project through a special configuration file. That is not available with the standard client.

Ohh, it's an elitist thing :-)

I had many idle computers this morning, all with Download Pending. I clicked Retry All from my BoincTasks Transfers page. Doing that too often seems to make the problem worse. Also, both http & https flavors suffer from this affliction.

My cable modem in the US is an E31N2V1 Hitron Technologies. The spec sheet does not say ADSL:
http://www.hitrontech.com/wp-content/uploads/2020/04/5338868b2233337bd4cb308c048cf211.pdf

Are you positive it's not the upload bandwidth being saturated?

Yes.

1) It's been happening for years, when things were quieter.
2) The hourly project-specified scheduler update is sufficient to block other computers, even when no data needs to be transferred (limit reached or no tasks).
3) Downloads also trigger it.

My connection is hybrid, 'Fibre to the Cabinet' - optical trunk feed, VDSL for the final 500m. I'm getting Downstream 70.619 Mbps, Upstream 12.773 Mbps at the moment - the internet link from the UK doesn't allow me to saturate that.

And yes - I had to take three goes even to get a preview of that post, because one of the machines in the spare bedroom upstairs decided to upload at the critical moment. I wasn't typing fast enough to saturate either your or my upload link!

Edit - now typing from the machine upstairs. It had tried, but failed, to upload (log says 'connect() failed') - so no bandwidth used, except for the attempted handshake. It cleared on the retry, and downloaded a new task as well.