I crunch on 3 computers. My daily driver is a I7 920 running Vista. Both the wife and I use it. My other two crunchers are I7 3770's. I reboot my daily driver about every 3 or 4 days. I reboot the 3770's about once a week.

My stupid question is. Now that im running two work units a piece on both of these machines GPU's should I reboot more often?

---

[/quote]

Old James

No - Two of my three sit here for days with nothing more than a quick "oh its still running OK" glance at the screen (which has to be turned on first!). The third is my daily driver. I guess a random one gets re-booted every weeks - more often than not after I kick a power cable out or have to go diving behind to get at something I've dropped.

---

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

My 2 with their 64bit OS's only get rebooted during the monthly updates, but when I had a 32bit rig it had to be rebooted every 4-5 days to release system memory since the intro of SETI V7.

Cheers.

I reboot the daily driver when I start to notice response lags when i try to do something.

---

[/quote]

Old James

I reboot the daily driver when I start to notice response lags when i try to do something.

Mine is my 3570K with dual GTX660's running all 4 cores and 3 tasks per card though I do suspend crunching when I get into heavy video editing, but I've never noticed any lag on either current rig (with my old Q6600 with 32bit OS I did and it was running those same GTX660's doing the same as they do now).

Cheers.

I was wondering if a video card was like RAM and over time would lose it.

---

[/quote]

Old James

I've never noticed that happening on any of mine, but then I don't do AP's on my cards either.

Cheers.

Do anyone of "rebooters" have any numbers regarding possible memory leak (system or GPU) ?
[My own HD6950 + Q9450 host working under Vista x86 for weeks w/o reboots, same for x64 Windows7 C-60 netbook.
I reboot it only new system software installed.]

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Do anyone of "rebooters" have any numbers regarding possible memory leak (system or GPU) ?
[My own HD6950 + Q9450 host working under Vista x86 for weeks w/o reboots, same for x64 Windows7 C-60 netbook.
I reboot it only new system software installed.]

As mentioned before my old Q6600 w/ dual GTX660's running Win7 x86 with 4GB (3.5GB useable) of system memory would slowly lose free memory under SETI V7 which it didn't under V6, but I did mention it all the way back here http://setiathome.berkeley.edu/forum_thread.php?id=71913&postid=1384490.

I havn't noticed this with my Win7 64bit rigs, but then they do have 16GB of system memory.

Cheers.

In posted link you reference to SETI v7 CUDA
Surely you understand that SETI v7 (that is SETI v7 CPU, by default) and SETI v7 CUDA are quite different programs. Some precision in wording is vital here to address issue and have some chance to get it fixed.

So, it's nut to crack for our current CUDA team then

[I have no experience with such config, both my CUDA hosts are x64 ones, not x86]

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

In posted link you reference to SETI v7 CUDA
Surely you understand that SETI v7 (that is SETI v7 CPU, by default) and SETI v7 CUDA are quite different programs. Some precision in wording is vital here to address issue and have some chance to get it fixed.

So, it's nut to crack for our current CUDA team then.

Sorry about that, but yes it seemed to be the CUDA work that was causing the problem with that setup as while CUDA work was suspended the problem didn't happen.

The thing that I found strange was why V6 using x41zc didn't show any signs of that behaviour where as it was immediately noticeable under V7.

I hope that I've explained that a bit better this time.

Cheers.

My 2 with their 64bit OS's only get rebooted during the monthly updates, but when I had a 32bit rig it had to be rebooted every 4-5 days to release system memory since the intro of SETI V7.

Cheers.

I use cleanmem. It works for both 32 & 64 bit. Have been using it for over a year with no problems.

Cleanmem

---

In posted link you reference to SETI v7 CUDA
Surely you understand that SETI v7 (that is SETI v7 CPU, by default) and SETI v7 CUDA are quite different programs. Some precision in wording is vital here to address issue and have some chance to get it fixed.

So, it's nut to crack for our current CUDA team then.

Sorry about that, but yes it seemed to be the CUDA work that was causing the problem with that setup as while CUDA work was suspended the problem didn't happen.

The thing that I found strange was why V6 using x41zc didn't show any signs of that behaviour where as it was immediately noticeable under V7.

I hope that I've explained that a bit better this time.

Cheers.

I'd certainly be Interested to see the same condition isolated on a different x86 machine.

Failing that, As there is no application or Library difference when run on either x64 or x86. Next levels down are OS related, so I'd be looking for file corruption, like exe and dll damage, malware/AV infection and the likes, followed by system driver update and hardware checks.

[Edit:] Note that there have been a number of Windows graphics subsystem updates since the machine's nVidia 314.07 WHQL dated Feb 2013. If Windows updates were applied since that time, then needing the corresponding nVidia driver update may be a factor. [Cuda depends and interacts heavily with DirectX at driver level]

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

I'd certainly be Interested to see the same condition isolated on a different x86 machine.

Failing that, As there is no application or Library difference when run on either x64 or x86. Next levels down are OS related, so I'd be looking for file corruption, like exe and dll damage, malware/AV infection and the likes, followed by system driver update and hardware checks.

[Edit:] Note that there have been a number of Windows graphics subsystem updates since the machine's nVidia 314.07 WHQL dated Feb 2013. If Windows updates were applied since that time, then needing the corresponding nVidia driver update may be a factor. [Cuda depends and interacts heavily with DirectX at driver level]

I believe that I was using 275.xx back then, but that system is no longer available to me.

Cheers.

My 2 with their 64bit OS's only get rebooted during the monthly updates, but when I had a 32bit rig it had to be rebooted every 4-5 days to release system memory since the intro of SETI V7.

Cheers.

Wiggo, could you say exactly which number (seen with which monitoring tool) you are referring to?

I have one 32-bit Windows 7 machine I could monitor, but it's not a daily driver so I'd need to spot-check it. It runs 24/7 for a lot longer than 4-5 days, though.

My 2 with their 64bit OS's only get rebooted during the monthly updates, but when I had a 32bit rig it had to be rebooted every 4-5 days to release system memory since the intro of SETI V7.

Cheers.

Wiggo, could you say exactly which number (seen with which monitoring tool) you are referring to?

I have one 32-bit Windows 7 machine I could monitor, but it's not a daily driver so I'd need to spot-check it. It runs 24/7 for a lot longer than 4-5 days, though.

I'm not sure what you mean by, "could you say exactly which number", Richard, but I was monitoring the memory usage through the Task Manager and the problem may also relate to the setup running the 2x GTX660's with 3 running tasks on each, plus the variation in the time it took to get to the stage of having to reboot could also be due to the type of workunits being done (shorties verses normals).

Sorry James but I didn't mean to highjack your thread.

Cheers.

My 2 with their 64bit OS's only get rebooted during the monthly updates, but when I had a 32bit rig it had to be rebooted every 4-5 days to release system memory since the intro of SETI V7.

Cheers.

Wiggo, could you say exactly which number (seen with which monitoring tool) you are referring to?

I have one 32-bit Windows 7 machine I could monitor, but it's not a daily driver so I'd need to spot-check it. It runs 24/7 for a lot longer than 4-5 days, though.

I'm not sure what you mean by, "could you say exactly which number", Richard, but I was monitoring the memory usage through the Task Manager and the problem may also relate to the setup running the 2x GTX660's with 3 running tasks on each, plus the variation in the time it took to get to the stage of having to reboot could also be due to the type of workunits being done (shorties verses normals).

Sorry James but I didn't mean to highjack your thread.

Cheers.

Dont be sorry. Thats why I opened it. I might not post but I am reading and learning. And Im sure I will be asking more questions down the road. And I ask others who think they have a dumb question to ask also.
The only dumb question is the one not asked, As they say.

---

[/quote]

Old James

Has anyone else started seeing more validation inconclusives with wingmates running ATI open CL and CUDA 42 and 50?

---

[/quote]

Old James

Has anyone else started seeing more validation inconclusives with wingmates running ATI open CL and CUDA 42 and 50?

Perhaps here. I haven't characterised any pattern to the wingmates yet (device types etc), but noticed today my current inconclusive to pending ratios have risen from the earlier ~1 to 4% range, to the 4-7% range. That's still better than under V6, which was in the 10-15% realm here, but I guess an efficiency drop somewhere. Importantly, I suppose, the 3 machines I use do crunch with different application builds, have no invalids I've spotted, but show the same direction in validation changes... So something to look into, as devices & applications will keep diversifying.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.