Transfers stalled and the click retry and there's instant BW, why is this...?

I run mainly Seti ap tasks on my ATI.
I do get tasks.
When they start they do nicely.
But after a few percent they do stop and will retry after some time...
I do click retry button and woops they start almost instant again and will stop again after a few percent of dl.

This seem strange to me.
There seems to be BW since dl starts directly after clicking the retry button is clicked.

Anyone have a clue to why transfers stop(stalls) all the time??

I run mainly Seti ap tasks on my ATI.
I do get tasks.
When they start they do nicely.
But after a few percent they do stop and will retry after some time...
I do click retry button and woops they start almost instant again and will stop again after a few percent of dl.

This seem strange to me.
There seems to be BW since dl starts directly after clicking the retry button is clicked.

Anyone have a clue to why transfers stop(stalls) all the time??

Anyone else got an idea??

Anyone have a clue to why transfers stop(stalls) all the time??

Anyone have a clue to why transfers stop(stalls) all the time??

Because as always, the number of downloads in progress is well above the amount needed to saturate the 100 Mbits/sec Hurricane link, (maybe up to 5 or 6 times):

Graphs for gigabitethernet2_3

Claggy

Yes, but that doesn't explain why there is BW as soon as the retry button is pushed.

Yes, but that doesn't explain why there is BW as soon as the retry button is pushed.

BW? What does that mean?

Claggy

I noticed this repeatedly. You get a little bandwidth after toggling network activity, then it goes back to normal slow or stalled out again. I would really like to know the reason for this anomoly.

____________

I noticed this repeatedly. You get a little bandwidth after toggling network activity, then it goes back to normal slow or stalled out again. I would really like to know the reason for this anomoly.

The impression I get is that the server tends to drop connections after a while, which leads to time-outs at the client's end. So a fresh connection might get a burst of download, but then it gets lost after a while, or even after a few seconds, because of the huge demand on the server.

Looking at your location and RAC, though, I don't think you have as much of a bandwidth problem as some others. ;)

Edit: Gah, Richard beat me to the post.
____________
Soli Deo Gloria

IMO whatever TCP congestion avoidance algorithm is in use is likely showing that "instant BW" effect for each new connection. The cause was already stated, there's more work assigned to be downloaded than can fit through the pipe.

The clue on my Windows 7 machine is that during the first part of the transfer, it goes much faster than my link will support. I believe that what might be happening is that BOINC is seeing the transfer to some internal buffer initially, and then looking at the end to end transfer when it times out. Try changing one of the options in cc_config.xml to see if the problem goes away. <http_transfer_timeout>seconds</http_transfer_timeout> to maybe 3500 rather than 300 and see what happens.
____________


BOINC WIKI

Seems that what's ruining it for me is the Astropulse work units. They are so large that they inevitably time out 1-2% in to the download. Their time is estimate is also ridiculous... for me they show 159 hours, but they take about 1-2% of that to complete! So, since the BOINC client thinks there's enough GPU work it won't request it for any other projects, and the GPUs sit idle.

So much for my wanting to get GPU Astropulse running. :^p I've just babysat two GPU AP downloads turning off/on network connectivity about twenty times in twenty minutes to restart it and have yet to complete one...
____________
“Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has.”
--- Margaret Mead

What I'm finding is that Uploads kill the Downloads.
I will have downloads creeping along at around 2.5 to 3.5 kBs, slow but still happening. Then when an upload happens, as soon as the upload is finished the downloads stall until I use the "suspend network activity/restart network activity" trick. After this the downloads creep along ok until the next upload.

Most annoying when 2/3rds of the units on board are shorties.

T.A.

IMO whatever TCP congestion avoidance algorithm is in use is likely showing that "instant BW" effect for each new connection. The cause was already stated, there's more work assigned to be downloaded than can fit through the pipe.

Joe

IMO whatever TCP congestion avoidance algorithm is in use is likely showing that "instant BW" effect for each new connection. The cause was already stated, there's more work assigned to be downloaded than can fit through the pipe.

Joe

Wouldnt be possible to throttle the splitters (or the feeder, or the scheduller or whatever is needed) in some way so they dont produce/assign more files to be transfered than the pipes can handle? I know that means less work available to be assigned but it doesnt help to have it assigned if you cant download it... Specially if they fail and need to be retried over and over again wasting a lot of bandwith...

What I'm finding is that Uploads kill the Downloads.
I will have downloads creeping along at around 2.5 to 3.5 kBs, slow but still happening. Then when an upload happens, as soon as the upload is finished the downloads stall until I use the "suspend network activity/restart network activity" trick. After this the downloads creep along ok until the next upload.

Most annoying when 2/3rds of the units on board are shorties.

T.A.

Here's what I see happening now that many AP units are being sent:

1. In each group of new tasks sent I get an AP or two.
2. Fairly quickly I get two APs currently downloading.
3. These two soon stall.
4. Once stalled they eventually timeout with a ridiculous backoff of between four to five hours.
5. While these APs are stalled and/or backed off BOINC and/or SETI refuse to send my results and also refuse to request any new tasks, AP -or- MB for CPU or GPU.
6. This timeout/backoff cycle continues for such a long time (days) that my faster rigs run completely out of GPU MB and sometimes even out of CPU MB tasks!

All this because of two lonely AP units that are stuck for days if left untouched.

So, until someone fixes this flaw in the transfer system, here is my question:

Is there an override option that will allow more than two downloads at a time so that the two stuck AP downloads, which is now a constant problem, will not prevent me from getting any more MB CPU/GPU units?

<max_file_xfers>N</max_file_xfers> Maximum number of simultaneous file transfers (default 8). <max_file_xfers_per_project>N</max_file_xfers_per_project> Maximum number of simultaneous file transfers per project (default 2).

I think that more than two transfers at a time (say, perhaps, four) may be at least a partial workaround that could keep my rigs running quite a bit longer before running out of work thanks to just two stuck APs. The only other option I see at this time is to turn off AP processing, which I really do not want to do.

Thanks for any help you can give me with this!