On the Farm (Feb 03 2010)

Nothing major to report, hence the lack of updates. We had our usual weekly outage yesterday for mysql maintenance. During that threw a newly compiled transitioner and scheduler into beta containing various bug fixes. The recovery was fine, though it's hard to tell as the network graphs (which are hosted by central campus, not us) seem to be broken at the moment.

We're actually having server closet temperature issues again as well. So I spent a chunk of time going around to various servers and implementing "sensors" to get more temperature data - want to make sure we're not being misled by a single server with a broken fan or something. Should have done this a while ago, but I can say that about pretty much everything I'm working on.

The science database is having a bit of a headache, mostly due to some extra Astropulse related analysis queries above and beyond the usual set of splitters/assimilators hitting the thing. We had to give it a kick an hour ago, and it recovered just fine (mostly since that kick killed the analysis query hogging all the i/o). We really need to improve this part of our server farm - when the NTPCkr is fully operational the science database is going to need all the juice it can get!

- 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 Matt

Question - Are the "astropulse" generally available to us yet? Would love to get some.

Thanks!


ront

Thanks for your response.

Will this improve in the forseeable future?

ront

Thanks for your response.

Will this improve in the forseeable future?

ront

If and when the bandwidth of Berkeley's connection is increased, then it may be. But at the moment trying to get more 8MByte downloads to us just cloggs up the connection and we all suffer.

Thanks for your response.

Will this improve in the forseeable future?

ront

Thanks for your response.

Will this improve in the forseeable future?

ront

If and when the bandwidth of Berkeley's connection is increased, then it may be. But at the moment trying to get more 8MByte downloads to us just cloggs up the connection and we all suffer.

If I recall, they are produced in a ratio of about 40:1 from the same tape.

Thanks for your response.

Will this improve in the forseeable future?

ront

If and when the bandwidth of Berkeley's connection is increased, then it may be. But at the moment trying to get more 8MByte downloads to us just cloggs up the connection and we all suffer.

If I recall, they are produced in a ratio of about 40:1 from the same tape.

What did I say in post 968033?

Thanks for your response.

Will this improve in the forseeable future?

ront

If and when the bandwidth of Berkeley's connection is increased, then it may be. But at the moment trying to get more 8MByte downloads to us just cloggs up the connection and we all suffer.

If I recall, they are produced in a ratio of about 40:1 from the same tape.

What did I say in post 968033?

I was under the impression that if the bandwidth was greater, that old data that has been processed with the enhanced MB app already, could be resurrected and put through the AP splitter using the s/ware filter. Including the data we have recently used when AP was switched off.
And in that case the organic reason of the 8 MByte and 350 KByte sizes would not apply.

I was under the impression that if the bandwidth was greater, that old data that has been processed with the enhanced MB app already, could be resurrected and put through the AP splitter using the s/ware filter. Including the data we have recently used when AP was switched off.
And in that case the organic reason of the 8 MByte and 350 KByte sizes would not apply.