Geek@play: Just FYI, this is me 'returning' to SETI. I crunched for SETI *years* ago when it was brand spanking new (1999/2000 ish)

If you still remember your Seti Classic email addr, you might be able to claim your credits by going here.

Dave, thanks a bunch! I'll be happy if I can get 600 as a RAC out of those boxes.. it will make for some truly mind blowing numbers (not trying to brag, just nice to have something worthy of 'fleet' status under my control again LOL). If I get 'em all online I'll have a RAC around 166K (assuming 600 per). That should move things up the stats a bit ;)

Indeed! Good luck getting everything running.

-Dave

---

Geek@play: Just FYI, this is me 'returning' to SETI. I crunched for SETI *years* ago when it was brand spanking new (1999/2000 ish)

If you still remember your Seti Classic email addr, you might be able to claim your credits by going here.

RandyC:

I go through email addresses like my wife goes through moods LOL... I couldn't possibly remember what the heck I used back then LOL.

Thank you. As an aside, does anyone know what kind of RAC I can expect out of a 3.0 P4 dual core system over the long haul (light office usage scenario)?

You can look at mine P4D 930
it has been off for about 2 days now, but on 24/7 for months before that, it is down from about 970 right now...

-Dave

Dave, thanks a bunch! I'll be happy if I can get 600 as a RAC out of those boxes.. it will make for some truly mind blowing numbers (not trying to brag, just nice to have something worthy of 'fleet' status under my control again LOL). If I get 'em all online I'll have a RAC around 166K (assuming 600 per). That should move things up the stats a bit ;)

I'm running a P4 3.2 HT that is just short of 550 RAC right now running Chicken v2.4. It does get turned off some, but is probably on 75% - 80% of the time.

---

Calm Chaos Forum...Join Calm Chaos Now

Osiris30

If you don't already have a shortcut for the rest of your machines, then I might help speed up the attachment process. Let one of your machines run out of work (set seti to NO New Work). Copy the whole boinc folder. On the new machines make the folder "C:\\programfiles\\boinc" or wherever you want to install it to (remember where it is so you can install boinc to that location). paste the copied boinc folder contents to the boinc folder on the unattached machines(or you could just paste the copied boinc folder to C:\\programfiles\\). Then run boinc installer on each of the new machines. As soon as you're finished installing boinc you'll already be attached and then just re allow new work. It will detect the new machine, make a new host ID and you're off to the races.

In the past, tapes were split in a highly random order, this tended to mix "fast" and "slow" work units, so that we didn't see the system run dry because of all fast (all noisy) work.

Looking at the splitter queue (sunday morning) it seems to be pretty much in order. If the telescope was looking at the same source all the time, that could give us a bunch of really similar work units.

Perhaps things need to be randomized a bit more....

I have had similar thoughts, however even better than randomizing would be to run a sort of preview on each disc or recording session.

It might be an additional workload on the server infrastructure, so that might be why Matt has not done it, but if they could preview each disc they might be able to choose a good mix of work before the splitters start their work.

Seems like a possible solution from my limited viewpoint.

<edit> added a word to make more gramatical sense </edit>

If the recording was done when the telescope was looking at one point in the sky, then moved, them steady again, the "tape" wouldn't be consistent all the way through, so it'd be more than split one WU, test it, and then split more.

Same with noise sources.

It should be possible to characterize work by angle-range, but I'm not sure how much that'd help.

---

If you copy the folder then whatever seti application is there will be transfered, so ...If you've put an optimized app in that folder, you might wanna make sure it'll work on the machine you're pasting it to.

Osiris30

If you don't already have a shortcut for the rest of your machines, then I might help speed up the attachment process. Let one of your machines run out of work (set seti to NO New Work). Copy the whole boinc folder. On the new machines make the folder "C:\\programfiles\\boinc" or wherever you want to install it to (remember where it is so you can install boinc to that location). paste the copied boinc folder contents to the boinc folder on the unattached machines(or you could just paste the copied boinc folder to C:\\programfiles\\). Then run boinc installer on each of the new machines. As soon as you're finished installing boinc you'll already be attached and then just re allow new work. It will detect the new machine, make a new host ID and you're off to the races.

