As I recall there were some NV cards that really REALLY didn't like VLARs & could cause a system to lock up. I want to say that those with 500 series NV cards reported little or no problems with VLAR tasks, but it might have been the 600 series.

Yep, my 470's, they can handle 1 VLAR at a time, 2 causes slowdowns etc and 3 will cause lockups.

I have reverted back to 1 task at a time.

That's what I've figured and only a very small percentage of us actually tune our rigs to well above the average users' default settings (the greatest majority of users) so it's really only a very small percentage of us that the VLAR to GPU problem effects.

This really should be made a selectable option as to whether you allow VLAR's to GPU or not (promised to us a long time ago now).

Most of those doing VLAR's on GPU may not even know how badly they're worth credit wise either.

Anyhow I'll go and check to see if I've received anymore in the last 2hrs for my GPU's to abort. ;-

Cheers.

As I recall there were some NV cards that really REALLY didn't like VLARs & could cause a system to lock up. I want to say that those with 500 series NV cards reported little or no problems with VLAR tasks, but it might have been the 600 series.

Yep, my 470's, they can handle 1 VLAR at a time, 2 causes slowdowns etc and 3 will cause lockups.

I have reverted back to 1 task at a time.

That's what I've figured and only a very small percentage of us actually tune our rigs to well above the average users' default settings (the greatest majority of users) so it's really only a very small percentage of us that the VLAR to GPU problem effects.

This really should be made a selectable option as to whether you allow VLAR's to GPU or not (promised to us a long time ago now).

Most of those doing VLAR's on GPU may not even know how badly they're worth credit wise either.

Anyhow I'll go and check to see if I've received anymore in the last 2hrs for my GPU's to abort. ;-

Cheers.

It seems to be really messing with the kitty farm.....
But I'm just gonna have to let them slog through it.
Searching through 2200 GPU WUs on 9 rigs to slay the offenders just ain't happenin'.

---

"Time is simply the mechanism that keeps everything from happening all at once."

I don't care for them (vlars) and the credit given for the amount of time spent crunching them varies as well


Run time CPU time credit
3972409226 Completed and validated 5,678.69 171.32 213.93 SETI@home v7


3972630906 Completed and validated 5,755.46 169.73 198.24 SETI@home v7

These are the highest I've seen so far.

I've had some run 7000 sec and only get around 124 credit so there is not a good rhyme or reason to them.

Eric is working to repatch the server code update that broke things and released the VLARs to GPUs again.
His first attempt didn't take, but he is still working on it.

Meow!

---

"Time is simply the mechanism that keeps everything from happening all at once."

As I recall there were some NV cards that really REALLY didn't like VLARs & could cause a system to lock up. I want to say that those with 500 series NV cards reported little or no problems with VLAR tasks, but it might have been the 600 series.

Yep, my 470's, they can handle 1 VLAR at a time, 2 causes slowdowns etc and 3 will cause lockups.

I have reverted back to 1 task at a time.

That's what I've figured and only a very small percentage of us actually tune our rigs to well above the average users' default settings (the greatest majority of users) so it's really only a very small percentage of us that the VLAR to GPU problem effects.

This really should be made a selectable option as to whether you allow VLAR's to GPU or not (promised to us a long time ago now).

Most of those doing VLAR's on GPU may not even know how badly they're worth credit wise either.

Anyhow I'll go and check to see if I've received anymore in the last 2hrs for my GPU's to abort. ;-

Cheers.

It seems to be really messing with the kitty farm.....
But I'm just gonna have to let them slog through it.
Searching through 2200 GPU WUs on 9 rigs to slay the offenders just ain't happenin'.

Thankfully I only have 2 mid-range rigs to look after here Mark. ;-)

I don't care for them (vlars) and the credit given for the amount of time spent crunching them varies as well


Run time CPU time credit
3972409226 Completed and validated 5,678.69 171.32 213.93 SETI@home v7


3972630906 Completed and validated 5,755.46 169.73 198.24 SETI@home v7

These are the highest I've seen so far.

I've had some run 7000 sec and only get around 124 credit so there is not a good rhyme or reason to them.

Yes, they just don't agree well with those of us with well tuned Nvidia cards, but sadly we're only a very small minority in the grander scale of things which is why several of us (an even smaller percentage of us) would rather see VLAR's set as an option whether to run as a computing option so that some of us can turn them off that way. ;-)

