High Score (Mar 27 2012)

Another outage day (for database backups, maintenance, etc.). Today we also tackled a couple extra things.

First, I did a download test to answer the question: "given our current hardware and software setup, if we had a 1Gbits/sec link available to us (as opposed to currently being choked at 100Mbits/sec) how fast could we actually push bits out?" Well, the answer is: roughly peaking at 450 Mbits/sec, where the next chokepoint is our workunit file server. Not bad. This datum will help when making arguments to the right people about what we hope to gain from network improvements around here. Of course, we'd still average about 100Mbits/sec (like we do now) but we'd drop far less connections, and everything would be faster/happier.

Second, Jeff and I did some tests regarding our internal network. Turns out we're finding our few switches handling traffic in the server closet are being completely overloaded. This actually may be the source of several issues recently. However, we're still finding other mysterious chokepoints. Oy, all the hidden bottlenecks!

We also hoped to get the VGC-sensitive splitter on line (see previous note) but the recent compile got munged somehow so we had to revert to the previous one as I brought the projects back up this afternoon. Oh well. We'll get it on line soon.

We did get beyond all the early drive failures on the new JBOD and now have a full set of 24 working drives on the front of it, all hooked up to georgem, RAIDed up and tested. Below is a picture of them in the rack in the closet (georgem just above the monitor, the JBOD just below). The other new server paddym is still on the lab table pending certain plans and me finding time to get an OS on it.



Oh yeah I also updated the server list at the bottom of the server status page.

- Matt

____________
-- BOINC/SETI@home network/web/science/development person
-- "Any idiot can have a good idea. What is hard is to do it." - Jeanne-Claude

Thanks for the update Matt,

Claggy

Thanks for the update Matt,

Claggy

We also hoped to get the VGC-sensitive splitter on line (see previous note) but the recent compile got munged somehow so we had to revert to the previous one as I brought the projects back up this afternoon. Oh well. We'll get it on line soon.

Great work on the bottleneck testing....
Now, time for more bandwidth!

Meow!
____________
******

"Ask not, what your kitty can do for you. Ask what you can do for your kitty."

As it is kitten, so shall it be done.

We also hoped to get the VGC-sensitive splitter on line (see previous note) but the recent compile got munged somehow so we had to revert to the previous one as I brought the projects back up this afternoon. Oh well. We'll get it on line soon.

Why isn't this being tested on Beta? (NTM: Why wasn't AP v6.0 tested on Beta?) I thought testing of this sort was what Beta was for?

but... but .. but ... i m there now :)


just have to feed me up ^^


j/k

EDIT: How many AP a tape has ?
____________

wow ! so 4700 tasks

if we considare that 1 task takes a median of 1hr with gpu... it would gives 4700 hrs of works. sweet thanks you.
____________

ya but cant get the _0 and _1 in same time on same PC for the same WU :)
____________

SETI does have a small cache of 3TB drives used for Astropulse Reob data.
____________


Executive Director GPU Users Group Inc. -
brad@gpuug.org

ya but cant get the _0 and _1 in same time on same PC for the same WU :)

Exactly why I said "two people" and "assume everyone uses a GPU." :P

Astropulse v6 testing started at Beta early last December, and has been more or less continuous since late January. For all of that testing, new splitter code had to be in place with the sign difference which was the primary reason for a new version of Astropulse. Changes to the Validator to reliably sense tasks with abnormal runtimes took place more recently, and a trivial change of the application was needed to support that, hence the release is version 6.01.

There are usually less than 4000 active hosts working Beta, and many of those with a fairly low resource share. One tape file typically lasts a month, a far different situation than here where the data flow is much higher. Issues like how many splitters are needed to supply demand cannot be checked at Beta, and using VGC-sensitive splitters there would probably reduce the variations which makes beta testing of applications useful. Whether they may have been used to split some channels I don't know, it's certainly possible though I think unlikely.

[quote]ya but cant get the _0 and _1 in same time on same PC for the same WU :)

Exactly why I said "two people" and "assume everyone uses a GPU." :P

I just started this I have decide you my failover datacenter to help out with the crunching. I am running it on grid of 6 vSphere 5 ESX servers running on Dell m1000e Blade Chassis with M610 blades. I cloned VMs what I call seti@home machines and let them run a 100% 24x7. I have been doing this a week I have 81,681 credits. A problem I have is am not being fed jobs fast enough to tap my servers out 24x7.