Cool, I'll have to give that a look see. Right now I don't mind too too much doing it the old fashioned way as I have multiple things I configure at the same time on the machine while BOINC does it's dance anyway. The biggest issue with attaching the other machines is pretty much two things: 1) I'm lazy LOL and 2) I'm going to let the limited deployment run for a while to make sure it doesn't cause issues. As much as I would love the large fleet, I'm not going to fubar the LAN because of it :)

If you copy the folder then whatever seti application is there will be transfered, so ...If you've put an optimized app in that folder, you might wanna make sure it'll work on the machine you're pasting it to.

That's the best part.. the whole network is the same class of machine.. although the next batch won't be, but they will be C2D's instead of P4-duals, so I sure as hell ain't gonna complain about that :)

In the past, tapes were split in a highly random order, this tended to mix "fast" and "slow" work units, so that we didn't see the system run dry because of all fast (all noisy) work.

Looking at the splitter queue (sunday morning) it seems to be pretty much in order. If the telescope was looking at the same source all the time, that could give us a bunch of really similar work units.

Perhaps things need to be randomized a bit more....

I have had similar thoughts, however even better than randomizing would be to run a sort of preview on each disc or recording session.

It might be an additional workload on the server infrastructure, so that might be why Matt has not done it, but if they could preview each disc they might be able to choose a good mix of work before the splitters start their work.

Seems like a possible solution from my limited viewpoint.

<edit> added a word to make more gramatical sense </edit>

If the recording was done when the telescope was looking at one point in the sky, then moved, them steady again, the "tape" wouldn't be consistent all the way through, so it'd be more than split one WU, test it, and then split more.

Same with noise sources.

It should be possible to characterize work by angle-range, but I'm not sure how much that'd help.

Here's what I don't get.. BOINC is able to estimate the time fairly accurately. The -9s I got I'm willling to chalk up to extremely bad luck on my part.. but if BOINC can sniff out the 20 minute WUs at the client side, why can't the splitters also know the expected time for the WUs and split data out accordingly.

In the past, tapes were split in a highly random order, this tended to mix "fast" and "slow" work units, so that we didn't see the system run dry because of all fast (all noisy) work.

Looking at the splitter queue (sunday morning) it seems to be pretty much in order. If the telescope was looking at the same source all the time, that could give us a bunch of really similar work units.

Perhaps things need to be randomized a bit more....

I have had similar thoughts, however even better than randomizing would be to run a sort of preview on each disc or recording session.

It might be an additional workload on the server infrastructure, so that might be why Matt has not done it, but if they could preview each disc they might be able to choose a good mix of work before the splitters start their work.

Seems like a possible solution from my limited viewpoint.

<edit> added a word to make more gramatical sense </edit>

If the recording was done when the telescope was looking at one point in the sky, then moved, them steady again, the "tape" wouldn't be consistent all the way through, so it'd be more than split one WU, test it, and then split more.

Same with noise sources.

It should be possible to characterize work by angle-range, but I'm not sure how much that'd help.

Here's what I don't get.. BOINC is able to estimate the time fairly accurately. The -9s I got I'm willling to chalk up to extremely bad luck on my part.. but if BOINC can sniff out the 20 minute WUs at the client side, why can't the splitters also know the expected time for the WUs and split data out accordingly.

Going back to my first statement, you could have a "tape" that has a few "long" work units at the start, and the rest all quick. The splitters couldn't even know until they've scanned (or at least sampled) the tape.

With three splitters running, on three different tapes, it's only an issue if all of the current tapes are of the "fast" variety.

If it is an unusual event, it's maybe a little irksome, but that happens. If it happens alot, then it's time to work on the issue.

---

In the past, tapes were split in a highly random order, this tended to mix "fast" and "slow" work units, so that we didn't see the system run dry because of all fast (all noisy) work.

Looking at the splitter queue (sunday morning) it seems to be pretty much in order. If the telescope was looking at the same source all the time, that could give us a bunch of really similar work units.

Perhaps things need to be randomized a bit more....

I have had similar thoughts, however even better than randomizing would be to run a sort of preview on each disc or recording session.

