I looks like APs will not be split in a day or so.

Indeed. That seems to be our current cycle. Load in new data. We consume all of the AP by Friday/Saturday. Then caches whittle down, or switch to MB, until the next set of data is loaded. Luckily for me my machines are slow enough they never run out of MB or AP work it seems.

---

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

I looks like APs will not be split in a day or so.

Indeed. That seems to be our current cycle. Load in new data. We consume all of the AP by Friday/Saturday. Then caches whittle down, or switch to MB, until the next set of data is loaded. Luckily for me my machines are slow enough they never run out of MB or AP work it seems.

This is probably due to the fact that 3 AP splitters have been working on 1 file before all 3 move to another file, instead of each splitter doing its own separate file, during this AP feeding secession.

Cheers.

I looks like APs will not be split in a day or so.

Indeed. That seems to be our current cycle. Load in new data. We consume all of the AP by Friday/Saturday. Then caches whittle down, or switch to MB, until the next set of data is loaded. Luckily for me my machines are slow enough they never run out of MB or AP work it seems.

This is probably due to the fact that 3 AP splitters have been working on 1 file before all 3 move to another file, instead of each splitter doing its own separate file, during this AP feeding secession.

Cheers.

I have not understood why splitters would work on one data set when there are plenty of free ones for each splitter to work on its own. Perhaps it is faster for splitters to team up one one data set?
Whatever the case it doesn't seem to effect their output. AP RTS is at 25K. Which seems to be its cap like that of MB around 300K.

---

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

I looks like APs will not be split in a day or so.

Indeed. That seems to be our current cycle. Load in new data. We consume all of the AP by Friday/Saturday. Then caches whittle down, or switch to MB, until the next set of data is loaded. Luckily for me my machines are slow enough they never run out of MB or AP work it seems.

This is probably due to the fact that 3 AP splitters have been working on 1 file before all 3 move to another file, instead of each splitter doing its own separate file, during this AP feeding secession.

Cheers.

I have not understood why splitters would work on one data set when there are plenty of free ones for each splitter to work on its own. Perhaps it is faster for splitters to team up one one data set?
Whatever the case it doesn't seem to effect their output. AP RTS is at 25K. Which seems to be its cap like that of MB around 300K.

I have no idea why those AP splitters are doing what they are doing now, but this time we were a lot longer reaching that 25,000 mark than in previous weeks.

Cheers.

I have no idea why those AP splitters are doing what they are doing now, but this time we were a lot longer reaching that 25,000 mark than in previous weeks.

Cheers.

I have to agree with you I noticed the same thing. I was wondering if it was because more people were filling their quota with this work. I have also noticed these tasks seem to be running longer

---

I looks like APs will not be split in a day or so.

Indeed. That seems to be our current cycle. Load in new data. We consume all of the AP by Friday/Saturday. Then caches whittle down, or switch to MB, until the next set of data is loaded. Luckily for me my machines are slow enough they never run out of MB or AP work it seems.

This is probably due to the fact that 3 AP splitters have been working on 1 file before all 3 move to another file, instead of each splitter doing its own separate file, during this AP feeding secession.

Cheers.

I have not understood why splitters would work on one data set when there are plenty of free ones for each splitter to work on its own. Perhaps it is faster for splitters to team up one one data set?
Whatever the case it doesn't seem to effect their output. AP RTS is at 25K. Which seems to be its cap like that of MB around 300K.

I have no idea why those AP splitters are doing what they are doing now, but this time we were a lot longer reaching that 25,000 mark than in previous weeks.

Cheers.

The lines on the haveland stats look like we got there a tiny bit faster this week, but the resolution on the weekly graph could be misleading.
The fact that the mysterious forces that govern the splitters have seen fit to keep them working is the important part I think. Hopefully they will not require sacrificing hardware to keep them happy. I have not seen anyone talking about their hardware going up in smoke recently. With luck it shall stay that way.

---

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

I have no idea why those AP splitters are doing what they are doing now, but this time we were a lot longer reaching that 25,000 mark than in previous weeks.

Cheers.

I have to agree with you I noticed the same thing. I was wondering if it was because more people were filling their quota with this work. I have also noticed these tasks seem to be running longer

I suspect the slower AP splitting may have something to do with the extra MB splitters going now and a DB I/O limit that has been mentioned before. But that's just a guess on my part.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

I have no idea why those AP splitters are doing what they are doing now, but this time we were a lot longer reaching that 25,000 mark than in previous weeks.

Cheers.

I have to agree with you I noticed the same thing. I was wondering if it was because more people were filling their quota with this work. I have also noticed these tasks seem to be running longer

I suspect the slower AP splitting may have something to do with the extra MB splitters going now and a DB I/O limit that has been mentioned before. But that's just a guess on my part.

My gues is diferent, because the AP RTS buffer is at a high level (>25k) the system slowdown the splitters automaticaly.

---

I have no idea why those AP splitters are doing what they are doing now, but this time we were a lot longer reaching that 25,000 mark than in previous weeks.

Cheers.

I have to agree with you I noticed the same thing. I was wondering if it was because more people were filling their quota with this work. I have also noticed these tasks seem to be running longer

I suspect the slower AP splitting may have something to do with the extra MB splitters going now and a DB I/O limit that has been mentioned before. But that's just a guess on my part.

My gues is diferent, because the AP RTS buffer is at a high level (>25k) the system slowdown the splitters automaticaly.

But we were referring to the splitting speed when AP first started back up.
Once the RTS is up to 25k, yes they automatically throttle back until it needs refilling.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

I see what you meant when all the spiter were red they were not broken down I been told my boys are getting me a new pc so my gtx760 I was getting is on hold till november hope it work well

Soon we will not have any APs to download.

---

Soon we will not have any APs to download.

All gone. Roughly 400 channels left to go before more work will be loaded

---

Is its just the AP's that run out or will the MB's run out too

There appear be enough "tapes" loaded on the server to carry us through until Tuesday, which is when new tapes are added to the pool.

---

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

Soon we will not have any APs to download.

:(

---

rOZZ
Music
Pictures

Soon we will not have any APs to download.

:(

The last batch of APs were highly blanked, so they were not really good crunching anyways....
Waiting for the next run.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

I've got enough AP's to keep my 2 CPU's happy until the next file load, while my GPU's happily do as many MB's as they can.

Cheers.

my pcs are not fast so they will just keep going for a long time after most other run out I think

Well it looks like those files to be split at the bottom of the list, that have been there for 2-3 months now, look like they'll be there even longer seeing as new files are already being added again over the top of them again (those new files could've waited until tomorrow) and the 1st new file has 3 AP splitters again tied up plus that file only seems to be producing errors as well. :-(

Cheers.

Well it looks like those files to be split at the bottom of the list, that have been there for 2-3 months now, look like they'll be there even longer seeing as new files are already being added again over the top of them again (those new files could've waited until tomorrow) and the 1st new file has 3 AP splitters again tied up plus that file only seems to be producing errors as well. :-(

Cheers.

Given the choice I would take error channels over hung/stuck ones.

---

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