|
Switch Completed
The TLC site has had the DNS switched over to IronBits' server. The
DNS was actually switched sometime last week, and has been hosted there
since then. Right now the site is still being mirrored at Hagabard's
server tlc.hagabard.com.
For the time being, if the main TLC site is down, the complete stats
can be found on Hagabard's mirror. Again, thanks go out to both
Hagabard and IronBits for hosting the TLC stats!
Version 3.04 Soon?
I have heard that there is a new client being worked on, but I have no
idea on a timetable for release. The bug that is being fixed is the
one explained in the news from the 18th (scroll down a bit). Not
sure if it is going to be mandatory either.
S@H Problem Last Week
There was a problem with the servers last week. Some people had
results uploaded and didn't get credit for them, and then their client was
squawking at them "state.sah not found" and would loop
endlessly. SetiQueue seemed to protect from this problem, since it
didn't end up uploading any results because it couldn't connect
properly. Eric Korpela explained the problem on the newsgroups:
Here's what the problem was...
The science database has been down in preparation for an informix
upgrade.
The results are being stored on a new disk. Enough results
accumulated that
the device ran out of inodes. Because of that results were
building up in
temp space, which also ran out of inodes. Without space for
temporary files,
very little was functioning.
Galactic Habitable Zones
In this month's Scientific American there is an article that
describes Galactic Habitable Zones (GHZ). The GHZ is analogous to
the solar habitable zone which extened from outside Venus to outside
Mars. The GHZ's boundaries are kind of loosely defined for the Milky
way, the outer boundary is defined by the the metallicity of the stars in
the region. The probability of forming terrestrial type planets is
proportional to the metallicity of the parent star. The outer
portions of the milky way have a lower rate of supernova and therefore
have less metals, although the metallicity of the outer regions is
increasing with time.
The inner bounds of the GHZ is determined by several
factors. The closer to the center of the Milky Way the closer stars
and clusters are and the higher chance for interactions which may cause
comets and other debris to rain down on a developing solar system.
There is also increased galactic radiation from the center of the galaxy
and also from the increased supernova frequency.
With the inner and outer boundaries of the GHZ, this
significantly reduces the potential number of planets which may harbor
intelligent life. It would be interesting to see if the GHZ has been
taken into account in formulating the Drake Equation, and if it wasn't,
how it would affect the theoretical number of planets that harbor
intelligent life.
Site News
The TLC site here is going to be moving, but hopefully the move
will be seamless. For the last couple of months Hagabard
has been hosting the TLC site on his server. The server will be
moving over to a server hosted by IronBits
(IB). We are working on getting the servers ready and my excel
scripts straightened out before we move the tlc.com domain over. We
will still be using Hagabard's server as a mirror for the stats for the
time being. When the switch is made, the mirror will be available at
tlc.hagabard.com. It is
the same site as the tlc.com site is right now. If my uploads go
alright today (Tuesday)...the switch over to IB's server may come as soon
as Tuesday afternoon/night. If for some reason the DNS switch
doesn't go as planned, IB's site can be reached at tlc.dbestern.net.
Hopefully the move will be seamless and you will never know anything is up
with the change! I would like to thank both Hagabard for the hosting
over the past couple of months, and IB for the future hosting of the stie!
S@H News
There has been a bit of updates on the S@H site, with a new wealth of
information for your perusal. The first item of note is a technical
news report dated Sept
12th from the news item:
We have recently diagnosed a long-standing
problem: certain work units never get results returned. There are at
least two cases: 1) if a work unit produces a result file larger than 60
KB, the client silently discards the result file and fetches a new work
unit; 2) if a work unit has corrupt data, the client immediately
discards it. In both cases the user doesn't receive credit for
processing the work unit.
Because our server never gets results for these
work units, they remain on disk indefinitely, and are sent over and over
again to clients. Users aren't getting credit for an increasing fraction
of the work units they complete.
As a short-term solution, we are purging old
work units from our server. This will hopefully reduce the fraction of
"uncredited" work units close to zero. Longer-term, we will
fix the client so that it handles large result files correctly. We hope
to have this fix in the Unix and command-line versions soon, and in the
Windows and Mac versions after that.
Notice the bold portion of the news item. It looks
like this problem may be alleviated by tweaking the S@H client a
bit. This sounds like they will end up coming out with a new version
of the client. Will this be a forced upgrade? I am not sure.
Seeing that it may be a minor fix it *may* not be a required
upgrade....but they may find other things to fix in the client if they are
going to do the work of making a new client and porting...but don't expect
them to tweak the client for more speed.
Second up is a glossary
for different terms used in the project. It has definitions for
different terms, plus some links which describe the terms a bit better.
Next, there is a post
that Norton personal firewall may be kicking in when sending back results
to the Berkeley servers:
Spurious error messages from Norton
Personal Firewall
We have received problem reports from SETI@home
users running Norton Personal Firewall (NPF). NPF checks outgoing HTTP
requests for character strings, such as parts of your credit card
numbers.
SETI@home uses HTTP to download work units and
upload results. Each result consists of about 5,000 characters, mostly
numbers. Any short sequence of digits occurs occasionally in result
files.
- If you have configured NPF to check for
several 4-digit sequences, there is significant chance that at least
one of these sequences will randomly occur in a result file. NPF
will then tell you that SETI@home is uploading one of your credit
card numbers. This is not the case.
We recommend that SETI@home users configure NPF to
check for longer digit sequences (8-12 digits). This will greatly reduce
the incidence of spurious error messages.
Finally, they have posted a new newsletter (#9)
describing "Persistent
Signals". Why is persistence important? Well a
signal needs to be verified. If a gaussian shows up once and not in
another pass of the same portion of the sky, then that signal is most
likely not of importance....but if the signal is still there when they
scan the same portion of the sky, then it *may* be of extraterrestrial
origin. The article shows some of the different graphs of some plots
and shows how they may throw out a result because of local radio frequency
interference. There is some good stuff in there...I highly recommend
that ya read it.
New
Hopefully if everything goes ok with the update today there will be a new
set of charts available using the drop down menus. These charts show
ONLY the active members on the team (member who have returned at least one
work unit in the past 7 days). The charts are a bit different from
the other member charts but should provide some more information for those
stats freaks on TLC :). I may come up with some graphs for the
active members, but just not this moment...it may take some fiddling with
my excel charts to get them to work right. Also I updated the weekly
stats for those of you who are interested!
Tragedy
I am sure most of you have heard about the terrorist activities that
occurred in NYC, Washington DC, and Pennsylvania. My hearts and
thoughts go out to all of the people who were effected by the events that
happened yesterday. I want to reiterate what Caesar has posted on
the Ars Technica site on how people can help.
Many of you are writing in asking
how you can help. First of all, give blood if you can. Simply call
1-800-GIVE-LIFE to see where you can give blood, and if you are
eligible. According to the Red Cross, your blood donation could save as
many as three lives. Please consider this. Secondly, please donate
money to the American Red Cross. You can donate
using this link, which uses Amazon's payment system (and hence is
convenient for many), or you can donate
at the Red Cross site. Ars Technica and its staff are making
donations, and I hope you will too. Right now that system is reporting
that they've collected $2880.00. Let's move that up, OK? -Cæsar
As of this time the relief fund (through Amazon) has
collected over $113,000. Please help the relief and rescue efforts
if you can.
-Front Page |
