Posts by Andy Lee Robinson

21) Message boards : Number crunching : 62 AP_V5 Left In The Field (Message 1242242)
Posted 6 Jun 2012 by Profile Andy Lee Robinson
Post:

Report deadline 9 Jun 2012 | 8:49:09 UTC


Received 6 Jun 2012 | 12:17:25 UTC

Server state Over
Outcome Success
Client state Done
Exit status 0 (0x0)
Computer ID 6259723
Report deadline 9 Jun 2012 | 8:49:09 UTC
Run time 456,056.73
CPU time 417,734.70
Validate state Task was reported too late to validate
Credit 0.00
Application version Astropulse v505 v5.05


Err... Received 6 Jun, report deadline 9 Jun - it was returned within the period, so why too late to validate?

An AMD E350 is a silly processor to use on Boinc, but IMHO it still should have validated.
22) Message boards : Number crunching : SAH On Linux (Message 1240631)
Posted 3 Jun 2012 by Profile Andy Lee Robinson
Post:
This should renice the cpu/gpu threads as a simple command:

for i in $(ps -C setiathome_x41g -o pid=); do renice -n 0 $i; done;

I guess it could be added to /etc/crontab to run every minute:
* * * * * root sleep 10; (for i in $(ps -C setiathome_x41g -o pid=); do renice -n 0 $i; done;)

Not sure how much benefit it really is, but might not be helpful on a production webserver/db :-)
23) Message boards : News : Major Power Outage at SSL (Message 1239959)
Posted 2 Jun 2012 by Profile Andy Lee Robinson
Post:

https://twitter.com/#!/setihome

Funny how the colour "yellow" and the word "bypass" comes to mind... :-)
24) Message boards : News : Major Power Outage at SSL (Message 1239766)
Posted 2 Jun 2012 by Profile Andy Lee Robinson
Post:
Instead of an impossible redirect, I would have suggested a managed update of DNS as they shouldn't be on site. For a planned outage, the subdomain's resource record refresh rate is increased before the switch so that an update will happen relatively immediately.
However, with infinite wisdom, the forum website has the same domain name as the project's, so after a DNS update the backup info site would be swamped with half a million machines trying to connect. Not good!

The forum is also intimately tied to the project database, so it couldn't run standalone, unless connecting to a remote multiple master db, or to a slave as readonly.

A free blog site such as setiathome.wordpress.com could suffice, at present available for someone to register.

Or how about:
Twitter feed?
Boincstats shoutbox?
An official Facebook page? (not the uninteractive wiki)

I could also update my stats page on http://setistats.haveland.com/ if someone lets me know.

So many ways to communicate now - no excuses for info darkness.
25) Message boards : Number crunching : Hang on wingys, I'm trying.......... (Message 1234239)
Posted 20 May 2012 by Profile Andy Lee Robinson
Post:
Mark, I have 3 P5Ks still running.
On one of them, 2 of the SATA ports failed and running on what is left.
Your board could be a similar thing, so try the disk on different ports.
If it's still wobbly, try with another disk?

It may be that retirement is looming...
I had to tone down the overclocking on my boards to maintain stability.
26) Message boards : Number crunching : 62 AP_V5 Left In The Field (Message 1233901)
Posted 20 May 2012 by Profile Andy Lee Robinson
Post:
A theoretical 250 days to bounce around peeing everyone off!

Has to be a solution for user or admin to notify of a bad host and force reassignment, prioritize high turnover hosts etc.
There already is something in place that limits delivery to hosts that produce many errors, so shouldn't be difficult to add. I remember having this discussion some years ago!

Not checking in for a few days could count as an error, if the user has specified that the machine is permanently connected to the net and expects to check in/report daily.
27) Message boards : Number crunching : 62 AP_V5 Left In The Field (Message 1233768)
Posted 20 May 2012 by Profile Andy Lee Robinson
Post:
I'm also wondering why it went back up to 4. I hope someone in the lab is at least curious enough to check for himself and see if they're out to hosts that are likely to return them.


Simply because tasks that have timed out "return home" to wait for a new host to come along. Until then, they are not out in the field!
28) Message boards : Number crunching : how much GPU can the download server support? (Message 1213367)
Posted 2 Apr 2012 by Profile Andy Lee Robinson
Post:
The plan right now is to replace all 3 of the current download/upload servers and compile them into one server.


