Wave goodbye to the short-term cricket graphs for the gigabitethernet 6_17. I still don't understand why this is not working, it apparently has not been moved and either it is or is not part of the UC Berkeley network, why would that make any difference? It is was a useful tool to gauge server performance, why is it being hidden?

Probably because they are looking at other options right now.
I would imagine the IT guys are using a tool like Cisco Prime(or the older Cisco Works) for their internal needs. If the school year isn't yet over I imagine it is ending soon. Which would likely put the priority to replace the external graphing tools low on the list.

Thanks, much better than the last explanation I read. Although, as you suggest, it is unlikely to happen tomorrow...

If it happens before August I would be surprised.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Wave goodbye to the short-term cricket graphs for the gigabitethernet 6_17. I still don't understand why this is not working, it apparently has not been moved and either it is or is not part of the UC Berkeley network, why would that make any difference? It is was a useful tool to gauge server performance, why is it being hidden?

Probably because they are looking at other options right now.
I would imagine the IT guys are using a tool like Cisco Prime(or the older Cisco Works) for their internal needs. If the school year isn't yet over I imagine it is ending soon. Which would likely put the priority to replace the external graphing tools low on the list.

Thanks, much better than the last explanation I read. Although, as you suggest, it is unlikely to happen tomorrow...

If it happens before August I would be surprised.

Or it could be a simple matter of priorities, other things are more vital to keeping the program running at all.

---

"Sour Grapes make a bitter Whine." <(0)>

Watching the number of tapes to do rapidly declining. Will we be out of work by tonight?? hmmm...

Should be interesting to see.....

Watching the number of tapes to do rapidly declining. Will we be out of work by tonight?? hmmm...

Should be interesting to see.....

Heya Zalster, where do ya get to see the amount of work/tapes that are available to the project for crunching? Same goes for y'all saying that some AP's have been split and/or sent out...where do ya see that? Is there a link that y'all go to that you could share for me? :)

Thanks guys :)

- Akio

---

Akio, you can go here:

http://setiathome.berkeley.edu/sah_status.html

also available from the S@H web page as "Server Status Page" - referred to as SSP.

---

Member of the 20 Year Club

Hey Akio,

On the main front page of seti there is a section called "about" somewhere about 4-5 down it says "server status"

http://setiathome.berkeley.edu/sah_status.html

I personally have it bookmarked in my browser so I can just click and check what is going on.


Zalster

Wave goodbye to the short-term cricket graphs for the gigabitethernet 6_17. I still don't understand why this is not working, it apparently has not been moved and either it is or is not part of the UC Berkeley network, why would that make any difference? It is was a useful tool to gauge server performance, why is it being hidden?

Probably because they are looking at other options right now.
I would imagine the IT guys are using a tool like Cisco Prime(or the older Cisco Works) for their internal needs. If the school year isn't yet over I imagine it is ending soon. Which would likely put the priority to replace the external graphing tools low on the list.

Thanks, much better than the last explanation I read. Although, as you suggest, it is unlikely to happen tomorrow...

If it happens before August I would be surprised.

Or it could be a simple matter of priorities, other things are more vital to keeping the program running at all.

The bandwidth graph isn't part of the SETI@home project. It is generated by the Berkeley IST department for their "customers" to monitor. Matt indicated they have some internal tool to monitor things on their end. So they are not worried about it.
As I stated previously. I don't expect there is any priority on it.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

The bandwidth graph isn't part of the SETI@home project. It is generated by the Berkeley IST department for their "customers" to monitor. Matt indicated they have some internal tool to monitor things on their end. So they are not worried about it.
As I stated previously. I don't expect there is any priority on it.

My understanding was always that the cricket graphs were not supposed to be widely circulated, more like an Berkeley IT internal monitoring tool, one of which just happened to show 'our' cable and IT wasn't bothered too much by outsiders (i.e. us) accessing it. Sort of a grace thing.

