And, in [further] answer to Peter, I can't find any evidence that there are new N-Body work units being added at present -- admittedly that's by random sampling of high work unit numbers and watching their rate of increase but, unless there's some way of getting "work units generated in the last hour" (or similar) onto the Server Status page, user research can't do any better. Tom did say there's supposed to be a limit, but that doesn't explain how it ran away in the first place, so a little doubt-based research is in order :-)

Cheers - Al.

I just tried the same computer again which already has exactly 100 tasks queued, and got no more work. So I tried another computer and got exactly 100. So it's a server limit, not a shortage or clog-up. Not sure how that limit got on there which I'm sure wasn't there before, especially as Tom promised me a higher limit for seperation. But I can't see a problem with a 100 Nbody limit, especially as the can't send/receive at once bug only exists for seperation.

That isn't you. The server is clogged up with stuff to send. It may eventually clear, or it may need Tom to do something. Mind you, I just tested it, using a 10 day buffer with 4 fast cores = 6 minutes per task, so in theory I could get 2400 Nbody tasks. I got 100, then 0 1.5 minutes later, then 0 1.5 minutes after that. Perhaps a 100 task limit has been imposed? That's a very round number I got.

Every single one is a _2 task, so presumably we have a lot of finishing off to do as wingmen. So those cannot be cleared or the research would have gaps. Unless Tom can put through a smaller number at a time so as not to confuse the server?

Yep, I didn't count mine exactly but it was very close to 100, and probably was. And yes, they are all _2 tasks, which is why I'm so anxious to run them, to clear out the back log. I have 2 other computers running nbody exclusively, so am not out of the recovery game totally. It would be nice to run the big iron on this task, but so far, various combinations of setting computer preferences, and jiggering the app_config.xml file have yielded zero results. So for now, the big iron is running only separation. I may look into running 2 boinc instances on this computer, but honestly, it just should not be this difficult.

Cheers.

Not sure how that limit got on there which I'm sure wasn't there before, especially as Tom promised me a higher limit for seperation. But I can't see a problem with a 100 Nbody limit, especially as the can't send/receive at once bug only exists for seperation.

So do we need to ask Tom for a higher limit like is promised for separation? I wouldn't have a problem with a 100 nbody limit(90 minutes worth of work), as long as I didn't run out of n body. Right now, I see dry spells of about 45 minutes or so.

It's interesting that my nvidia gpu can get 40 hours or so of work when needed.

And, in [further] answer to Peter, I can't find any evidence that there are new N-Body work units being added at present -- admittedly that's by random sampling of high work unit numbers and watching their rate of increase but, unless there's some way of getting "work units generated in the last hour" (or similar) onto the Server Status page, user research can't do any better. Tom did say there's supposed to be a limit, but that doesn't explain how it ran away in the first place, so a little doubt-based research is in order :-)

Cheers - Al.

I just tried the same computer again which already has exactly 100 tasks queued, and got no more work. So I tried another computer and got exactly 100. So it's a server limit, not a shortage or clog-up. Not sure how that limit got on there which I'm sure wasn't there before, especially as Tom promised me a higher limit for seperation. But I can't see a problem with a 100 Nbody limit, especially as the can't send/receive at once bug only exists for seperation.

That's an interesting observation (which I had also spotted, and assumed was because the server knows N-Body is a multi-thread application and is expected to use all cores so the typical "100 per CPU" turns into "100 per computer" :-). However, it wasn't the limit I was talking about...

I was referring to limits that should stop the work unit generator from producing new work when there is already more than a certain amount available and that re-enable work when it sinks below a [possibly different] threshold; that's why I made my comment about the initial "running away" that got it in the mess it is currently in. If you thought you were answering what I said, sorry if I wasn't clear enough :-)

Cheers - Al.

P.S. I'm guessing the limit here is 10,000 because the Separation unsent count seems to hover around 9,000...

Ryzen 9 computer lists 72 n-body tasks and 1071 separation task as in progress.

yep. 72 tasks at 1.25 minutes/task will finish in 57 minutes. I am now down to 49 tasks ready to run. the well has run dry many times.

the question still remains from here: https://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=4881&postid=73361

why is the number of n body tasks increasing, while at the same time, telling me there are none available?

I don't know but Universe and Number Fields do the exact same thing until after 30 minutes or more, sometimes days, it will send me tasks, that makes me think it's a Boinc thing.