hm... then it'll probably need the tcp/ip settings tweaking a lot to handle the number of sessions and a shedload of cpu for connection tracking and massive disk concurrency.

I think 4 servers, using iptables to route based on least significant two bits over a 1G network, or 4x100mpbs split between different providers would get things running acceptably again.

The current state of affairs is really really painful, with so much bandwidth wasted in retries.

The lowest hanging fruit (knee level) is to change the WU data encoding for MB tasks from base64 to binary (ala astropulse), that would win about 20% efficiency for a simple tweak.
29) Message boards : News : Your chance to be famous. (Message 1209522)
Posted 24 Mar 2012 by Profile Andy Lee Robinson
Post:
I wonder why msattler springs to mind... :)
30) Message boards : Number crunching : memory as a ram disk (Message 1191018)
Posted 2 Feb 2012 by Profile Andy Lee Robinson
Post:
Not quite true... might gain an extra couple of seconds per day!
31) Message boards : Number crunching : Sparse FFT: 10x speed (Message 1187056)
Posted 21 Jan 2012 by Profile Andy Lee Robinson
Post:
See the obscure and misleading "SODA, with a D" topic...

I don't think it'll be useful because it throws the baby out with the bathwater, and the babies we are looking for are really really really tiny!
32) Message boards : Number crunching : SODA, with a D (Message 1186962)
Posted 21 Jan 2012 by Profile Andy Lee Robinson
Post:
Thanks Martin, I do know what they are, where and why they are used!
(I wrote an FFT algorithm in 6502 ASM to do digital vocoding amongst other things for my postgrad thesis 25 years ago!)

This algorithm is not a lossless fast FFT, it economizes by throwing away insignificant frequencies and working on the rest.
Not too useful for SETI where everything is significant - the faintest of signals may be overlooked and discarded.
It might be useful for superficial scanning, then do a deeper search with the normal FFT.
33) Message boards : Number crunching : Breathing life into an old computer (Message 1186785)
Posted 20 Jan 2012 by Profile Andy Lee Robinson
Post:
Now I just have to speed up the Pentium 4.


Bin it, and spend the money you save on its electricity bill on another GPU for the other machine.
34) Message boards : Number crunching : SODA, with a D (Message 1186782)
Posted 20 Jan 2012 by Profile Andy Lee Robinson
Post:
um... that should be Foxtrot Foxtrot Tango if you want to use the international convention...

Interesting article, but pity that the graphic incorrectly sums the example waveforms, and appears to just be drawn!

I'm not sure that sparse FFTs are applicable for SETI, as they are used for lossy compression of media.
35) Message boards : Number crunching : Ramdisk (Message 1185306)
Posted 14 Jan 2012 by Profile Andy Lee Robinson
Post:
client_state.xml updated quite often and takes ~4MB on my not too fast host...
On more fast hosts it would be much bigger.

So, there is something in BOINC that can win from faster "HDD" access.
Robustness of such BOINC setup is another question.

That is true. With my low-end rigs, my client_state has never been more than 1MB, but it gets re-generated/updated every 60 seconds, and that <1MB file ends up with hundreds of fragments in the file system.

I imagine that when we lose the limits and some people go back to 10,000+ tasks in their cache, client_state must be huge ( >10MB ), and with that, thousands of fragments, which makes disk-access time for it a lot slower.

However, as stated before, since it is volatile storage, you would have to write the contents of it to disk somewhat frequently as a safety measure.



It isn't worth it - disk transfers are mostly cached and handled by DMA, so while the cpu is waiting for I/O the FPU/GPU can still be working.

A 10 MB file loads and saves in less than 1/4 of a second, so even at once a minute, that's only 1/240th of time, during which the FPU/GPUs are still crunching.

Disk caching makes running from ramdisk almost redundant, unless used like a "persistent cache" that doesn't expire other cached stuff.

For example, if I need to do a lot of random access processing on files that might impact the performance of other disk intensive applications, mysql etc. by head thrashing, then I copy from disk to the ramdrive, do the intensive stuff on them and copy back.

