Since this thread is here anyway; Is there anyway I can detach a machine from the project that I no longer have physical access to?

A have a couple of machines sitting on some WUs that I'd love to release back to the pool as some don't expire for nearly a month yet and I hate sitting on them. Problem is they are my laptop and mac from my last job and well they ain't mine anymore LOL.

Nope, not without access to the machines.

Hrmmmm... to quote my 9 year old daughter: poopy.

Since this thread is here anyway; Is there anyway I can detach a machine from the project that I no longer have physical access to?

A have a couple of machines sitting on some WUs that I'd love to release back to the pool as some don't expire for nearly a month yet and I hate sitting on them. Problem is they are my laptop and mac from my last job and well they ain't mine anymore LOL.

Nope, not without access to the machines.

Since this thread is here anyway; Is there anyway I can detach a machine from the project that I no longer have physical access to?

A have a couple of machines sitting on some WUs that I'd love to release back to the pool as some don't expire for nearly a month yet and I hate sitting on them. Problem is they are my laptop and mac from my last job and well they ain't mine anymore LOL.

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

Google "Arecibo schedule" to get to what projects were scheduled to make observations. That's just a starting point, most don't publish what they actually observed or how. I will note that the March 7 schedule also includes an hour on project P1684 which is observation of a particular Pulsar so should be VLAR.

The ALFALFA project Spring 2007 observations are well documented, though. The last two links on that page are to text files which identify the declination and times very nicely. There's a similar page for the Fall 2006 observations, also conducted after the Multibeam recorder was installed though any data collected then has presumably been put in storage.

                                                                Joe

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

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

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.

---

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

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

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

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

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

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

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.

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 :)

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.

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.

---

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.