Communications disruptions and downloaded units

My son brought another problem to me concerning the latest communication problems. He has a two day connection time and therefore has about 10 units in his cache

normally. This should have seen him through the last outage but as the units tend to be delivered in batches he received 6 noisy (less than 5 mins) units together so that he ran out of

work before Seti was re-established.

Therefore might I suggest that units are issued randomly from the batch on the issueing server to decrease the likelyhood of this re-occuring. I've no idea if this can be done

and realise that it would be low priority but please give it some thought.

Andy

Communications disruptions and downloaded units

My son brought another problem to me concerning the latest communication problems. He has a two day connection time and therefore has about 10 units in his cache

normally. This should have seen him through the last outage but as the units tend to be delivered in batches he received 6 noisy (less than 5 mins) units together so that he ran out of

work before Seti was re-established.

Therefore might I suggest that units are issued randomly from the batch on the issueing server to decrease the likelyhood of this re-occuring. I've no idea if this can be done

and realise that it would be low priority but please give it some thought.

Andy

As I understand it Andy, tapes are picked sort-of at random already.
I believe that it is usually a whole tape, or a significant part of one, that contains noisy data.
Each tape contains around 33000 blocks of data, and (IF I uderstand it!) each 48 blocks produce 256 WUs or 1024 results. So a tape generates ~700,000 results.
Now it seems that Berkeley can hold around 500,000 results 'Ready to Send' at any time.
Since 3 splitters are currently generating results, this is probably about as good a 'random' distribution as you're going to get without massively increasing the ready-to-send cache - or increasing the number of splitters.
IIRC Classic has about 8 splitters and when Classic shuts, these (most of them) will move to BOINC and I guess that will improve the 'random' distribution quite a bit.

---

mike, don't forget that each 107 second chunk of data overlaps the previous and successive ones. this overlap actually means there is 1,050,000 results/tape. Unless of course I'm incorrect also.

---

Thanks Tony and Mike,
But yes I can do the sums also, but I don't remebering getting batches like this when we crunched Classic, I've had them and so have both my sons now, since we swaped to Boinc and I was just hopeful that something could be arranged so that when a user gets a cache it isn't blown in a few minutes instead of the several days expected. Especially frustrating when it happens and Seti is down (again).

Andy

Thanks Tony and Mike,
But yes I can do the sums also, but I don't remebering getting batches like this when we crunched Classic, I've had them and so have both my sons now, since we swaped to Boinc and I was just hopeful that something could be arranged so that when a user gets a cache it isn't blown in a few minutes instead of the several days expected. Especially frustrating when it happens and Seti is down (again).

Andy

I understand Andy. As someone with a background in Troposcatter Comms you can imagine that within one tape that the portion (time) exposed to RFI can last quite a while. These WUs are generally distributed from the same tape and from the same time period. So you can see where one user or group of users could get "dirty" WUs in groups. About the only way I can think of to fix is it to "Shuffle" the WUs from several tapes and then distribute. I don't think this would be high on their list of priorities.

tony

It would be nice if there was a way that WU’s that are regularly spaced along the tape are sent out first then if the WU’s from one area of tape come back noisy the WU’s in between those WU’s are not then sent out as they will be noisy also.

---

Anthony

mike, don't forget that each 107 second chunk of data overlaps the previous and successive ones. this overlap actually means there is 1,050,000 results/tape. Unless of course I'm incorrect also.

Arecibo with the current seti-recorder can generate roughly 270k wu/day, but each tape have only capasity for around 176k wu. Therefore they're normally recording two tapes same date, and marks them aa and ab.

Due to 4 result/wu and gaps in recording and so on there's around 650k result/tape and 1M result/day.

I understand Andy. As someone with a background in Troposcatter Comms you can imagine that within one tape that the portion (time) exposed to RFI can last quite a while. These WUs are generally distributed from the same tape and from the same time period. So you can see where one user or group of users could get "dirty" WUs in groups. About the only way I can think of to fix is it to "Shuffle" the WUs from several tapes and then distribute. I don't think this would be high on their list of priorities.

tony

As the units have a unique ID and I have downloaded units that are at intervals of 4, e.g. 1623478: 1623482: 1623486 etc. Couldn't they arrange it that the interval was larger, say 64, then you would get every 16th unit.

Andy

Thanks Tony and Mike,
But yes I can do the sums also, but I don't remebering getting batches like this when we crunched Classic, I've had them and so have both my sons now, since we swaped to Boinc and I was just hopeful that something could be arranged so that when a user gets a cache it isn't blown in a few minutes instead of the several days expected. Especially frustrating when it happens and Seti is down (again).

Andy

Classic seti did the same thing.

SetiQueue had options you could set to control the interval between downloads.

From Kari Jakobis howto on SetiQueue:

Inter Workunit download gap:

Enter an amount between 0 and 600 minutes. This specifies the amount of time which will be between the download of two work units. You will receive work units from different recording locations if you leave this to "1" or higher. "0" will result in a bunch of work units all recorded at the (almost) same location in the sky.


SetiQueue also took advantage of it. When it noticed the WU was "sweet" (expected to take less CPU time than normal), it quicky downloaded as many as it could until your queue was full. Or one that was considered longer than normal, it waited a longer interval before downloading another one.

From the same page, near the bottom:

The third section displays the Queue processing settings of SetiQueue. I explained the "Inter-WU download gap" before, but the "Inter-WU VLAR gap" setting as well as the "Look for sweet WUs" option can only be found & configured from the web interface. VLAR units are units which take unusually longer than the average unit as they are recorded at Arecibo in a difficult angle. These workunits will take longer than the "normal" ones. If you specify an amount of time SetiQueue will wait this long after downloading the first one of these VLAR-units until it will download the next one to your Queue. 5 minutes should be enough to avoid downloading many of them at once.

Enabling the "Look for sweet WUs" option is highly recommended. A "sweet workunit" is analyzed much more faster than the average unit. If you enable this option SetiQueue will override the gap specified in "inter-WU download gap" after the first one is downloaded and will continue to download constantly new WUs until the next VLAR unit is discovered, after which it will return to use the "inter-WU download gap"