LHC@home

Today, my transfer queue is full with attempts to upload the results from several work units. Some are partial uploads, some haven't started. When I've manually restarted the transfers, the transfer speed is about 10-200kbps. I have a 1G fibre connection, so the problem isn't on my end. Is CERN's network down, slow, or just maxed out? This isn't the first time this has happened, but it's the worst I've seen. Interestingly, my system seems able to download work units without issue, just often extremely slow and problematic trying to return results. I have a few days, but I'd be upset if credit can't be awarded because the network problem keeps the work unit results from being sent!

It would be helpful to have more details.

"I have a 1G fibre connection ..."
Down I guess.
What about Up?

"Is CERN's network down, slow, or just maxed out?"
No. Nothing obvious.


What kind/how many computers do you run?
How are they connected to your internet router (wi-fi, cable ...)?
What OS do you use?

Some logs from reported tasks might help.
Don't post them. It would be better to make your computers visible for other volunteers here:
https://lhcathome.cern.ch/lhcathome/prefs.php?subset=project

Computers made visible.

It's my desktop Linux workstation, Ubuntu 20.04. Quad-core 6th gen Intel i7, 64 GB RAM. Runs BOINC, and I'm typically listening to music with Spotify, sometimes in a video meeting (video & audio almost never choppy). Connected via gigabit Ethernet. My home networking equipment is Ubiquiti. I'm a programmer and have been an off-and-on system administrator.

I also run other BOINC projects which don't have this issue https://stats.free-dc.org/stats.php?page=userbycpid&cpid=8eec59b304235b333e68fc4cf529753d

Your logs don't show unusual entries.
You run mainly ATLAS native tasks which copy their results back to BOINC when they are finished.
BOINC uploads them via the same libs that are used for all projects (libcurl).


All ATLAS downloads and uploads are done via a loadbalanced service on "lhcathome-upload.cern.ch".
This worked fine at least during the last 24 h.


You may check the following:

Are there any limits in BOINC?
"Options -> Computing Preferences ..."

Whether "<http_1_0>1</http_1_0>" is set in cc_config.xml
=> shouldn't be required any more. Either set "<http_1_0>0</http_1_0>" or remove the line completely.
"Reload config files" or restart BOINC in case you change this.

Did you set a network limit elsewhere (local firewall, router, ...)?

Do you transfer the data via a VPN or TOR?
They may also set a limit.

<http_1_0>0</http_1_0> is already set.

Not using a VPN, TOR, or anything like that. Just a direction connection. My ISP calls it 1 Gig, but it's 960 Mbps up and down, no usage caps. Other websites, including video conferencing, work fine.

"Options -> Computing Preferences..." doesn't have any limits set for networking. There are some computation settings, only so that BOINC doesn't use 100% of the CPU.

I increased the amount of allowed transfers and transfers per project, and the results were uploaded quickly. I wonder if the client was having internal issues due to the number of pending results.

Edit: posted to soon, the results are still there trying to upload, now at slightly faster speeds of 30-1000Kbps.

I figured it out, the LHC@Home communications was triggering this rule in my Ubiquiti router: https://github.com/seanlinmt/suricata/blob/master/files/rules/emerging-attack_response.rules#L213 "ET ATTACK_RESPONSE Output of id command from HTTP server". Transfers are slow but successful after allowing the CERN IPs which my router was logging with this firewall rule.