As I understood Matt IT themselves are reevaluating cricket graphs (and at this point they are aware of a community interested in a particular cable). Maybe they themselves want a different monitoring tool. Or they don;t really like us peeking. There are probably several opinions. And several possibilities. So, fingers crossed, they decide to make this information publicly available again.
But as has been pointed out, summer break is approaching and publicly available monitoring is a low priority. We need them to have a little bit of slack time and the right frame of mind to bother with it.
Then again we might get lucky and somebody decides that's just the bit of infrastucture he'd like to tinker with instead of trying to fix some particularly nasty problem :D

---

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

The bandwidth graph isn't part of the SETI@home project. It is generated by the Berkeley IST department for their "customers" to monitor. Matt indicated they have some internal tool to monitor things on their end. So they are not worried about it.
As I stated previously. I don't expect there is any priority on it.

My understanding was always that the cricket graphs were not supposed to be widely circulated, more like an Berkeley IT internal monitoring tool, one of which just happened to show 'our' cable and IT wasn't bothered too much by outsiders (i.e. us) accessing it. Sort of a grace thing.

As I understood Matt IT themselves are reevaluating cricket graphs (and at this point they are aware of a community interested in a particular cable). Maybe they themselves want a different monitoring tool. Or they don;t really like us peeking. There are probably several opinions. And several possibilities. So, fingers crossed, they decide to make this information publicly available again.
But as has been pointed out, summer break is approaching and publicly available monitoring is a low priority. We need them to have a little bit of slack time and the right frame of mind to bother with it.
Then again we might get lucky and somebody decides that's just the bit of infrastucture he'd like to tinker with instead of trying to fix some particularly nasty problem :D

They are going to do what they are going to do.

My sincere wish is that they redirect the Cricket graphs to the new link, but I am not sure at all that they shall.

If they read this post, please be advised that it was a very good tool for some of us on the outside looking in to monitor exactly what was happening with the Seti servers at any given point in time.
It has allowed me to advise Eric or Matt of things going astray before they became a real issue.

I very much miss my Crickets, and I would be very grateful if they or some similar monitoring tool were made available again.

Please?

Meow?

---

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

The bandwidth graph isn't part of the SETI@home project. It is generated by the Berkeley IST department for their "customers" to monitor. Matt indicated they have some internal tool to monitor things on their end. So they are not worried about it.
As I stated previously. I don't expect there is any priority on it.

My understanding was always that the cricket graphs were not supposed to be widely circulated, more like an Berkeley IT internal monitoring tool, one of which just happened to show 'our' cable and IT wasn't bothered too much by outsiders (i.e. us) accessing it. Sort of a grace thing.

As I understood Matt IT themselves are reevaluating cricket graphs (and at this point they are aware of a community interested in a particular cable). Maybe they themselves want a different monitoring tool. Or they don;t really like us peeking. There are probably several opinions. And several possibilities. So, fingers crossed, they decide to make this information publicly available again.
But as has been pointed out, summer break is approaching and publicly available monitoring is a low priority. We need them to have a little bit of slack time and the right frame of mind to bother with it.
Then again we might get lucky and somebody decides that's just the bit of infrastucture he'd like to tinker with instead of trying to fix some particularly nasty problem :D

We were asked not to link directly to the images from the graphs, but the pages themselves are not a big secret. There is a public link provided to the list of graphs on this page http://www.net.berkeley.edu/. The information probably isn't highly useful to most outside of the Berkeley campus.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Blinked and you missed them......APs and they are gone.....

Blinked and you missed them......APs and they are gone.....

Crap...the kitties did not snag a one of them.

---

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

Crap. I didn't even know they've been available in the past few hours. I just checked like.. 3 hours ago and there was nothing yet.

Looked just now and there's one tape that is still being split, but the creation rate is still just "0/sec."

*sigh* Oh well. Guess I'll just keep seeing this for a while:

