I found a little trick that seems to be working once you can get downloads started.
In cc_config, set max files transfer to 1.
<max_file_xfers>1</max_file_xfers>
Have Boinc read the config file.
Once it gets going, it will only download one task at a time.
Seems to be working at the moment.

Meow!

Meow yourself. :)
No luck here with that ...
Strange that some folks are actually getting anything and for others it seems to be down hard ...

---

No luck here with that ...

Nope.
Same for playing with the hosts file.
Things are very borked.


Berkeley campus System Status shows all green, so it's (most likely) just a Set issue again.

---

Grant
Darwin NT

It's working purrrrrrrrrrrfectly for me.
You might have to hit the retry button for a while to get things rolling.
But I am now downloading tasks 1 at a time with good results.

Meow.

---

"Time is simply the mechanism that keeps everything from happening all at once."

I notice that the Master Database is copping a hiding at the moment as well.

---

Grant
Darwin NT

A little bit of baby sitting here(spamming the retry on the last waiting task) and managed to get both machines to full caches.

To be fair it was only about 50 tasks across 2 machines.

I can get away with <max_file_xfers>2</max_file_xfers>

But you have to get one download started to begin with, then they take off on their own.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I can get away with <max_file_xfers>2</max_file_xfers>

But you have to get one download started to begin with, then they take off on their own.

Yeah, I finally got 1 box "in the door" and got ~100 tasks.
Looks like it's just everybody contending for open ports on the 1 d/l sever that is up and running.
Max xfers probably doesn't matter; just a question of getting a socket.

Max_xfers at 8 is probably pretty reasonable, given that max_xfers_per_project at 2 will throttle it lower anyway.

---

I can get away with <max_file_xfers>2</max_file_xfers>

But you have to get one download started to begin with, then they take off on their own.

In the land of work arounds...............LOL.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Morning Mark,

In the land of work arounds...............LOL.

Or J.M. Barrie's famous place :-)

Hiya, Chris.
I don't think I know that place.

Meow.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Morning Mark,

In the land of work arounds...............LOL.

Or J.M. Barrie's famous place :-)

Lol!

---

Peter Pan?

p.s. mornin' Jim

Ahh,,,,,,,,,,,,,,,,
When one believes, it can be so.
I might be due for a pixie haircut soon.

Meow.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Arrrghh...woke up to an eerily quiet living room...no cozy fan hum means S@H trouble.
And trouble there was....I'm down to a few CPU tasks left in cache.
Can't get the downloads moving, "Project communication failed: attempting access to reference site".
Oh well....good time to get some backup work done.

...Ghia...

---

Humans may rule the world...but bacteria run it...

Peter Pan?

p.s. mornin' Jim

Ahh,,,,,,,,,,,,,,,,
When one believes, it can be so.
I might be due for a pixie haircut soon.

Meow.

Or is it just that the servers are out in Never Never Land? :)
Morning, Chris.

---

Everything is going just dandy here and that's not to mention over 160 AP's picked up today.

Cheers.

Everything is going just dandy here and that's not to mention over 160 AP's picked up today.

Cheers.

Making me think this could be some sort of campus network issue.
I've tried your fix, I've tried other suggested fixes, i've tried both, & various combinations.

Still no joy.

---

Grant
Darwin NT

Well, like everybody else, I woke up to stalled downloads across all machines. All now fully reloaded and downloaded, with no downtime. Conclusions:

Smaller, less powerful machines can hold their caches for longer.
For this current (28 February/1 March 2019) problem, messing with the hosts file won't help. If you didn't 'reset to auto' after the last DNS failure, you're probably shooting yourself in the foot.
Setting 'max_file_xfers_per_project' to 1 does help. It won't help you get your first connection, but failures on the second channel won't send you into "project backoff". The single channel you've got seems to keep plodding away until finished.

Setting 'max_file_xfers_per_project' to 1 does help. It won't help you get your first connection, but failures on the second channel won't send you into "project backoff". The single channel you've got seems to keep plodding away until finished.

Do u Think they have modified their firewall to allow only one concurrent Connection perhaps. If multiple Connections occur from the same IP then the host is sent to a block firewall rule?!

That's the only explanation that comes to mind when max_file is set to 1 instead as of 2 per default.

---

_________________________________________________________________________
Addicted to SETI crunching!
Founder of GPU Users Group

Smaller, less powerful machines can hold their caches for longer.

Interestingly, my least capable machine is the only one that seems able to get DLs, and now does so consistently. The others, no soap after several hours of manual trying.
All are 'max_file_xfers_per_project' set to 1.
Like a lot of other things, all comes down to the luck of the draw.

---

No. There's no point, they haven't got time to mess about with things like that.

My reasoning for my advice was twofold:

1) At their end. We seem to have a download server which can't handle as many connections as we would all like it to service at the same time. Usually, when you hit it, it's too busy, and tells you to go away. But if you persist, every so often you'll hit it at just the right microsecond to get its attention.

2) At your end. Once you get a connection, you want to go on using it until your backlog is cleared. If you have a second set of connection attempts running at the same time, there's a chance that the second connection will hit at the wrong microsecond. Three of those in a row, and BOINC will stop trying. Then you go to the back of the scrum again.

Seems like it, once i updated the cc_config to accept only one at a time again it seems to go through now.
Needed to nag the retry (in boinccmd it's a mess) but once it got going it seems to let through the others too at a slow pace.

---

_________________________________________________________________________
Addicted to SETI crunching!
Founder of GPU Users Group