Wiggo, you are dead right there.

There is another side effect as well. For example, assuming I only do AP, if I only get AP for half the time, then I can maintain a RAC equivalent to crunching MB only (on a monthly basis), but with circa half the power usage due to idle GPUs and CPUs.

---

More like more people are doing AP's so that they can get a better RAC happening.

Don't worry Sten, I'll keep trying my best to chew through those MB's so more files can be loaded.

Cheers.

Don't worry indeed.

The kitties are of course muching their way through a ton of MB work as well.
I do not have any of my rigs set up AP-only.

---

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

I've been getting lots of re-sends for APs to clean up that ATI fiasco. So far, re-sends are enough to satisfy my cache's demands. In fact, I just got a _7 task earlier.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

Been scratching my head lately over the download network traffic. There have been some large surges, and as now some sustained traffic levels, even though there is no AP work going out, no increase in the amount of MB work in progess, nor a decline in the average turn around time.

---

Grant
Darwin NT

Been scratching my head lately over the download network traffic. There have been some large surges, and as now some sustained traffic levels, even though there is no AP work going out, no increase in the amount of MB work in progess, nor a decline in the average turn around time.

I have noticed that myself, and was just as curious as you are. With the way v7 runs, I don't know if we shall really see another true 'shorty storm'. And even if we did have a minor one, the effects on the bandwidth would not have such a marked start and stop.

Only guess would be retrieving some information from the servers back to the lab for archiving purposes? Dunno.

---

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

Been scratching my head lately over the download network traffic. There have been some large surges, and as now some sustained traffic levels, even though there is no AP work going out, no increase in the amount of MB work in progess, nor a decline in the average turn around time.

I have noticed that myself, and was just as curious as you are. With the way v7 runs, I don't know if we shall really see another true 'shorty storm'. And even if we did have a minor one, the effects on the bandwidth would not have such a marked start and stop.

Only guess would be retrieving some information from the servers back to the lab for archiving purposes? Dunno.

Looking at my results shorties are taking about 45% as long to run as normal AR tasks. I expect if we get a bunch of 'tapes' that make nothing but shorties we will be able to tell on the b/w graph.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

I wonder if the creation rate could be related to file 20jn12ac as it has been in its current state for way longer than is usual.

Cheers.

And 12 days later, 20jn12ac is still in the same sorry state. Someone is asleep at the helm.

As far as I know, that stuck dataset holds up 1 MB splitter. And since MB splitting has been keeping up with demand, maybe that's why it's not been dealt with. Although the rational for leaving it in it's stuck state evades me...LOL.

---

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

I think Mark's right - as its not causing any delays in the MB production its never reached the top of someone's tuit list.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

I wonder if the creation rate could be related to file 20jn12ac as it has been in its current state for way longer than is usual.

Cheers.

And 12 days later, 20jn12ac is still in the same sorry state. Someone is asleep at the helm.

As far as I know, that stuck dataset holds up 1 MB splitter. And since MB splitting has been keeping up with demand, maybe that's why it's not been dealt with. Although the rational for leaving it in it's stuck state evades me...LOL.

No it isn't. No splitter has run on that file since sometime last week. They blocked it somehow, and just have not dismounted it yet.

---

Donald
Infernal Optimist / Submariner, retired

I wonder if the creation rate could be related to file 20jn12ac as it has been in its current state for way longer than is usual.

Cheers.

And 12 days later, 20jn12ac is still in the same sorry state. Someone is asleep at the helm.

As far as I know, that stuck dataset holds up 1 MB splitter. And since MB splitting has been keeping up with demand, maybe that's why it's not been dealt with. Although the rational for leaving it in it's stuck state evades me...LOL.

No it isn't. No splitter has run on that file since sometime last week. They blocked it somehow, and just have not dismounted it yet.

How do you know that if it's stuck, Donald?
I was told by Eric that if a dataset gets stuck, it ties up the splitter working on it. I was later told that Matt had restarted it. But it would appear that it got stuck again. Just curious why you think the splitters are all dancing around it and that it's not still stuck tying up a splitter.

---

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

look at the color chart channel in progress so it is not being split at this moment

While not being split it is tying up a splitter doing nothing.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

While not being split it is tying up a splitter doing nothing.

Or IS it at the moment?
Not really sure.
JEAN makes a good point...
We have 6 active splitters, and the SSP shows 6 datasets color coded as 'in progress'. The stuck dataset does not show that.

Although I know everything on the SSP is not always as it appears.
And don't have any idea if one splitter only works on one dataset at a time by itself.

---

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

look at the color chart channel in progress so it is not being split at this moment

Exactly. There are no dark green "in progress" bands on that file, and have not been since about Wednesday last week. There was one when it was stuck earlier. That's why I think Eric or Matt "blocked" that file from being split.

And don't have any idea if one splitter only works on one dataset at a time by itself.

I have seen as many as 9 channels "in progress" on MB, so at least some of the splitters can do 2 channels at once.

---

Donald
Infernal Optimist / Submariner, retired

look at the color chart channel in progress so it is not being split at this moment

Exactly. There are no dark green "in progress" bands on that file, and have not been since about Wednesday last week. There was one when it was stuck earlier. That's why I think Eric or Matt "blocked" that file from being split.

And ya just could be correct, my friend.

---

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

I'm thinking with the network bandwidth we have now, and no end in sight for the serverside limits, they could probably tweak the AP/MB ratio of work being split & pump out more AP these days.

---

Grant
Darwin NT

I'm thinking with the network bandwidth we have now, and no end in sight for the serverside limits, they could probably tweak the AP/MB ratio of work being split & pump out more AP these days.

If I am not mistaken, each dataset splits into a finite number of MB WUs as well as a finite number of AP WUs.
If the AP work is crunched and returned faster than the MB work is, that simply leaves the MB work remaining that has to be done before more datasets are loaded and split.

I don't think there is any way of making more AP work out of the data than there already is.

---

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

look at the color chart channel in progress so it is not being split at this moment

Exactly. There are no dark green "in progress" bands on that file, and have not been since about Wednesday last week. There was one when it was stuck earlier. That's why I think Eric or Matt "blocked" that file from being split.

And don't have any idea if one splitter only works on one dataset at a time by itself.

I have seen as many as 9 channels "in progress" on MB, so at least some of the splitters can do 2 channels at once.

I've seen up to 16 or so reported in the count, but manually counting the number of channels marked with the dark green block generally matches the number of splitters with Status = "Running". IOW, the count for "channels in progress:" has sometimes exceeded the other two indications of what's being done. My guess has always been that completion of a channel merely failed to reduce the count under some circumstances.

A splitter process can only work on one channel at a time. Although it has become conventional to call the work "multibeam", WUs have strictly been single beam.

                                                                  Joe

APs, them APs, where oh where are they?

They are on tapes that are yet to be loaded into the splitters. We are all processing the MB work units as fast as we can

---

APs, them APs, where oh where are they? There haven't been any fresh APs being split for days now, and the few resends just isn't enough. I'm getting seriously low on APs now, and since AP is all I run, my computers will be idle soon, if there aren't any AP files added to the splitters very soon...

Panic, serious panic ahead.

Sten, I'm afraid it looks like you are going to run dry and this may the norm going forward. The new world order appears to be that every one is jumping on AP when they are available in order to bolster their RAC. It's a shame that the credits for v7 MB are so low in comparison otherwise this wouldn't be happening and I can't see a fix for the v7 credit issue coming any time soon.

Good luck though and hope you make it through to the next tape.

Lionel

---