I have similar for a batch of 06no10ab wu on one of my 460 rigs

i think its just a long running batch as rig is running fine - checked with a re boot and run a few work units from another batch and they run normally

just think its luck of the draw in that there is something about the data from the 6th November that takes longer to crunch

as everybody probably in the same position you will likely get more credit for the wu which hopefully will even things out - subject to the variability in the "new" credit system

---

Tim

Remember there is no solid boundary between "normal" WU's and VLAR's. It's a sliding scale. The lower the AR the longer it takes to crunch.

Without looking, I will guess that those WU's you noticed, probably have an AR of around 0.2. Not low enough to be an "official" VLAR but still pretty "chewy".

This is why I have the definition of VLAR in my Fred's Resched config file set to a VLAR "value" of 0.25.

T.A.

Remember there is no solid boundary between "normal" WU's and VLAR's. It's a sliding scale. The lower the AR the longer it takes to crunch.

Without looking, I will guess that those WU's you noticed, probably have an AR of around 0.2. Not low enough to be an "official" VLAR but still pretty "chewy".

This is why I have the definition of VLAR in my Fred's Resched config file set to a VLAR "value" of 0.25.

T.A.

Which wouldn't have caught the AR=0.275245 I found in jravin's reported results. While we have these unusual ARs in the mix, it would be helpful if the generalised moaning could be supplemented with some actual facts - and it's much easier for the owner of the rig, noticing slow progress, to record the name of the WU, and find it - either using Sutaru's technique before reporting has taken place, or my technique afterwards.

Remember there is no solid boundary between "normal" WU's and VLAR's. It's a sliding scale. The lower the AR the longer it takes to crunch.

Without looking, I will guess that those WU's you noticed, probably have an AR of around 0.2. Not low enough to be an "official" VLAR but still pretty "chewy".

This is why I have the definition of VLAR in my Fred's Resched config file set to a VLAR "value" of 0.25.

T.A.

Which wouldn't have caught the AR=0.275245 I found in jravin's reported results. While we have these unusual ARs in the mix, it would be helpful if the generalised moaning could be supplemented with some actual facts - and it's much easier for the owner of the rig, noticing slow progress, to record the name of the WU, and find it - either using Sutaru's technique before reporting has taken place, or my technique afterwards.

The WU's had not bothered me enough to worry about them, as stated above I know that not all WU's are equal, I only mentioned them in responce to the OP's post.

I also had at the same time a number of shorties, not VHAR's but almosts. So the number of WU's processed over a given time was probably around the same amount, If Bruno had not had problems I would not have even noticed it.

I will take the bad with the good, I am not fussy if I get a bit of slow work with the fast, the only things that I want to do is to keep this machine processing efficiently and to make sure that I produce the minimum of errored and invalid WU's.

Kevin

---

Kevin

FYI: I checked one of the "slow" WUs after completion, and it is indeed claiming more credit (197.50). Don't know if it will be granted, but this makes sense in terms of the flops (59xxxxx....).

Run time: 32xx secs

Task: 1777838658
WU: 683754425

AR: 0.279653

EDIT: Checking further, in my valid WU list, it seems to sometimes grant 100+ credits and sometimes not. So now I'm even more confused. Aaaarrrrggggghhhhh!!!!!!

---

Life is full of arrrrrrgggggggggggghhhhhhhhhhhhhhs.

---

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

I got several WUs with 0.25 AR, but except longer completion time, GPU utilization was as usual.[/b]

---

Which wouldn't have caught the AR=0.275245 I found in jravin's reported results. While we have these unusual ARs in the mix, it would be helpful if the generalised moaning could be supplemented with some actual facts - and it's much easier for the owner of the rig, noticing slow progress, to record the name of the WU, and find it - either using Sutaru's technique before reporting has taken place, or my technique afterwards.

if you want specifics Richard

don't think people are moaning just querying why things are running slower than usual and if they have a problem that others might have seen and know why etc


http://setiathome.berkeley.edu/results.php?hostid=5708832&offset=220&show_names=1&state=2&appid=

you will see a batch of wu for 06no10ab.29745.22153.3.10.xxx that are running long - like 50% longer than "usual"

ar is approx 0.167 so almost a vlar - so it probably accounts for it although never seen wu run this long before in the six months i have had 460's

these are running on 460's oc to 850/1700/2000 - with 3 wu at once - usual time would be approx 30 mins these are running at 45mins

if you want any more info let me know!

:)

---

Tim

Which wouldn't have caught the AR=0.275245 I found in jravin's reported results. While we have these unusual ARs in the mix, it would be helpful if the generalised moaning could be supplemented with some actual facts - and it's much easier for the owner of the rig, noticing slow progress, to record the name of the WU, and find it - either using Sutaru's technique before reporting has taken place, or my technique afterwards.

if you want specifics Richard

don't think people are moaning just querying why things are running slower than usual and if they have a problem that others might have seen and know why etc

:)

I see your :), Tim, and I know we're on the same wavelength.

But no, I don't want specifics.

Two sets of people are asking for specifics:

1) The people with the (possible) problem. If they want to know 'why', as you suggest, we really do have to know enough about what they're seeing to make an informed judgement.

2) The developers of the application(s). If their program behaves oddly under unexpected or unusual situations, they'll want to correct it. But again, they need to know exactly what is unusual about the situation.

The suggestion this problem might be AR-related was covered, although slightly obliquely, in the first reply to this thread. But nobody followed through with any real data, or bothered to look....

I´m not sure Richard.
I noticed the same on my host.

My 5850 finnish a normal 0.42 unit in 25-35 minutes running 2 paralell.
I had ~ 20 units with same AR running over 50 minutes.
Most of them are already purged now but i think i have another one.
My first guess was the problem is on my end but i dont think so anymore.


http://setiathome.berkeley.edu/result.php?resultid=1778855091

http://setiathome.berkeley.edu/result.php?resultid=1778214897

http://setiathome.berkeley.edu/result.php?resultid=1778214644

---

With each crime and every kindness we birth our future.

Been doing some further checking, looks like the GPU slowdown in my case was being caused at least partly by other factors.

It seems that running Einstien on CPU slows down GPU performance, even when reducing from 4 to 3 CPU units.


I had previously noticed a slowdown on CPU performance since upgrading my GPU's, this was when doing SETI WU's, I have not tried doing just GPU WU's so I do not know if maxing the CPU with SETI slows GPU WU's, but it looks like when running Einstien CPU WU's they don't like letting the GPU's have as many CPU resources as they want, causing them to slow down.

I think I may reduce the amount of other work I do.

Kevin

---

Kevin