It might be an additional workload on the server infrastructure, so that might be why Matt has not done it, but if they could preview each disc they might be able to choose a good mix of work before the splitters start their work.

Seems like a possible solution from my limited viewpoint.

<edit> added a word to make more gramatical sense </edit>

If the recording was done when the telescope was looking at one point in the sky, then moved, them steady again, the "tape" wouldn't be consistent all the way through, so it'd be more than split one WU, test it, and then split more.

Same with noise sources.

It should be possible to characterize work by angle-range, but I'm not sure how much that'd help.

Here's what I don't get.. BOINC is able to estimate the time fairly accurately. The -9s I got I'm willling to chalk up to extremely bad luck on my part.. but if BOINC can sniff out the 20 minute WUs at the client side, why can't the splitters also know the expected time for the WUs and split data out accordingly.

Going back to my first statement, you could have a "tape" that has a few "long" work units at the start, and the rest all quick. The splitters couldn't even know until they've scanned (or at least sampled) the tape.

With three splitters running, on three different tapes, it's only an issue if all of the current tapes are of the "fast" variety.

If it is an unusual event, it's maybe a little irksome, but that happens. If it happens alot, then it's time to work on the issue.

Well then we just need to get them more splitters and a nice big storage array to dump all the WUs on.. and some bandwidth to serve them and the problem becomes moot ;) :P

It'll be fascinating to see what comes off the next few 'tapes'. What sort of observing session at Arecibo allowed them to gather over 600GB of data in a single day?

Let's see, 14 channels at 2.5 million samples per second is 1.26e11 samples per hour. With 2 bit coding that could be 31.5 Gigabytes per hour giving an observing time of about 19 hours. That's probably an overestimate, block overhead and such certainly reduce the available data space.

One of the advantages of radiotelescopes is they can be used both day and night. AFAIK, there's no reason the ALFA receivers cannot be on for a full 24 hours.

                                                                 Joe

With three splitters running, on three different tapes, it's only an issue if all of the current tapes are of the "fast" variety.

That doesn't seem to be Matt's current strategy, judging by the new display on the server status page.

Seems to be a straightforward sequential split, with all six splitters working on the same 'tape' (or consecutive 'tapes', as one is finished and the next comes into play).

That's why I'm interested to see what the 13 'tapes' recorded on 07 March 2007 contain. What would Arecibo be devoting 17 hours (thanks Joe) of recording time to? That's the longest continuous recording time we've seen to date, by a long way. My fear is that it will turn out to be a single "basketweave" sky survey, and we'll get nothing but shorties for the next few days.

Time will tell. They should reach the first of the tapes by the time I get up tomorrow morning.....

Edit - simple geometry tells us that even a radio (day/night) telescope can't have been focussing on the same point in the sky for 17 hours.....

...
That's why I'm interested to see what the 13 'tapes' recorded on 07 March 2007 contain. What would Arecibo be devoting 17 hours (thanks Joe) of recording time to? That's the longest continuous recording time we've seen to date, by a long way. My fear is that it will turn out to be a single "basketweave" sky survey, and we'll get nothing but shorties for the next few days.

The ALFALFA project had a 9 hour observation on that date. That much of the data should be at angle range 0.407578 for beam 0, the other beams slightly different.

                                                                  Joe

...
That's why I'm interested to see what the 13 'tapes' recorded on 07 March 2007 contain. What would Arecibo be devoting 17 hours (thanks Joe) of recording time to? That's the longest continuous recording time we've seen to date, by a long way. My fear is that it will turn out to be a single "basketweave" sky survey, and we'll get nothing but shorties for the next few days.

The ALFALFA project had a 9 hour observation on that date. That much of the data should be at angle range 0.407578 for beam 0, the other beams slightly different.

                                                                  Joe

Where did you find that info? I tried to find an observing schedule, but g**gle would only retrieve Green Bank data.

In the past, tapes were split in a highly random order, this tended to mix "fast" and "slow" work units, so that we didn't see the system run dry because of all fast (all noisy) work.

Looking at the splitter queue (Sunday morning) it seems to be pretty much in order. If the telescope was looking at the same source all the time, that could give us a bunch of really similar work units.

