Another wacky weekend for us. Astropulse is still ramping up - we're creating work, sending it out, receiving results back and assimilating them. However the validator stopped granting credit for these workunits - something we'll fix and we can also retroactively give people their credit. The workunit storage server ran low on room again, the bottleneck that's been giving everybody headaches over the weekend as the splitters could only create work as fast as workunits got deleted off disk. Right now things are generally running slow as I'm moving stuff off the workunit server to make room causing lots of excess internal i/o. As an added bonus the mysql database replica server crashed this morning - it ran out of memory. No harm done, but it looks like it'll take a while to catch up again (it's been lagging behind all weekend). I would like to try to split the numbers on the status page between the two different applications (SETI@home/Astropulse) but those extra "where" clauses make the queries run forever.

In better news, looks like we got our new home-grown NAS/RAID box working as we'd like it, so we may start employing that sooner than later (thus freeing up lots of room/power in our server closet). Also all drive issues on our science database server over the past couple of weeks have been completely dealt with at this point. Well.. there's one lingering corrupted index which we'll try to rebuild tomorrow during the outage.

I was actually out of the loop since Thursday as I went up to Seattle to play a gig on the main stage at the Microsoft Techready conference at Bell Harbor. Anybody around here attend that thing? Fun show/event, but the stage tent was completely inadequate and the entire band got soaked by rain and sea mist. I'm amazed none of us were electrocuted.

- 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

I was actually out of the loop since Thursday as I went up to Seattle to play a gig on the main stage at the Microsoft Techready conference at Bell Harbor.

Sshhhhh! Nobody tell ML1 about this. Everybody, stand in front of the letters so ML1 can't read them. He doesn't have to know about this. :)

I was actually out of the loop since Thursday as I went up to Seattle to play a gig on the main stage at the Microsoft Techready conference at Bell Harbor.

Sshhhhh! Nobody tell ML1 about this. Everybody, stand in front of the letters so ML1 can't read them. He doesn't have to know about this. :)

Someone's got to do it, and they're welcome to fund some hardware. Might even be fun! Just watchout for the EULA...

Shame about the soaking.

Happy crunchin',
Martin

ps: Thanks for the special mention!

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

Well, if the disk is full because of all the WU's "in the wild" wouldn't those "Ghost WU's" for AstroPulse be a large culprit? I have just peeked at one of my hosts that has no work and the server side thinks it has 2 AP WU's. But it's running the AK 8.0 Opti App, and is not configured to run AP. So that's two of those "larger" WU's that will be sitting there for a month before it gets "No Reply"d out and hopefully processed by a more suitable host. :-)

If this is the case for even a small percentage of the hosts out there, we could find a significant amount of disk space tied up that'll wait a month before the system realizes it needs to go to some other host.

And I see at least on one of them, my wingmate is also running an older Opti App. (Which implies to me they don't even read the forums so they wouldn't know to have manually updated the app_info.xml.) So neither party will be returning that one.

EDIT: Then there's the other problem mentoned in the Number Crunching threads of hosts that shouldn't be getting work that suddenly are. Not the most eloquent of threads, but each host out there like this could also reflect a significant amount of WU's "in the wild" that won't come back until they miss deadline...

Well, if the disk is full because of all the WU's "in the wild" wouldn't those "Ghost WU's" for AstroPulse be a large culprit? I have just peeked at one of my hosts that has no work and the server side thinks it has 2 AP WU's. But it's running the AK 8.0 Opti App, and is not configured to run AP. So that's two of those "larger" WU's that will be sitting there for a month before it gets "No Reply"d out and hopefully processed by a more suitable host. :-)

Don't think so... there's not that many AP WU's out there, yet...

If this is the case for even a small percentage of the hosts out there, we could find a significant amount of disk space tied up that'll wait a month before the system realizes it needs to go to some other host.

And I see at least on one of them, my wingmate is also running an older Opti App. (Which implies to me they don't even read the forums so they wouldn't know to have manually updated the app_info.xml.) So neither party will be returning that one.

EDIT: Then there's the other problem mentoned in the Number Crunching threads of hosts that shouldn't be getting work that suddenly are. Not the most eloquent of threads, but each host out there like this could also reflect a significant amount of WU's "in the wild" that won't come back until they miss deadline...

---

.

Hello, from Albany, CA!...

Well, if the disk is full because of all the WU's "in the wild" wouldn't those "Ghost WU's" for AstroPulse be a large culprit? I have just peeked at one of my hosts that has no work and the server side thinks it has 2 AP WU's. But it's running the AK 8.0 Opti App, and is not configured to run AP. So that's two of those "larger" WU's that will be sitting there for a month before it gets "No Reply"d out and hopefully processed by a more suitable host. :-)

Don't think so... there's not that many AP WU's out there, yet...

But according to this post by Joe, an AP WU may be roughly 40 times the size of a MB WU. So wouldn't that consume that much more space on the Download Server while it's hanging around waiting to get returned? :-)

But according to this post by Joe, an AP WU may be roughly 40 times the size of a MB WU. So wouldn't that consume that much more space on the Download Server while it's hanging around waiting to get returned? :-)

AP WUs have exactly 32 times as much data as MB ones. The size is slightly less than 32 times since AP WUs use pure binary for the data section rather than having it broken up into lines, and the header is shorter too.

The 40.4 ratio for number of WUs is because MB WUs start at about 85 second intervals even though they have a duration of 107.37 seconds; that overlap means Gaussians, Pulses, or Triplets can be found reliably and don't get lost at the gap. AP is primarily looking for very fast stuff so isn't using overlap, at least in those I looked at on SETI Beta there wasn't any.

                                                                Joe