very short run times


log in

Advanced search

Questions and Answers : Windows : very short run times

Author Message
JakeTheDog
Send message
Joined: 3 Nov 13
Posts: 13
Credit: 286,282
RAC: 379
United States
Message 1461310 - Posted: 6 Jan 2014, 22:29:21 UTC

Hello, for the past couple weeks I have noticed that maybe 5% of my tasks are getting less than a minute of run time, maybe sometimes less than 10 seconds. I have never seen this in my results before, and they are being marked as valid. This seems kind of odd, and when I usually see these short run times as invalid in wingmen's. So I am wondering if some of these work units are corrupted in some way and need to be rerun. Or perhaps both the wingman and I have incorrect but identical results. Or perhaps it is normal for some of these work units to only require 3 seconds of run time.

OzzFan
Volunteer tester
Avatar
Send message
Joined: 9 Apr 02
Posts: 13542
Credit: 29,410,458
RAC: 16,068
United States
Message 1461336 - Posted: 7 Jan 2014, 0:11:13 UTC - in response to Message 1461310.

The length of time a task is processed greatly depends on the Angle Range in which it was recorded by the receiver.

Tasks that are recorded on a Very High Angle Range (VHAR) typically process in a matter of seconds. Tasks recorded on a Very Low Angle Range (VLAR) typically take longer to process.

This is perfectly normal behavior.

JakeTheDog
Send message
Joined: 3 Nov 13
Posts: 13
Credit: 286,282
RAC: 379
United States
Message 1461347 - Posted: 7 Jan 2014, 1:40:24 UTC

Well OK then. It just seemed odd since I've never seen any of my results use so little time until now.

Profile Fred E.
Volunteer tester
Send message
Joined: 22 Jul 99
Posts: 768
Credit: 24,136,438
RAC: 2,518
United States
Message 1461360 - Posted: 7 Jan 2014, 2:06:46 UTC

I looked at 3 result files in your validated list that ran for 75 seconds or less. All 3 were -9 result overflow tasks. The application stops when it finds 30 signals in a single file. Sometimes it's a problem with your gpu (high temperatures, etc.). But in these cases, the wingman computer(s) found the same thing, so no need to worry now.