Cheers.

There have been a few blue spikes come through on router 8_34 I wonder what that is about. My guess is perhaps internal traffic

---

There have been a few blue spikes come through on router 8_34 I wonder what that is about. My guess is perhaps internal traffic

I dunno. What, pray tell, does that link monitor?
I generally only look at 6_17 Seti server traffic.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Eric says the VLAR/GPU server problem should be fixed now.
If anybody sees more VLAR tasks arriving in their GPU caches, please post about it.

---

"Time is simply the mechanism that keeps everything from happening all at once."

[quote]Just how big is the AP database, anyway?

Not sure. Not too long ago, I noted that the AP DB is ~4.5 TB..at least.

If that was the case, then the data transfer should have been done in roughly 15 hours at ~725Mbit. So... I don't know what's going on now. Could be that the MB DB is being copied, too, and that one is quite likely to be well over 10 TB.

Seeing as our normal inr-211/6_17 link is also carrying the outbound traffic to us, we can't really use that to get a decent estimate of the extra payload.

Thanks to Joe's digging, inr-304/8_34 shows what is actually going up to the lab.

The massive transfer started at ~1100 PST on Tuesday. Just as an eyeballed estimate, I'm going to say the average for the past 50 hours appears to be ~700Mbit.

700000000/8*3600*50/2^40 = 14.32 TiB.

Here you go Mark 8_34 as data actually going up to the lab from the servers that provide us with work. So I doubt it would be internal traffic

---

Interesting. Compare 8_34 to 6_17

---

"Time is simply the mechanism that keeps everything from happening all at once."

Grant (SSSF) wrote:

Both my systems now have some GPU work.
Most requests for work result in "Project has no tasks available" messages. Given the length of the outage & the lack of any AP work I think that will be the case for a fair while yet as the feeder struggles to meet the demand.

ivan wrote:

Well, as of 2042 UTC, all my machines have their full quota of MB tasks, except for my Celeron J1900 which I switched from Linux to Windows 10 on Monday. It's not done enough GPU jobs yet to have its performance quantified (currently its GPU is running at 70 or 80% of a single CPU core, but the CPU is reportedly running at 2.4 GHz, for a 2 GHz part!).

Intel® Celeron® Processor J1900
Burst Frequency 2.41 GHz

---

What about 'Intel GPUs'?
Normally they could get .vlar's, or not?

My 'Intel GPU' got .vlar's at:
14 Feb 2015, 0:39:24 UTC and
14 Feb 2015, 6:40:35 UTC

---

What about 'Intel GPUs'?
Normally they could get .vlar's, or not?

My 'Intel GPU' got .vlar's at:
14 Feb 2015, 0:39:24 UTC and
14 Feb 2015, 6:40:35 UTC

I would have to ask Eric....
Let you know.

Meow.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Eric says the VLAR/GPU server problem should be fixed now.
If anybody sees more VLAR tasks arriving in their GPU caches, please post about it.

Looks good so far, no VLARs in the last half dozen or so GPU work requests.

---

Grant
Darwin NT

Eric says the VLAR/GPU server problem should be fixed now.
If anybody sees more VLAR tasks arriving in their GPU caches, please post about it.

Looks good so far, no VLARs in the last half dozen or so GPU work requests.

Thanks, Grant. Same here so far. Looks like Eric's got that one fixed again.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Eric says the VLAR/GPU server problem should be fixed now.
If anybody sees more VLAR tasks arriving in their GPU caches, please post about it.

Looks good so far, no VLARs in the last half dozen or so GPU work requests.

The same here so far too. :-)

Cheers.

Sorry if it's been asked and answered before, but what's going on with AP creation and validation?

---

Eric says the VLAR/GPU server problem should be fixed now.
If anybody sees more VLAR tasks arriving in their GPU caches, please post about it.

Looks good so far, no VLARs in the last half dozen or so GPU work requests.

The same here so far too. :-)

Cheers.

Looking good then...
The kitties will chew up and spit out what is left in the crunchers' caches and then be back on track.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Sorry if it's been asked and answered before, but what's going on with AP creation and validation?

The AP database crashed badly and is in the process of being rebuilt/recovered.
I have word that everything should be recoverable and that is being done offline.
Hopefully we shall have the AP portion of the project back for us in a couple of weeks....

---

"Time is simply the mechanism that keeps everything from happening all at once."

Thnx

---