I thought unroll should be set to 2 times your Complete Units. My 750Ti has 5.

I was use unroll 16 because someone suggested it, it worked but would lock up if I tried to view a video with AP tasks running.

So I backed it off to unroll 10 and it seems fine now.

With -use_sleep in use it can be 2.5 times the number of CU`s (compute units)
So unroll 12 with 5 CU`s is fine.

---

With each crime and every kindness we birth our future.

Is there any way to have a different method of identifying the individual GPUs in the device-specific configuration other than Device 0, Device 1, etc., to avoid this sort of shuffling when upgrading drivers?

Who could better know what card is what than their own device driver?
If device driver decided to change enumeration we must follow ;)
Another recognition metod would require AI to implement :D

Is there any way to have a different method of identifying the individual GPUs in the device-specific configuration other than Device 0, Device 1, etc., to avoid this sort of shuffling when upgrading drivers?

Who could better know what card is what than their own device driver?
If device driver decided to change enumeration we must follow ;)
Another recognition metod would require AI to implement :D

Okay, just thought I'd ask. ;^) It caught me by surprise because I don't think I'd seen that happen in earlier driver updates.

Perhaps it would be helpful to add a note to the ReadMe for the device-specific configuration to suggest that users recheck their device assignments following a driver upgrade.

Perhaps it would be helpful to add a note to the ReadMe for the device-specific configuration to suggest that users recheck their device assignments following a driver upgrade.

Yes, such warning is appropriate. Along with possible same result after physical slot change.

Perhaps it would be helpful to add a note to the ReadMe for the device-specific configuration to suggest that users recheck their device assignments following a driver upgrade.

Yes, such warning is appropriate. Along with possible same result after physical slot change.

That would be good, thanks!

Added warning for next commit. Thanks for hint.

With 325k+ MB in the "ready to send" queue, it's about time to load some more APs, I'm running dry.

---

I don't buy computers, I build them!!

With 325k+ MB in the "ready to send" queue, it's about time to load some more APs, I'm running dry.

We have a bit of work left to do on the MB front
Total channels to do: 622

---

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

MB splitters are down to 500 chnanels to split, it's going to be a long time before we see fresh APs in any number.

---

MB splitters are down to 500 chnanels to split, it's going to be a long time before we see fresh APs in any number.

I think there is a new disk being worked on - the last one had 504 available channels. The one currently being split has 434 available channels w/ 391 to go. Should we hold a lottery to see how many of these we have to go through before we get to splitting APs again?

---

I don't buy computers, I build them!!

MB splitters are down to 500 chnanels to split, it's going to be a long time before we see fresh APs in any number.

I think there is a new disk being worked on - the last one had 504 available channels. The one currently being split has 434 available channels w/ 391 to go. Should we hold a lottery to see how many of these we have to go through before we get to splitting APs again?

You seem to be looking at total available channels on disk which is the total of recorded channels for all of the data sets. The number previously being refereed to is total channels to do. Just a few lines down. Which is current sitting at 385

---

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

MB splitters are down to 500 chnanels to split, it's going to be a long time before we see fresh APs in any number.

I think there is a new disk being worked on - the last one had 504 available channels. The one currently being split has 434 available channels w/ 391 to go. Should we hold a lottery to see how many of these we have to go through before we get to splitting APs again?

You seem to be looking at total available channels on disk which is the total of recorded channels for all of the data sets. The number previously being refereed to is total channels to do. Just a few lines down. Which is current sitting at 385

I agree, but the point I was trying to make was that a newer disk is currently being split w/ 391 to go and how many more would we will have to encounter before AP splits again. If it was one or between switching back to APs I wouldn't mind so much, but it seems that its weeks before that happens.

---

I don't buy computers, I build them!!

MB splitters are down to 500 chnanels to split, it's going to be a long time before we see fresh APs in any number.

I think there is a new disk being worked on - the last one had 504 available channels. The one currently being split has 434 available channels w/ 391 to go. Should we hold a lottery to see how many of these we have to go through before we get to splitting APs again?

You seem to be looking at total available channels on disk which is the total of recorded channels for all of the data sets. The number previously being refereed to is total channels to do. Just a few lines down. Which is current sitting at 385

I agree, but the point I was trying to make was that a newer disk is currently being split w/ 391 to go and how many more would we will have to encounter before AP splits again. If it was one or between switching back to APs I wouldn't mind so much, but it seems that its weeks before that happens.

I haven't got a clue what this "new disk" you are referring to might be. There doesn't appear to have been any new data sets, or tapes if you prefer, added to the queue to be split since there were loaded previously. We are working down from about 800 or so channels I believe.

---

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

This is the current status As of 22 Jul 2015, 21:10:04 UTC. When I did the original post on this, the "total available channels on disk" was either 503 or 504, I can't remember which one. I may be wrong, but the total available channels on a disk does not change, while splitting files on that disk. If that is indeed the case, then the disk currently being worked is in fact a new disk. If my perspective on this is incorrect, then this senile old man deeply apologies.

total available channels on disk: 420 0
channels in progress: 7 0
channels done: 39 0
channels ended in error: 0 0
total channels to do: 374 0

---

I don't buy computers, I build them!!

This is the current status As of 22 Jul 2015, 21:10:04 UTC. When I did the original post on this, the "total available channels on disk" was either 503 or 504, I can't remember which one. I may be wrong, but the total available channels on a disk does not change, while splitting files on that disk. If that is indeed the case, then the disk currently being worked is in fact a new disk. If my perspective on this is incorrect, then this senile old man deeply apologies.

total available channels on disk: 420 0
channels in progress: 7 0
channels done: 39 0
channels ended in error: 0 0
total channels to do: 374 0

'On disk' means "in currently accessible storage" - the server disk array where data is stored while being work on.

So, there's no "new disk" involved, just a number of image files stored 'on disk'. When an image file is completely split, the working copy is deleted from local storage, and the total number of channels reduces by 14.

This is the current status As of 22 Jul 2015, 21:10:04 UTC. When I did the original post on this, the "total available channels on disk" was either 503 or 504, I can't remember which one. I may be wrong, but the total available channels on a disk does not change, while splitting files on that disk. If that is indeed the case, then the disk currently being worked is in fact a new disk. If my perspective on this is incorrect, then this senile old man deeply apologies.

total available channels on disk: 420 0
channels in progress: 7 0
channels done: 39 0
channels ended in error: 0 0
total channels to do: 374 0

Ah, now I understand why you were saying that. Hopefully Richard's explanation clears up any confusion.

According to my father being senile is the best part of getting old. :P

---

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

...Never mind Grumps, there aren't that many tapes to be split before we get you your next fix

---

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

MB splitters are down to 500 chnanels to split, it's going to be a long time before we see fresh APs in any number.

As I stated 2 days ago.

---

OMG !!!

It is gonna get worse.

My RAC was 23.5K
At post time 19.7K and falling like a stone.

We don't care about RAC and points, only about the science... (Then why am I stressing about no APs and the fact my RAC will probably drop 40%)

All is good here. Move along. Nothing of concern.

Bob

---

Sometimes I wonder, what happened to all the people I gave directions to?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SETI@home classic workunits 4,321
SETI@home classic CPU time 22,169 hours

how come nobody complains when their rac shoots upward