Not sure how that limit got on there which I'm sure wasn't there before, especially as Tom promised me a higher limit for seperation. But I can't see a problem with a 100 Nbody limit, especially as the can't send/receive at once bug only exists for seperation.

So do we need to ask Tom for a higher limit like is promised for separation? I wouldn't have a problem with a 100 nbody limit(90 minutes worth of work), as long as I didn't run out of n body. Right now, I see dry spells of about 45 minutes or so.

It's interesting that my nvidia gpu can get 40 hours or so of work when needed.

I believe, it's been a LONG time, that the limit was put in place just so someone with 48 or more cpu's doesn't come in and grab 3k units and then not finish them on time or not leave enough for everyone else that wants them. I think it's a good time to rethink the limit but to also take into account the number of people and pc's that try to get and return tasks everyday as well so no one gets zero tasks because the Server can't keep up. I mean if you have a cpu with 100 cpu cores and overclock that a little bit you could finish all of those tasks in under and hour and in 24 hours take almost 1/3rd of the total tasks made per day. If that same pc started having issues and returning junk then that's 1/3rd of the total daily tasks sent out that go back out as resends.

Yep, I didn't count mine exactly but it was very close to 100, and probably was. And yes, they are all _2 tasks, which is why I'm so anxious to run them, to clear out the back log. I have 2 other computers running nbody exclusively, so am not out of the recovery game totally. It would be nice to run the big iron on this task, but so far, various combinations of setting computer preferences, and jiggering the app_config.xml file have yielded zero results. So for now, the big iron is running only separation. I may look into running 2 boinc instances on this computer, but honestly, it just should not be this difficult..

I want to put my 92 cores onto Nbody, but I'm in a Pentathlon for Universe!

What's stopping you getting 100 at a time and maxing out your CPU with no settings changes?

So do we need to ask Tom for a higher limit like is promised for separation? I wouldn't have a problem with a 100 nbody limit(90 minutes worth of work), as long as I didn't run out of n body. Right now, I see dry spells of about 45 minutes or so.

It's interesting that my nvidia gpu can get 40 hours or so of work when needed.

That's a slow GPU at 44Gflops, my Tahitis at 1000Gflops only get 2 or 3 hours work, then an annoying 10 minute delay because of Boinc thinking the server has no work available, when in reality it was just refusing to hand it out on the same contact as receiving the last ones.

I was referring to limits that should stop the work unit generator from producing new work when there is already more than a certain amount available and that re-enable work when it sinks below a [possibly different] threshold; that's why I made my comment about the initial "running away" that got it in the mess it is currently in. If you thought you were answering what I said, sorry if I wasn't clear enough :-)

Cheers - Al.

P.S. I'm guessing the limit here is 10,000 because the Separation unsent count seems to hover around 9,000...

No, probably me having too much vodka and answering the wrong question.

It traditionally sits at 10,000 seperation and 1,000 Nbody. Not sure why the limiter fell off when things went wrong. Many millions of Nbodies was rather odd.

As for the other conversation, maybe there's always been the 100 limit per customer or the buffer would run out (Tom did say to increase from 300 per GPU the seperation would have to have more than 10,000 in the buffer), and I never noticed the 100 limit before as Nbody is never a problem to get.

I don't know but Universe and Number Fields do the exact same thing until after 30 minutes or more, sometimes days, it will send me tasks, that makes me think it's a Boinc thing.

Is that because you're bunkering like me? Those get annoyed (as does Primegrid) when I block their server with a firewall so the uploads wait until competition day.

I don't know but Universe and Number Fields do the exact same thing until after 30 minutes or more, sometimes days, it will send me tasks, that makes me think it's a Boinc thing.

Is that because you're bunkering like me? Those get annoyed (as does Primegrid) when I block their server with a firewall so the uploads wait until competition day.

No I do not 'bunker' tasks like that.

I don't know but Universe and Number Fields do the exact same thing until after 30 minutes or more, sometimes days, it will send me tasks, that makes me think it's a Boinc thing.

Is that because you're bunkering like me? Those get annoyed (as does Primegrid) when I block their server with a firewall so the uploads wait until competition day.

No I do not 'bunker' tasks like that.

We do, which is why Scotland does so well.

Is that because you're bunkering like me? Those get annoyed (as does Primegrid) when I block their server with a firewall so the uploads wait until competition day.

And what is the benefit of this? I don't see your point here.

Is that because you're bunkering like me? Those get annoyed (as does Primegrid) when I block their server with a firewall so the uploads wait until competition day.

And what is the benefit of this? I don't see your point here.