Perhaps things need to be randomized a bit more....

I have had similar thoughts, however even better than randomizing would be to run a sort of preview on each disc or recording session.

It might be an additional workload on the server infrastructure, so that might be why Matt has not done it, but if they could preview each disc they might be able to choose a good mix of work before the splitters start their work.

Seems like a possible solution from my limited viewpoint.

<edit> added a word to make more grammatical sense </edit>

If the recording was done when the telescope was looking at one point in the sky, then moved, them steady again, the "tape" wouldn't be consistent all the way through, so it'd be more than split one WU, test it, and then split more.

Same with noise sources.

It should be possible to characterize work by angle-range, but I'm not sure how much that'd help.

Here's what I don't get.. BOINC is able to estimate the time fairly accurately. The -9s I got I'm willing to chalk up to extremely bad luck on my part.. but if BOINC can sniff out the 20 minute WUs at the client side, why can't the splitters also know the expected time for the WUs and split data out accordingly.

Going back to my first statement, you could have a "tape" that has a few "long" work units at the start, and the rest all quick. The splitters couldn't even know until they've scanned (or at least sampled) the tape.

With three splitters running, on three different tapes, it's only an issue if all of the current tapes are of the "fast" variety.

If it is an unusual event, it's maybe a little irksome, but that happens. If it happens a lot, then it's time to work on the issue.

Well then we just need to get them more splitters and a nice big storage array to dump all the WUs on.. and some bandwidth to serve them and the problem becomes moot ;) :P

Well If You'd won the Lottery and were newly rich, you could've made a $250,000.00 Donation, I'm sure cash strapped Seti would've really appreciated the money, Since You haven't. Know that -9 errors do happen and most people just ignore them and go on to the next WU as nothing else can be done with very little money.

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

Well If You'd won the Lottery and were newly rich, you could've made a $250,000.00 Donation, I'm sure cash strapped Seti would've really appreciated the money, Since You haven't. Know that -9 errors do happen and most people just ignore them and go on to the next WU as nothing else can be done with very little money.

How could I win the lottery you thugged me in the alley way and stole my ticket. That aside, I originally started this thread because I had never seen such a large number of short work units and was seeking clarification.

Depends whether you mean ultra-short-short (60 seconds) - report -9 overflow, attributed to RFI noise. Can happen at any time, usually to just a few WUs, but occasionally a large portion of a tape is contaminated. The new data recorder, installed in conjunction with the multibeam antenna, is supposed to be more intelligent in only recording data when that antenna is doing proper observations: so in theory there should be fewer -9s these days.

Or just short (20 minutes) - recorded at a high AR, ~1.4 or above, crunch to completion without overflow. This is a new recording mode, known as "basketweave", where the antenna nods backwards and forwards to cover a large area of sky in a short time. We're seeing many more of these since the switch to the multibeam antenna/recorder. Matt and the crew will have to engineer the backend to cope with the increased number of these, but I'm not sure they've realised the significance yet.

Depends whether you mean ultra-short-short (60 seconds) - report -9 overflow, attributed to RFI noise. Can happen at any time, usually to just a few WUs, but occasionally a large portion of a tape is contaminated. The new data recorder, installed in conjunction with the multibeam antenna, is supposed to be more intelligent in only recording data when that antenna is doing proper observations: so in theory there should be fewer -9s these days.

Or just short (20 minutes) - recorded at a high AR, ~1.4 or above, crunch to completion without overflow. This is a new recording mode, known as "basketweave", where the antenna nods backwards and forwards to cover a large area of sky in a short time. We're seeing many more of these since the switch to the multibeam antenna/recorder. Matt and the crew will have to engineer the backend to cope with the increased number of these, but I'm not sure they've realised the significance yet.

Well the big problem I was having was both combined. The WUs that hit my (and I'm sure many other) machines had a high error rate (-9). In and of itself, not a major issue, and I doubt I would have noticed, expect, the majority of other work I was getting at the time was short workunits. The two combined led to a big issue keping the machines stocked. However, most cache's seem full of 5 days of work right now, so hopefully I'll weather future similar situations better.

Having said all of that, there's been some interesting discussions on the thread so I feel good about griping :P