Did anyone see VLAR's crunch in a time which was anywhere near* the original estimate?

* For near I will accept a figure that is lower than twice initial estimate.

And quick note, since we stopped doing VLAR's the APR for the Opt app on my computer has gone up from ~180 to ~200. (the CUDA50 figure is ~170)

I did, but I modified my own Boinc to converge estimates locally very quickly without overshoot or ringing, So I probably don't count

I made a kick look on my hosts and most off the APR numbers are slowly converge to about 80-90% to the ones with V6, i belive that is good no?

@Jason Thanks for you pacience and help.

---

Fixed those Links, worth a look Juan

---

"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.

Fixed those Links, worth a look Juan

Sure i will do, the DPC Latency Checker i allready use (you show me that in the past, all off my hosts are allready in the "green" region), but now it´s 4:05 AM here, i need to sleep a little before go to work.

---

Fixed those Links, worth a look Juan

I haven't Black Vyper'd a rig in a long time.
Just don't have the time or ambition to lately.
When things were more CPU based, I'd spend a lot of time doing it.
Good to know he is still around.

The advice there was always sound.
Yes, it IS possible to kill a lot of unnecessary overhead in Windows...LOL.

---

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

Fixed those Links, worth a look Juan

I haven't Black Vyper'd a rig in a long time.
Just don't have the time or ambition to lately.
When things were more CPU based, I'd spend a lot of time doing it.
Good to know he is still around.

The advice there was always sound.
Yes, it IS possible to kill a lot of unnecessary overhead in Windows...LOL.

With your 'different rig, same hardware/setup, different behaviour' things happening Mark, the DPC Latency one will be worth a play with.

---

"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.

Fixed those Links, worth a look Juan

I haven't Black Vyper'd a rig in a long time.
Just don't have the time or ambition to lately.
When things were more CPU based, I'd spend a lot of time doing it.
Good to know he is still around.

The advice there was always sound.
Yes, it IS possible to kill a lot of unnecessary overhead in Windows...LOL.

With your 'different rig, same hardware/setup, different behaviour' things happening Mark, the DPC Latency one will be worth a play with.

You are probably most correct, Jason.
I am sure some of it comes down to the mobo and the RAM thingys.

I just don't know how deep into the bowels I can go anymore....
Maybe over the 4th of July holiday, when the fire truck factory is shut down for a week, I can dabble in some things I used to be more adept at.

---

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

Before i go to sleep...

I rememeber something, the absoulte maximum of the lantecy of the hosts that presents the video lag was in the range of 480us on the 670+690 and 520Us on the 2x690, compared with the same MB/CPU with a single 670 that was about 200us tops, all in the green area but clarely the 2GPUs hosts have a bigger number.

I will try to check the numbers again when i arrive at the ofice and even try to remove one of the GPu´s and see if the latency changes.

That could be explain why this hosts are more afected by the video lag from the vlars?

---

That could be explain why this hosts are more afected by the video lag from the vlars?

Possibly. Make sure when you compare again they run with the same apps, same settings, and same drivers. *sometimes* there are also ways to reassign interrupts if they are shared across slots, but only on the highest end mobos I think with extra slots(so you can move slots). If something like that turned out to be the case (genuine hardware limit) then it would justify hardware changes.

With DPCs it can be any device [driver] causing peaks, like chipset, even USB device or controller, sound card, or more likely network. As these things are software now, one poor driver can ruin the lot ( and a device that works doesn't mean it has a 'good' driver. )

On my machine that had DPC issues, I just disable everything I don't use in device manager, then those devices & slow drivers are out of the picture.

---

"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.

Haha, thanks. The problem is actually well understood, and demonstrated with the difference between 6.08 (unusable at all for VLAR) & 6.09 (operational at VLAR though not fantastic....) that nVidia was trying to solve it. One of their recommendations is to not use Cuda on an active display :-D... well it's us that pushes that boundary chossing to use GeForce for gpGPU instead of Tesla Compute clusters with no displays.

Actually, 608 - released 21 January 2009 - was the first one to run VLARs to completion without a BSOD. I think I ran the first one - an offline test at Beta, with a private drop of the app direct from NVidia - on my 9800GT. Before that, we'd gone through a rapid re-release cycle since the 604 launch app in December 2008.

-1
Just to annoy someone...
Cheers.

The Just to annoy someone... was worthy of a 2 digit IQ imbecile.
Apologies are in order.

I still stand by the -1. You almost never see them.

If Boinc is going to demand an anal retentive devotion from people who sign up as a lark, cost be damned, you'll lose 90% of your base.

The onus is on the project to make it "Set and Forget".

Runaway GPUs trashing each and every WU doesn't reflect poorly on the Owner, but rather on the Project for continuing to send WUs out.

Jheeze.