One example (task 33`19678742)
...
Preemptively acknowledging a safe Exit. ->
SETI@Home Informational message -9 result_overflow
NOTE: The number of results detected equals the storage space allocated.

Flopcounter: 2336471688390.454600

Spike count: 30
Autocorr count: 0
Pulse count: 0
Triplet count: 0
Gaussian count: 0
Worker preemptively acknowledging an overflow exit.->
called boinc_finish
...
____________
Another Fred
Support SETI@home when you search the Web with GoodSearch or shop online with GoodShop.

OzzFan
Volunteer tester
Avatar
Send message
Joined: 9 Apr 02
Posts: 13542
Credit: 29,410,458
RAC: 16,068
United States
Message 1461474 - Posted: 7 Jan 2014, 20:40:45 UTC - in response to Message 1461360.

All 3 were -9 result overflow tasks. The application stops when it finds 30 signals in a single file.


Yes, a very common trait of VHAR type tasks, which is why they crunch so quickly.

John Chrzastek
Send message
Joined: 28 May 12
Posts: 22
Credit: 7,069,456
RAC: 30,845
United States
Message 1466634 - Posted: 20 Jan 2014, 13:09:24 UTC - in response to Message 1461336.

I assume that VLAR antenna positions receive more signals because the lower angles pick up more terrestrial signals. The antenna does not have a perfect laser like beam to it - it's beam is wider therefore terrestrial signals 'leak' into the receiver. Am I correct in my reasoning?

OzzFan
Volunteer tester
Avatar
Send message
Joined: 9 Apr 02
Posts: 13542
Credit: 29,410,458
RAC: 16,068
United States
Message 1466719 - Posted: 20 Jan 2014, 18:21:01 UTC - in response to Message 1466634.

Actually, it is my understanding that it is the opposite. VHAR angles pick up more terrestrial signals that need to be removed from the workunit (or "task"), and because of the amount of blanking, they process very quickly.

VLARs have less terrestrial noise and thus more time is spent on processing the entire workunit, non-blanked.

It was fellow forum poster Ageless that pointed out to me an easy way to remember the difference in the types of workunits: Very (s)Low Angle Range (VLAR, are slower to process), which by inverse means that VHARs processes very quickly.

John Chrzastek
Send message
Joined: 28 May 12
Posts: 22
Credit: 7,069,456
RAC: 30,845
United States
Message 1466732 - Posted: 20 Jan 2014, 18:49:00 UTC - in response to Message 1466719.

OK, got it and thank you.

Do you know if the file formats are explained anywhere? I don't seem to be able to find them.

What I', wondering about now is ... for example ...
' 21oc13ad.23072.3339.438086664202.12.148_0.

The ' 21oc13 ' obviously means October 21, 2013 ... I'm curious about the " ad " part.

And the last portion ... " .148_0 " I think I read someplace where the " _0 " means I am the virst one to get it and if it were " .148_1 " it meant that I was the second one to process it.

This is all very fascinating. Thanks for your patience -John

rob smith
Volunteer tester
Send message
Joined: 7 Mar 03
Posts: 8146
Credit: 52,833,152
RAC: 75,836
United Kingdom
Message 1466746 - Posted: 20 Jan 2014, 19:18:21 UTC

Filling in a couple of the blanks:

"ad" indicates which receiver channel was used to collect the data.

(148)_0 and _1 are the first pair of tasks to be distributed for this work unit

If either you, or your wingman, has a problem, or you don't agree on the result then a task "_2" will be sent out to someone else (up to the maximum total tasks which is defined in the WU itself, normally 10 total I think)
The big long number describes the location in the sky etc. (and I always get which bit is which wrong...)
____________
Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

John Chrzastek
Send message
Joined: 28 May 12
Posts: 22
Credit: 7,069,456
RAC: 30,845
United States
Message 1466827 - Posted: 21 Jan 2014, 0:31:08 UTC - in response to Message 1466746.

OK, thank you. I would love to know more about the receiver too but all things in good time.

If _0 and _1 are each ether's wing men, is _2 the vertical stabilizer? Sorry.

-John

John McLeod VII
Volunteer developer
Volunteer tester
Avatar
Send message
Joined: 15 Jul 99
Posts: 24104
Credit: 518,165
RAC: 156
United States
Message 1467133 - Posted: 22 Jan 2014, 2:49:08 UTC - in response to Message 1466746.

Filling in a couple of the blanks:

"ad" indicates which receiver channel was used to collect the data.

(148)_0 and _1 are the first pair of tasks to be distributed for this work unit

If either you, or your wingman, has a problem, or you don't agree on the result then a task "_2" will be sent out to someone else (up to the maximum total tasks which is defined in the WU itself, normally 10 total I think)
The big long number describes the location in the sky etc. (and I always get which bit is which wrong...)

I was under the impression that ad was the 4th "tape" of the night.
____________


BOINC WIKI

JakeTheDog
Send message
Joined: 3 Nov 13
Posts: 13
Credit: 286,282
RAC: 379
United States
Message 1469968 - Posted: 28 Jan 2014, 21:00:59 UTC

Well, I am curious about another thing, kind of related to short run times. I've been running SETI most days for the past 3 months now. I've never had an "invalid" result but maybe 2% show up as "inconclusive" and then will later show as "valid." The "inconclusives" almost always show up as pairs or triplets, and are always from the same wingman at that download request. When I look up the wingman, they have hundreds and hundreds of "invalid" tasks.

So the thing I'm wondering about is, most results have single digit outcomes for the list of signals. If we have many SETI members with unstable computers giving hundreds of invalid results per month or even per week, wouldn't it be possible for 2 computers to have identical invalid results and for this these results to be marked as valid?

Profile Jeff Buck
Send message
Joined: 11 Feb 00
Posts: 258
Credit: 28,948,498
RAC: 83,244
United States
Message 1470347 - Posted: 29 Jan 2014, 17:10:45 UTC - in response to Message 1469968.

If we have many SETI members with unstable computers giving hundreds of invalid results per month or even per week, wouldn't it be possible for 2 computers to have identical invalid results and for this these results to be marked as valid?

Yes, it is. For one such scenario, see thread Two wrongs make a right in the Number Crunching forum.

John McLeod VII
Volunteer developer
Volunteer tester
Avatar
Send message
Joined: 15 Jul 99
Posts: 24104
Credit: 518,165
RAC: 156
United States
Message 1470523 - Posted: 30 Jan 2014, 0:09:47 UTC

But it is unlikely. It is not the count that matters as much as the placement and magnitude of each event.
____________


BOINC WIKI

Questions and Answers : Windows : very short run times

Copyright © 2014 University of California