Oh dear, I see 20jn12ac is still hanging around, stuck with loads of errors :-(

---

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

@Gary - THANKS! That explains why I7-3820 (my new cruncher) wasn't even asking for WUs except when nearly empty. I changed the settings per your suggestion, and the machine promptly loaded up to the limit.

---

Oh dear, I see 20jn12ac is still hanging around, stuck with loads of errors :-(

It certainly isn't giving in, is it?

Cheers.

Splitters still having issues. Ready-to-send buffer continues to shrink with the splitters unable to produce enough work. Could run out of work yet again all within 24hors of last running out.

---

Grant
Darwin NT

Splitters still having issues. Ready-to-send buffer continues to shrink with the splitters unable to produce enough work. Could run out of work yet again all within 24hors of last running out.

Well, that stuck dataset 20jn12ac is not helping anything. Tying up one MB splitter that is not producing WUs.

Eric said that Matt had restarted it. It apparently is still in terminal fail mode. I send Eric another message, and we'll have to wait until tomorrow to see if they kick it again or just boot the sucker.

---

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

Was just looking through my single-core machine's recently-reported v7 WUs and saw a cool one. 1265536732

The beginnings of an inconclusive train. I guess build 1846 and stock CPU app didn't quite agree with each other..? Its obvious cuda32 just completely got it wrong. It'll be interesting to see what happens when cuda50 gives it a whirl.

edit: and then I looked into it more.. the cuda32 attempt is a runaway machine. hostid 6721035. PMed to inform them and pointed to NC to ask for solutions for fixing it.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

Was just looking through my single-core machine's recently-reported v7 WUs and saw a cool one. 1265536732

The beginnings of an inconclusive train. I guess build 1846 and stock CPU app didn't quite agree with each other..? Its obvious cuda32 just completely got it wrong. It'll be interesting to see what happens when cuda50 gives it a whirl.

edit: and then I looked into it more.. the cuda32 attempt is a runaway machine. hostid 6721035. PMed to inform them and pointed to NC to ask for solutions for fixing it.

Wish we'd get behind why some hosts don't print stderr... bloody annoying that.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

I only just noticed it, but it looks like we hit another record after todays outage.
691Mb/s download traffic.

---

Grant
Darwin NT

Was just looking through my single-core machine's recently-reported v7 WUs and saw a cool one. 1265536732

The beginnings of an inconclusive train. I guess build 1846 and stock CPU app didn't quite agree with each other..? Its obvious cuda32 just completely got it wrong. It'll be interesting to see what happens when cuda50 gives it a whirl.

edit: and then I looked into it more.. the cuda32 attempt is a runaway machine. hostid 6721035. PMed to inform them and pointed to NC to ask for solutions for fixing it.

And the cuda50 task came back and agreed with both CPU apps.

Looks like the runaway host was doing the thing the server is set to do.. send a few (thousand?) tasks to each type of app and see which works best. 32 obviously didn't work, 42 isn't working either, and 50 isn't showing any promise, either. Bad drivers, or a bad card is what I'm thinking. Or it could just be some other environment misconfiguration. Hard telling.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

@Gary - THANKS! That explains why I7-3820 (my new cruncher) wasn't even asking for WUs except when nearly empty. I changed the settings per your suggestion, and the machine promptly loaded up to the limit.

Welcome.

I think a lot of people are getting caught by this and don't realize it.

---

Network traffic graph is interesting at the moment- it's got to be the flatest (while the system is running) that i can recall.

---

Grant
Darwin NT

Isn't it time now to finally kick that 20jn12ac file? It's been sitting there, stuck for over a week now, holding up one splitter from doing useful splitting.

I poked Eric about it again....
Dunno if he's in the lab right now or not.

---

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

Network traffic graph is interesting at the moment- it's got to be the flatest (while the system is running) that i can recall.

At least untill the huge spike went off the 24hr graph. Still, while up & down there aren't any huge spikes or dips in it.

---

Grant
Darwin NT

And while they are loading some new tapes perhaps they can do something about poor old 20jn12ac which has been stuck at this:
20jn12ac 50.20 GB (13) (done)

For days.

---

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

And while they are loading some new tapes perhaps they can do something about poor old 20jn12ac which has been stuck at this:
20jn12ac 50.20 GB (13) (done)

For days.

They have done something about it. There has not been a splitter running on that file for several days. Still listed on the page, but not being processed.

---

Donald
Infernal Optimist / Submariner, retired

Good job, anonymous wingmate. I appreciate you aborting your AP on the CPU and making too many errors to validate. workunit 1266348384

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

No new APs being split for a long time now. I'm beginning to panic, getting nervous.

Please, please.....

Same near panic here... If I read the status page right, there seems to be a lot of MBs being split before we get APs again.

Quite simple - it takes a lot less time to split the APs off a tape than to split the MBs off the same tape.

---

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

Quite simple - it takes a lot less time to split the APs off a tape than to split the MBs off the same tape.

There are also a lot more folks doing AP on GPU since the v7 and Lunatics installer rollouts. So the APs get crunched and returned faster than they used to be, hence they do not last as long when they are available.

The kitties were not doing them on GPU until the Lunatics release.

---

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

More like more people are doing AP's so that they can get a better RAC happening.

Don't worry Sten, I'll keep trying my best to chew through those MB's so more files can be loaded.

Cheers.