2015-05-28 03:16:48 SETI@home [sched_op_debug] CPU work request: 2592002.59 seconds; 3.00 CPUs
2015-05-28 03:16:49 SETI@home Message from server: No tasks are available for AstroPulse v7

---

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

There has been a couple of tapes go through with multiple splitters on each tape. Your chances of picking up an AP or two are pretty minimal unless you have dozens of machines.

Whenever I have seen a tape being split over the last few hours I have gone to AP only and nothing has landed here.

None of us would care to much about AP if they fixed the credit system. What is it now, almost 3 years and someone still refuses to acknowledge that it's broken or doesn't have the foggiest notion on how to fix it ...

---

My 2 rigs have been trying to get AP's for their CPU's all afternoon here (still none received), I can see those tapes being split, but results out in the field keep dropping so 1 has to wonder.

Why not just drop them in on bulk like before instead of the silly 1 file at a time?

In the meantime I'll just keep on smashing out MB's on the CPU's (and as always on my GPU's).

Cheers.

I'm almost wondering... those tapes that split, but don't seem to produce anything... is that a case of the splitters are running through and making WUs, but then checking against the DB and seeing "oh, I've done this one before, discarding it and moving on" ? That's about the only explanation I can think of for the reason why splitting happens, but the creation rate stays at 0 and nobody seems to get anything.

Although, on the other hand.. a few days ago, I snagged a few _0 and _1 WUs during one of those fast splits and the creation rate was shown as "0/sec," so... I don't know.

I do also know that the creation rate is not the raw output from the splitters, but merely a reflection of the.. transitioner (?) taking the output of the splitters and inserting them as available entries in the DB for the feeder to grab and send out to us.

---

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

I'm almost wondering... those tapes that split, but don't seem to produce anything... is that a case of the splitters are running through and making WUs, but then checking against the DB and seeing "oh, I've done this one before, discarding it and moving on" ? That's about the only explanation I can think of for the reason why splitting happens, but the creation rate stays at 0 and nobody seems to get anything.

Yes, Matt implied something like that a couple of months ago. From /dev/null (Mar 16 2015):

... turns out pretty much all the data in our queue was already split by Astropulse so only a few thousand workunits were generated. We broke the dam, but there was not much on the other side.

What happened to the 7.03 MB wu's? Me and woohoo would like to know. My GPU has had nothing to do since they disappeared.

---

What happened to the 7.03 MB wu's? Me and woohoo would like to know. My GPU has had nothing to do since they disappeared.

WUs are certainly available - they don't turn into v7.03 tasks until they reach your machine.

Did you (or Microsoft) update your video driver? The last task you completed says

Name: Bonaire
Vendor: Advanced Micro Devices, Inc.
Driver version: 1642.5 (VM)
Version: OpenCL 1.2 AMD-APP (1642.5)

but now BOINC is saying

Coprocessors AMD Bonaire (2048MB) OpenCL: 2.0

- that's a change from OpenCL 1.2 to OpenCL 2.0, and no driver version number.

What happened to the 7.03 MB wu's? Me and woohoo would like to know. My GPU has had nothing to do since they disappeared.

Hmmmm, a couple of us are having the same trouble at Beta. Seems we all have the same driver display;
AMD Bonaire (2048MB) OpenCL: 2.0 x2
AMD Hawaii (4096MB) OpenCL: 2.0 x6
AMD Cayman (2012MB) OpenCL: 1.2

Note how there isn't a Driver version listed.
These cards require the NoCAL Plan Class and that Plan appears to be missing.
Linux/x86_64 7.06 (opencl_ati5_cat132)
Linux/x86_64 7.06 (opencl_ati5_sah)
Linux/x86_64 7.06 (opencl_ati_cat132)
Linux/x86_64 7.06 (opencl_ati_sah)
I even changed from Catalyst 14.12 to 14.6 at Beta and it still didn't work.
http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2243&postid=54267#54267
Could Someone Please revive the NoCALs??

BTW, if you switch to Anonymous platform it will work....but that's kinda hard to do at Beta.