Perhaps php sessions can benefit, with rsynced backup and modified httpd start/stop to save/restore on boot/shutdown, but as these are all cached anyway, any performance benefits are really marginal. Any site requiring such performance should have its sessions distributed through a mysql cluster and memcached anyway!

The best improvement I've seen for a ramdisk is using /dev/shm as a temp dir for mysql, which I can't recommend highly enough.
36) Message boards : Number crunching : Kepler SETI Candidate Signals (Message 1184381)
Posted 10 Jan 2012 by Profile Andy Lee Robinson
Post:
In the News Section Eric Korpela writes that a student is writing a splitter to enable SETI@home volunteers to crunch Kepler data. Wait and see.
Tullio


Excellent... I hope it will look at as many frequencies as possible and see what else there may be to learn about the system.
37) Message boards : SETI@home Science : BBC article - Alien hunters: Searching for life (Message 1184174)
Posted 9 Jan 2012 by Profile Andy Lee Robinson
Post:
The first of a two-part BBC World Service Discovery
series, "Seti: the past, present and future"

http://www.bbc.co.uk/news/science-environment-16265519

Very interesting - podcast available for download
from http://www.bbc.co.uk/worldservice/ for a limited time.
38) Message boards : Number crunching : Kepler SETI Candidate Signals (Message 1184168)
Posted 9 Jan 2012 by Profile Andy Lee Robinson
Post:
The Kepler data gives orbital period of detected planets and requires that the orbital plane be more or less edge-on from our view, from which expected Doppler due to orbital motion around the star could be derived. But Doppler due to planetary rotation or the transmitter being on a satellite, etc., cannot be known. My own personal guess is that any civilization sending signals at Petawatt powers won't have the transmitter anyplace near the population.
                                                                  Joe


I think think the distance is around 600 ly, in the neighbourhood, but still impossibly far away to have any hope of travel.

A petawatt transmitter at any frequency would be a formidable weapon, but somehow I don't see that a really intelligent civilization would want to invest so much in advertising itself unless it was supremely confident in its ability to defend itself or attract prey. Contact might therefore be 'regrettable', but the distances are so vast that nothing we know about could survive a journey, except perhaps a hollowed out ice-covered asteroid with a fusion reactor scavenging on interstellar hydrogen. Going anywhere would be difficult though, even nuclear bombs would hardly be useful enough for attitude control!

I think only 1 in 200 stars with planetary systems have orbital planes that allows detectable transits (and even that sounds optimistic to me), so there are many more potential targets out there.
If only we had the resources to listen to some of our closest companions, or trace and examine stars that were nearby when our solar system was born and might share a common history.
39) Message boards : Number crunching : Kepler SETI Candidate Signals (Message 1184014)
Posted 9 Jan 2012 by Profile Andy Lee Robinson
Post:
Thanks for the clarification Josef, those coordinates look like they are just to the 'left' of Vega.

I did of course mean telescope slew rate is eliminated if the target is being tracked, so there would be no Angle Range and all of the sample could contain a signal if present.

If the actual orbit and inclination of the planet is known or could be found, then its motion could be factored in and over the course of many samples, the background noise could be further reduced to the point where a signal may become visible. It may require a new app designed for the task. If everyone processed thousands or millions of samples of the same region of space, with each task reducing background noise, then if there is anything there it should become visible.

Of course, it would help tremendously if we knew there was a signal there to be found!
40) Message boards : Number crunching : Kepler SETI Candidate Signals (Message 1183791)
Posted 8 Jan 2012 by Profile Andy Lee Robinson
Post:
Well, it certainly generated a lot of excitement here... not!

I think we should crunch some of the data if it is compatible, and look forward to doing some.
If they are direct samples from a fixed point, then I guess we won't have to worry about angle ranges and perhaps the signal sensitivity would be greater.

However, I don't expect too much - looking for ET is like scanning the Pacific Ocean for the ripples of a rain drop that happens on average every 1000 years.

However, SETI still has millions of candidate signals that haven't yet been investigated. After 10 years of doing this, I sometimes wonder what's the point if the results are just archived and not being actively investigated, with very little news of progress.


Previous 20 · Next 20


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.