Bunkering is the getting and crunching of tasks but preventing the return of them until after the start of a challenge so your Team gets a big boost, the longer a challenge runs the less effective bunkering is, also some challenges specifically prohibit that but using the time stamp of a sent task to approve or deny a result for the challenge, you would still get credit but not for the challenge.

Is that because you're bunkering like me? Those get annoyed (as does Primegrid) when I block their server with a firewall so the uploads wait until competition day.

And what is the benefit of this? I don't see your point here.

Bunkering is the getting and crunching of tasks but preventing the return of them until after the start of a challenge so your Team gets a big boost, the longer a challenge runs the less effective bunkering is, also some challenges specifically prohibit that but using the time stamp of a sent task to approve or deny a result for the challenge, you would still get credit but not for the challenge.

They could very easily stop it by not announcing the name of the project until the time it starts. They seem to think it's part of tactics though. I don't like it but if I don't do it I lose.

As for what you said they do, they could know when it was sent out, but not when you worked on it. It wouldn't be fair to discount something I already had in my buffer, but crunched during the competition.

Is that because you're bunkering like me? Those get annoyed (as does Primegrid) when I block their server with a firewall so the uploads wait until competition day.

And what is the benefit of this? I don't see your point here.

Bunkering is the getting and crunching of tasks but preventing the return of them until after the start of a challenge so your Team gets a big boost, the longer a challenge runs the less effective bunkering is, also some challenges specifically prohibit that but using the time stamp of a sent task to approve or deny a result for the challenge, you would still get credit but not for the challenge.

They could very easily stop it by not announcing the name of the project until the time it starts. They seem to think it's part of tactics though. I don't like it but if I don't do it I lose.

As for what you said they do, they could know when it was sent out, but not when you worked on it. It wouldn't be fair to discount something I already had in my buffer, but crunched during the competition.

Prime Grid does it that way, any task gotten by you before the Challenge starts will not be counted towards your challenge credits, also any task received after the Challenge ends does not count either, that prevents people from cranking up their cache and returning units over the next 10 days to 4 months after the Challenge ends.

I believe, it's been a LONG time, that the limit was put in place just so someone with 48 or more cpu's doesn't come in and grab 3k units and then not finish them on time or not leave enough for everyone else that wants them. I think it's a good time to rethink the limit but to also take into account the number of people and pc's that try to get and return tasks everyday as well so no one gets zero tasks because the Server can't keep up. I mean if you have a cpu with 100 cpu cores and overclock that a little bit you could finish all of those tasks in under and hour and in 24 hours take almost 1/3rd of the total tasks made per day. If that same pc started having issues and returning junk then that's 1/3rd of the total daily tasks sent out that go back out as resends.

Yep. I'm in violent agreement to rethink the limit, which was probably legit at onetime. Boinc is 20+ years old, and there are a lot more and a lot faster home computers now. And even 10 year old GPUs are screaming fast. Shucks, my R9 280x with a busted fan does 1 separation every 30 seconds. Or 2880 tasks in 24 hours. Sadly Boinc does not support that burn rate here. As I write this, I am waiting for GPU separation tasks.

The capacity in the MW community is definitely there, even more so when Unixchick and her WCG friends drop by for a month or so. It is high time to rethink the server side.

What's stopping you getting 100 at a time and maxing out your CPU with no settings changes?

100 at a time does not max out my settings, which is set to 3 days worth of work across all task types. The issue is, my computer runs dry every few hours or so, and I would like to keep it busy, but MW does not seem to support that. I think my computer limit is something like 550 tasks all together.

That's a slow GPU at 44Gflops, my Tahitis at 1000Gflops only get 2 or 3 hours work, then an annoying 10 minute delay because of Boinc thinking the server has no work available, when in reality it was just refusing to hand it out on the same contact as receiving the last ones.

Yep. that's why I recently got an R9 280x, at your recommendation. Pleased as punch with it, but like you, can't seem to keep it fully employed, at MW anyway. Mikey(and I don't ever poke him!) has suggested 4 other space based DC projects but would like to stick here and make it work. I see really good things coming out of this research.

Prime Grid does it that way, any task gotten by you before the Challenge starts will not be counted towards your challenge credits, also any task received after the Challenge ends does not count either, that prevents people from cranking up their cache and returning units over the next 10 days to 4 months after the Challenge ends.

This is news to me. Don't Primegrid just declare my credits as I return the tasks? It's the pentathlon that decides what to include.