Seti@Home optimized science apps and information
Optimized Seti@Home apps => Windows => Topic started by: nevica on 29 Mar 2009, 05:52:33 am
-
Hello,
BOINC has sent me a message that I dont have the app_info file for the optimized astropulse application.
I presume I will need to install this. My question is: Can I still run standard optimized SETI applications (setiathome_enhanced) as well as astropulse applications using the Optimized astropulse 5.03 for Windows application. Do I onlt need one app-info file which will take care of both types of data?
Thanks,
Nevica
-
Hello,
BOINC has sent me a message that I dont have the app_info file for the optimized astropulse application.
I presume I will need to install this. My question is: Can I still run standard optimized SETI applications (setiathome_enhanced) as well as astropulse applications using the Optimized astropulse 5.03 for Windows application. Do I onlt need one app-info file which will take care of both types of data?
Thanks,
Nevica
If you go to Arkayn's Site, he's done packages with AK_v8 apps and the Optimised Astropulse apps, just choose the correct one for your CPU / OS.
Multibeam and Astropulse Combined Packages (http://www.arkayn.us/seti/)
Claggy
-
Hello Claggy,
Can these apps also be used with standard SETI WU's as well as Astropulse and Mulitibeam?
Nevica
-
Hello Claggy,
Can these apps also be used with standard SETI WU's as well as Astropulse and Mulitibeam?
Nevica
Yes. "Multibeam" is a conventional synonym for "standard SETI WUs". Poorly chosen, since both types of work come from the same data provided by the multibeam recorder at Arecibo, but the project has chosen to name the splitters mb_splitter and ap_splitter.
Joe
-
Error in AP 5.03 ?
today I saw the first 9 erros since I run ap 5.03 on my V8-Xeon
have a look at
http://setiathome.berkeley.edu/results.php?userid=8071209&offset=0&show_names=0&state=5
heinz
-
Can't see anything by that link Heinz ["No access"]. Is there some text in stderr that says "Blanking too much RFI?" .. if so, there's a stuck bit in some channel of some tapes apparently.
[Edit:] Yep, I found one in your tasks by going through your user info:
http://setiathome.berkeley.edu/result.php?resultid=1218244630
Error in ap_remove_radar.cpp: generate_envelope: num_ffts_performed < 100. Blanking too much RFI?
-
Can't see anything by that link Heinz ["No access"]. Is there some text in stderr that says "Blanking too much RFI?" .. if so, there's a stuck bit in some channel of some tapes apparently.
[Edit:] Yep, I found one in your tasks by going through your user info:
http://setiathome.berkeley.edu/result.php?resultid=1218244630
Error in ap_remove_radar.cpp: generate_envelope: num_ffts_performed < 100. Blanking too much RFI?
in all 9 cases is it this error:
Error in ap_remove_radar.cpp: generate_envelope: num_ffts_performed < 100. Blanking too much RFI?
too bad....if the tape has a lot of them... and the wu will be sent to the next user again
http://setiathome.berkeley.edu/workunit.php?wuid=438579544
http://setiathome.berkeley.edu/workunit.php?wuid=438102609
http://setiathome.berkeley.edu/workunit.php?wuid=438809547
http://setiathome.berkeley.edu/workunit.php?wuid=438938766
http://setiathome.berkeley.edu/workunit.php?wuid=438808229
http://setiathome.berkeley.edu/workunit.php?wuid=438585889
http://setiathome.berkeley.edu/workunit.php?wuid=438675872
http://setiathome.berkeley.edu/workunit.php?wuid=438558426
http://setiathome.berkeley.edu/workunit.php?wuid=438555961
heinz
-
Can't see anything by that link Heinz ["No access"]. Is there some text in stderr that says "Blanking too much RFI?" .. if so, there's a stuck bit in some channel of some tapes apparently.
[Edit:] Yep, I found one in your tasks by going through your user info:
http://setiathome.berkeley.edu/result.php?resultid=1218244630
Error in ap_remove_radar.cpp: generate_envelope: num_ffts_performed < 100. Blanking too much RFI?
in all 9 cases is it this error:
Error in ap_remove_radar.cpp: generate_envelope: num_ffts_performed < 100. Blanking too much RFI?
too bad....if the tape has a lot of them... and the wu will be sent to the next user again
http://setiathome.berkeley.edu/workunit.php?wuid=438579544
http://setiathome.berkeley.edu/workunit.php?wuid=438102609
http://setiathome.berkeley.edu/workunit.php?wuid=438809547
http://setiathome.berkeley.edu/workunit.php?wuid=438938766
http://setiathome.berkeley.edu/workunit.php?wuid=438808229
http://setiathome.berkeley.edu/workunit.php?wuid=438585889
http://setiathome.berkeley.edu/workunit.php?wuid=438675872
http://setiathome.berkeley.edu/workunit.php?wuid=438558426
http://setiathome.berkeley.edu/workunit.php?wuid=438555961
heinz
My estimate is that there are at least 10000, on all B3_P1 channel WUs from 12 March through 20 March. It's a reappearance of a problem seen about a year ago in some SETI Beta Astropulse work, the data for that channel has a stuck bit. The reaction of 5.03 is to see that as a DC offset which means blanking is needed, and then since all the data is blanked it can't establish the envelope for data to do the blanking.
The good thing is this didn't happen with AP 5.00, which would have blanked all the data and then done full length processing antway. Some tests we did long ago proved that full blanking from 5.00 actually produces some false signals, those would have gone into the science database.
With 5.03 the cost to users is basically just whatever time it took to download the work, nobody is likely to get so many it has a serious impact on their daily quota. There will be 7 tasks sent for each WU, the 6th error returned will inhibit any beyond that time. So that's 7 tasks but doesn't cost much time nor have any bad science effect. Considering that normal Astropulse v5 work has been taking about 3.5 tasks sent to get a validated pair, the extra burden on the project servers isn't too bad either.
It would have been even better if it hadn't happened until 5.05 was released, that would put the same error line in stderr but produce a minimal result file and do a normal exit. There would be no signals in the output, the validator would compare the first two results received and see they were the same, and no reissues would be generated.
Obviously the best thing would have been locating and fixing the cause after the episode at Beta last year, but it wasn't happening on newly recorded data so I'm not surprised the cause couldn't be located.
Joe
-
Thanks Jason & Joe,
some more comming today:
http://setiathome.berkeley.edu/workunit.php?wuid=438441412
http://setiathome.berkeley.edu/workunit.php?wuid=438809808
http://setiathome.berkeley.edu/workunit.php?wuid=438515256
-
Thanks Jason & Joe,
some more comming today:
http://setiathome.berkeley.edu/workunit.php?wuid=438441412
http://setiathome.berkeley.edu/workunit.php?wuid=438809808
http://setiathome.berkeley.edu/workunit.php?wuid=438515256
Your post yesterday for http://setiathome.berkeley.edu/workunit.php?wuid=438675872 (ap_21mr09aa_B3_P1_00358_20090501_27701.wu) extended the range we know has been affected by a day. Before that we knew about 12mr09 through 20mr09.
There are some more B3_P1 tasks on your host (not crunched yet) which have the problem. http://setiathome.berkeley.edu/workunit.php?wuid=440203658 (ap_03ap09aa_B3_P1_00250_20090505_10103.wu_4) is the most interesting, as it extends our knowledge of how long the problem has lasted by almost 2 weeks.
There are some more 'tapes' which the ap_splitter processes haven't done yet which I think likely to have the same problem:
09mr09aa 50.20 GB
10mr09aa 50.20 GB
10mr09ab 50.20 GB
10mr09ac 50.20 GB
If you get any B3_P1 tasks from those, I'll be very interested in knowing whether thay do or do not have the problem. If we can identify when the problem started, that could help the project figure out a probable cause.
I'll be watching what few AP tasks I get and any reported in the project NC forum, but your host is getting a very good sample of the AP work being split.
Joe
-
Hi Joe,
As I'm going through the WU's I found 13 of them (B3P1) I will post when they are done.
they are from
02ap09ab ap_02ap09ab_B3_P1_00170_20090504_15112.wu http://setiathome.berkeley.edu/workunit.php?wuid=439903914
03ap09aa ap_03ap09aa_B3_P1_00250_20090505_10103.wu http://setiathome.berkeley.edu/workunit.php?wuid=440203658
this wu show no error
07fe09aa ap_07fe09aa_B3_P1_00258_20090405_02593.wu http://setiathome.berkeley.edu/workunit.php?wuid=430115086
13mr09ab ap_13mr09ab_B3_P1_00100_20090427_18772.wu http://setiathome.berkeley.edu/workunit.php?wuid=437453704
14mr09aa ap_14mr09aa_B3_P1_00143_20090428_28964.wu http://setiathome.berkeley.edu/workunit.php?wuid=437677134
14mr09ae ap_14mr09ae_B3_P1_00083_20090502_29770.wu http://setiathome.berkeley.edu/workunit.php?wuid=438809808
14mr09ae ap_14mr09ae_B3_P1_00030_20090502_29770.wu http://setiathome.berkeley.edu/workunit.php?wuid=438806928
14mr09ae ap_14mr09ae_B3_P1_00186_20090502_29770.wu http://setiathome.berkeley.edu/workunit.php?wuid=438813226
14mr09ae ap_14mr09ae_B3_P1_00000_20090502_29770.wu http://setiathome.berkeley.edu/workunit.php?wuid=438802784
15mr09ac ap_15mr09ac_B3_P1_00082_20090503_04267.wu http://setiathome.berkeley.edu/workunit.php?wuid=439201056
15mr09ac ap_15mr09ac_B3_P1_00095_20090503_04267.wu http://setiathome.berkeley.edu/workunit.php?wuid=439201094
15mr09ad ap_15mr09ad_B3_P1_00049_20090503_10075.wu http://setiathome.berkeley.edu/workunit.php?wuid=439363429
20mr09ab ap_20mr09ab_B3_P1_00366_20090430_19532.wu http://setiathome.berkeley.edu/workunit.php?wuid=438335691
20mr09ac ap_20mr09ac_B3_P1_00229_20090501_12024.wu http://setiathome.berkeley.edu/workunit.php?wuid=438441412
20mr09ae ap_20mr09ae_B3_P1_00046_20090501_18046.wu http://setiathome.berkeley.edu/workunit.php?wuid=438559553
-
Extending the range quite a bit further:
WU 440549415 (http://setiathome.berkeley.edu/workunit.php?wuid=440549415): ap_05ap09ab_B3_P1_00131_20090506_17763.wu
-
Extending the range quite a bit further:
WU 440549415 (http://setiathome.berkeley.edu/workunit.php?wuid=440549415): ap_05ap09ab_B3_P1_00131_20090506_17763.wu
Thanks!
The splitters are now doing 06ap09, and may have done the two shortish 'tapes' from 07ap09 earlier today (wish I'd saved earlier done/not status). There aren't any later in April nor in May yet. WU creation is leading sent time by about 10.5 hours...
Joe
-
Gap-filling:
WU 440049768 (http://setiathome.berkeley.edu/workunit.php?wuid=440049768): ap_02ap09ac_B3_P1_00078_20090505_16821.wu
-
A quick look through my list shows 15th, 20th & 21st march:
http://setiathome.berkeley.edu/result.php?resultid=1220223706
http://setiathome.berkeley.edu/result.php?resultid=1217514719
http://setiathome.berkeley.edu/result.php?resultid=1216553202
-
Gap-filling:
WU 440049768 (http://setiathome.berkeley.edu/workunit.php?wuid=440049768): ap_02ap09ac_B3_P1_00078_20090505_16821.wu
And upcoming: WU 441010635 (http://setiathome.berkeley.edu/workunit.php?wuid=441010635): ap_06ap09ac_B3_P1_00214_20090507_07720.wu
where task 1222567138 (http://setiathome.berkeley.edu/result.php?resultid=1222567138) shows the problem remains.
Edit: Found in task list for host 4709496 (http://setiathome.berkeley.edu/show_host_detail.php?hostid=4709496) (v16 Opteron):
WU 440332488 (http://setiathome.berkeley.edu/workunit.php?wuid=440332488) ap_07ap09ag_B3_P1_00121_20090506_31811.wu which has the problem, and
WU 436902732 (http://setiathome.berkeley.edu/workunit.php?wuid=436902732) ap_02mr09ac_B3_P1_00383_20090425_06576.wu which does not.
Joe
-
Hi Joe,
As I'm going through the WU's I found 13 of them (B3P1) I will post when they are done.
they are from
02ap09ab ap_02ap09ab_B3_P1_00170_20090504_15112.wu http://setiathome.berkeley.edu/workunit.php?wuid=439903914
03ap09aa ap_03ap09aa_B3_P1_00250_20090505_10103.wu http://setiathome.berkeley.edu/workunit.php?wuid=440203658
this wu show no error
07fe09aa ap_07fe09aa_B3_P1_00258_20090405_02593.wu http://setiathome.berkeley.edu/workunit.php?wuid=430115086
13mr09ab ap_13mr09ab_B3_P1_00100_20090427_18772.wu http://setiathome.berkeley.edu/workunit.php?wuid=437453704
14mr09aa ap_14mr09aa_B3_P1_00143_20090428_28964.wu http://setiathome.berkeley.edu/workunit.php?wuid=437677134
14mr09ae ap_14mr09ae_B3_P1_00083_20090502_29770.wu http://setiathome.berkeley.edu/workunit.php?wuid=438809808
14mr09ae ap_14mr09ae_B3_P1_00030_20090502_29770.wu http://setiathome.berkeley.edu/workunit.php?wuid=438806928
14mr09ae ap_14mr09ae_B3_P1_00186_20090502_29770.wu http://setiathome.berkeley.edu/workunit.php?wuid=438813226
14mr09ae ap_14mr09ae_B3_P1_00000_20090502_29770.wu http://setiathome.berkeley.edu/workunit.php?wuid=438802784
15mr09ac ap_15mr09ac_B3_P1_00082_20090503_04267.wu http://setiathome.berkeley.edu/workunit.php?wuid=439201056
15mr09ac ap_15mr09ac_B3_P1_00095_20090503_04267.wu http://setiathome.berkeley.edu/workunit.php?wuid=439201094
15mr09ad ap_15mr09ad_B3_P1_00049_20090503_10075.wu http://setiathome.berkeley.edu/workunit.php?wuid=439363429
20mr09ab ap_20mr09ab_B3_P1_00366_20090430_19532.wu http://setiathome.berkeley.edu/workunit.php?wuid=438335691
20mr09ac ap_20mr09ac_B3_P1_00229_20090501_12024.wu http://setiathome.berkeley.edu/workunit.php?wuid=438441412
20mr09ae ap_20mr09ae_B3_P1_00046_20090501_18046.wu http://setiathome.berkeley.edu/workunit.php?wuid=438559553
Hi Joe,
the most interesting 03ap09aa is out now.
07fe09aa shows no error, very interesting.
heinz
-
Hi Joe,
the most interesting 03ap09aa is out now.
07fe09aa shows no error, very interesting.
heinz
Some I've checked from other hosts seem to indicate all of February is OK, and so are March 1st and 2nd. There aren't any 'tapes' listed for March 3 through 8, March 9 and 10 still haven't been split yet, plus the aa one for March 12.
There should have been several hard disks full of data recorded between March 2 and 9, the ALFA receiver was scheduled for much observation. Perhaps the lack of 'tapes' indicates that's when they started having trouble writing the data to the removable hard drives. If so, maybe while trying to get that working they disturbed the cable from the detectors to the data acquisition card in the computer. Then the problem would show in the March 9 data. That's total speculation at this point, just a possibility from what Matt has said about the recorder, and what we're seeing.
Joe
-
I got a next serie of B3P1 with errors:
ap_06ap09ac_B3_P1_00021_20090507_07720.wu http://setiathome.berkeley.edu/workunit.php?wuid=441010156
ap_22mr09aa_B3_P1_00053_20090510_17379.wu http://setiathome.berkeley.edu/workunit.php?wuid=442070062
ap_22mr09ac_B3_P1_00019_20090511_25060.wu http://setiathome.berkeley.edu/workunit.php?wuid=442206548
ap_22mr09ad_B3_P1_00121_20090511_02240.wu http://setiathome.berkeley.edu/workunit.php?wuid=442276319
ap_22mr09ad_B3_P1_00066_20090511_02240.wu http://setiathome.berkeley.edu/workunit.php?wuid=442276085
ap_22mr09ad_B3_P1_00301_20090511_02240.wu http://setiathome.berkeley.edu/workunit.php?wuid=442277016
ap_22mr09ad_B3_P1_00303_20090511_02240.wu http://setiathome.berkeley.edu/workunit.php?wuid=442277024
ap_22mr09ad_B3_P1_00304_20090511_02240.wu http://setiathome.berkeley.edu/workunit.php?wuid=442277028
ap_22mr09ad_B3_P1_00309_20090511_02240.wu http://setiathome.berkeley.edu/workunit.php?wuid=442277049
ap_22mr09ad_B3_P1_00310_20090511_02240.wu http://setiathome.berkeley.edu/workunit.php?wuid=442277054
ap_22mr09ad_B3_P1_00312_20090511_02240.wu http://setiathome.berkeley.edu/workunit.php?wuid=442277062
@ Joe, I will post this errors as long as it is necessary
heinz
-
I got a next serie of B3P1 with errors:
ap_06ap09ac
ap_22mr09aa
ap_22mr09ac
ap_22mr09ad
ap_22mr09ad
ap_22mr09ad
ap_22mr09ad
ap_22mr09ad
ap_22mr09ad
ap_22mr09ad
ap_22mr09ad
@ Joe, I will post this errors as long as it is necessary
heinz
I'm convinced all 12mr09 through 07ap09 work from B3_P1 will have the error. If you'll keep checking in case I'm wrong that would be good, specific reports aren't really needed otherwise. And when they split the 09mr09 and 10mr09 data, or something after 07ap09 appears, I'll be very interested in whatever we can learn about when the problem started and when/whether it ended.
I also see that 12mr09aa through 12mr09ae have been added to the set of available 'tapes'. The af and ag parts both had the problem, it would be fascinating if some of those earlier sections didn't. But catching the beginning of the problem that accurately is highly unlikely.
Joe
-
next serie:
ap_14mr09af_B3_P1_00254_20090502_31030.wu http://setiathome.berkeley.edu/workunit.php?wuid=438938813
ap_22mr09ab_B3_P1_00047_20090511_32392.wu http://setiathome.berkeley.edu/workunit.php?wuid=442137554
ap_30mr09aa_B3_P1_00190_20090511_00910.wu http://setiathome.berkeley.edu/workunit.php?wuid=442350858
ap_30mr09ac_B3_P1_00046_20090512_24011.wu http://setiathome.berkeley.edu/workunit.php?wuid=442563384
ap_30mr09ac_B3_P1_00047_20090512_24011.wu http://setiathome.berkeley.edu/workunit.php?wuid=442563387
ap_30mr09ac_B3_P1_00048_20090512_24011.wu http://setiathome.berkeley.edu/workunit.php?wuid=442563391
ap_30mr09ac_B3_P1_00051_20090512_24011.wu http://setiathome.berkeley.edu/workunit.php?wuid=442563401
ap_30mr09ac_B3_P1_00054_20090512_24011.wu http://setiathome.berkeley.edu/workunit.php?wuid=442563411
heinz
-
Just to continue the record, the 09mr09 and 10mr09 files also had the problem on B3_P1. So the problem started sometime between the end of the 02mr09ae recording (which didn't exhibit the problem) and the start of 09mr09aa. That 02mr09ae could have been data from March 3, but hardly later since ALFA was being used fairly heavily.
Joe
-
next come in:
ap_03ap09aa_B3_P1_00344_20090505_10103.wu http://setiathome.berkeley.edu/workunit.php?wuid=440204096
ap_09mr09aa_B3_P1_00132_20090515_08017.wu http://setiathome.berkeley.edu/workunit.php?wuid=443793970
ap_09mr09aa_B3_P1_00021_20090515_08017.wu http://setiathome.berkeley.edu/workunit.php?wuid=443793487
ap_09mr09aa_B3_P1_00168_20090515_08017.wu http://setiathome.berkeley.edu/workunit.php?wuid=443794064
ap_10mr09aa_B3_P1_00188_20090515_00406.wu http://setiathome.berkeley.edu/workunit.php?wuid=443848728
ap_10mr09ac_B3_P1_00245_20090516_25105.wu http://setiathome.berkeley.edu/workunit.php?wuid=444003705
ap_10mr09ac_B3_P1_00166_20090516_25105.wu http://setiathome.berkeley.edu/workunit.php?wuid=444002982
ap_12mr09ab_B3_P1_00085_20090516_23480.wu http://setiathome.berkeley.edu/workunit.php?wuid=444107603
ap_12mr09ab_B3_P1_00086_20090516_23480.wu http://setiathome.berkeley.edu/workunit.php?wuid=444107606
ap_12mr09ab_B3_P1_00087_20090516_23480.wu http://setiathome.berkeley.edu/workunit.php?wuid=444107610
ap_12mr09ab_B3_P1_00090_20090516_23480.wu http://setiathome.berkeley.edu/workunit.php?wuid=444107623
ap_12mr09ab_B3_P1_00091_20090516_23480.wu http://setiathome.berkeley.edu/workunit.php?wuid=444107627
ap_12mr09ab_B3_P1_00092_20090516_23480.wu http://setiathome.berkeley.edu/workunit.php?wuid=444107632
ap_14mr09ag_B3_P1_00318_20090514_02342.wu http://setiathome.berkeley.edu/workunit.php?wuid=443422528
-
I have an allocation for
ap_06mr09ad_B3_P1_00101_20090518_30837.wu http://setiathome.berkeley.edu/workunit.php?wuid=444843376
I've applied the compressibility test, and it is not compressible: the acid test will come when I run it in a day or two, but provisionally the start date for the stuck bit is pulled forward from 02mar to 06mar.
-
I have an allocation for
ap_06mr09ad_B3_P1_00101_20090518_30837.wu http://setiathome.berkeley.edu/workunit.php?wuid=444843376
I've applied the compressibility test, and it is not compressible: the acid test will come when I run it in a day or two, but provisionally the start date for the stuck bit is pulled forward from 02mar to 06mar.
Thanks! I'd gathered a short list of five 06mr09ad_B3_P1 WUs to monitor, was thinking of looking for some 04mr09ac samples too. The compessibility test is sufficiently diagnostic, I think.
If you get a chance, would you get the value out of the
<data_desc>
<start>
<time>
field and convert it to UTC? The OnlineConversion.com Julian Date Converter (http://www.onlineconversion.com/julian_date.htm) or similar will tell us the actual start time of the WU, being an 'ad' it could actually be March 7 or even 8 data.
Joe
-
I've just returned a couple from 09mr09aa (http://setiathome.berkeley.edu/result.php?resultid=1228931844)
and 10mr09aa (http://setiathome.berkeley.edu/result.php?resultid=1229041933)
F.
-
Thanks! I'd gathered a short list of five 06mr09ad_B3_P1 WUs to monitor, was thinking of looking for some 04mr09ac samples too. The compessibility test is sufficiently diagnostic, I think.
If you get a chance, would you get the value out of the
<data_desc>
<start>
<time>
field and convert it to UTC? The OnlineConversion.com Julian Date Converter (http://www.onlineconversion.com/julian_date.htm) or similar will tell us the actual start time of the WU, being an 'ad' it could actually be March 7 or even 8 data.
Joe
The raw time in that field is 2454897.5549821, which converts to Sat 7 March 2009 01:19:10 using onlineconversion.
Edit - I've given it a bump start, and it's running normally - as would be expected from the compression test.
-
I have one that failed today and one that passed... A soon as the Forums are back I will post which they are...
BTW, I tried to consolidate the discussion to a single thread...
Edit
Okay
ap_12ja09ae_B3_P1_00110_20090307_15552.wu http://setiathome.berkeley.edu/workunit.php?wuid=422182744
Error
ap_21mr09ad_B3_P1_00134_20090510_28001.wu http://setiathome.berkeley.edu/workunit.php?wuid=441959393
ap_10mr09ab_B3_P1_00338_20090516_24490.wu http://setiathome.berkeley.edu/workunit.php?wuid=443962960
ap_12mr09ab_B3_P1_00026_20090516_23480.wu http://setiathome.berkeley.edu/workunit.php?wuid=444107319
-
Edit - I've given it a bump start...
Oooof - that was a crunch-and-a-half - "percent blanked: 82.71". Maybe the bit got stuck during the recording ;D ?
I've preserved the datafile for http://setiathome.berkeley.edu/result.php?resultid=1231307250
-
Oooof - that was a crunch-and-a-half - "percent blanked: 82.71". Maybe the bit got stuck during the recording ;D ?
The other one I've seen completed, 1231344675 (http://setiathome.berkeley.edu/result.php?resultid=1231344675), had "percent blanked: 87.79". That was about 15 minutes later [(170 - 101)*13.42 seconds] so doesn't refute the possibility that the beginnings of the problem are being seen. WU 444908104 (http://setiathome.berkeley.edu/workunit.php?wuid=444908104) is ap_06mr09ad_B3_P1_00399_20090518_30837.wu so right at the end of that channel. Could turn out to show the full problem...
An AP WU has 8 MiB of data and each byte can have any of 256 values. If it's normal data, the incidence of each possible value should be not too far from 32768. If the stuck bit problem has started, 16 of the patterns would have a much higher incidence than the other 240. I'm not sure what tool would be useful for that kind of check.
Joe
-
[quote awuhor=Josef W. Segur link=topic=584.msg17864#msg17864 date=1242835690]
An AP WU has 8 MiB of data and each byte can have any of 256 values. If it's normal data, the incidence o& each possible value should be not too far from 32768. If the stuck bit problem has started, 16 of the patterns would have a much higher incidence than the other 240. I'm not sure what tool would be useful for that kind of check.
Joe
[/quote]
Doesn't take long to knock one up.
Which bytes would you expect to be most common?
[attachment deleted by admin]
-
Answering my own question - here are the counts for one of the early ones I captured (ap_12mr09ag_B3_P1_00347_20090427_00597)
[attachment deleted by admin]
-
Answering my own question - here are the counts for one of the early ones I captured (ap_12mr09ag_B3_P1_00347_20090427_00597)
Hmm, I was expecting the 16 most frequent to be even more domioanp based on my viewing a few of those files as hex. That is, I expected almost everything to be one of these:
binary dec
00000000 0
00000010 2
00001000 8
00001010 10
00100000 32
00100010 34
100 00 40
00101010 42
10000000 128
10000010 130
10001000 136
10100000 1604br />1010000 162
10101000 168
10101010 170
Having 01010101 85 come in as the next most frequent pa4tern is very interesting. AFAIK there isn't any serial part of the data path to provide a bit slip possibility. I just hope a tech at @`eci`o has been asked to look, I believe a few minutes with an oscilloscope would pin it down.
Joe
-
Well, here's the guts of the counter I'm using - crude, but takes less time than r112 to process a WU ;D
Open Path + File For Binary As #1
[skip header]
For i = 1 To 8388608 1; L˙op until end of file.
MyChar = Input(1, #1)&n 3p; ' Get one character.
MyCharAsc = Asc(MyChar)
CharBin(MyCharAsc) = CharBin(MyCharAsc) + 1
Next i
Had to use binary and 'For i...' because otherwise it stopped on crtl-Z = EOF - good sign.
Here's another count for ap_13mr09aa_B3_P1_0026 20010426_20382.wu as a check.
ap_06mr09ae_B3_P1_00186_20090520_01005.wu is not compressible.
[attachment deleted by admin]
-
Golly, don't you think a fully optimized version would be better? ;)
As noted in the NC forum, 07mr09aa B3_P1 WUs are OK but 08mr09aa have the problem (and thanks for confirming the latter). The 07mr09ab file is being split now, and from aoschedule (http://www.naic.edu/vscience/schedule/scedfra2.htm) I think it may get the start time of the problem down to within 12 hours or so.
While searching out those WUs, I was watching for old Astropulse WUs too. Saw one from Jan 18 2009 which I judge probably still being reissued. But I also saw two from early October 2008 which seem more likely to be victims of a database failure (and one MB from January 2007 too).
Joe