Posts by Raistmer

1) Message boards : Nebula : Improved RFI browsing interface (Message 1855252)
Posted 11 days ago by Profile Raistmer
Post:
I'm curious, what is 6,5 or 4,5 beams in signal listing?
half-beam?
Time offset Det freq offset RA dec beam FFT len ID

123.37921410799 2956.4219999313 19.259386 12.258606 5.5 32768 2793446162
2) Message boards : Nebula : Drifting RFI vanquished! (Message 1855251)
Posted 11 days ago by Profile Raistmer
Post:
https://setiathome.berkeley.edu/nebula/waterfall.php?t=2455525.319763&dt=0.004&f=1418998711.1092&df=2000&spike=on&gaussian=on&pulse=on&triplet=on&autocorr=on&action=fout2

I suppose red vertical line of spikes is RFI and it gets removed by RFI removal algorithm indeed.
But what about 6 horizontal blue lines of pulses? Hitting RFI removal button doesn't remove them.
But those lines show some regularity. Especially 4 in center - equidistant ones. Actually, ones on top and bottom fit in same equidistant pattern too with one line missing .
Is it RFI? Or pulses out of consideration currently?

EDIT: it looks like periodic sequence of very short pulses (that give flat spectrum ). Something for AstroPulse to deal with, no?
3) Message boards : Cafe SETI : Happy 8 March (Message 1853836)
Posted 16 days ago by Profile Raistmer
Post:
To all women of SETI project!
4) Message boards : Number crunching : Linux (ARM processor) app and alternatives (Message 1853417)
Posted 18 days ago by Profile Raistmer
Post:
We have on main:

Android (ARM64 processor) 8.00 (arm64-neon) 22 Jan 2016, 0:38:52 UTC 231 GigaFLOPS
Android (ARM64 processor) 8.00 (arm64-vfpv4) 22 Jan 2016, 0:38:52 UTC 224 GigaFLOPS
Android (ARM64 processor) 8.01 4 Jan 2017, 3:33:29 UTC 111 GigaFLOPS

What those neon and vfp plan classes mean then?

EDIT: for beta list even wider:
Android (ARM64 processor) 8.00 4 Nov 2016, 19:09:50 UTC 1 GigaFLOPS
Android (ARM64 processor) 8.00 (api24) 23 Feb 2017, 20:28:26 UTC 0 GigaFLOPS
Android (ARM64 processor) 8.01 (arm64-neon) 5 Jan 2016, 23:44:30 UTC 6 GigaFLOPS
Android (ARM64 processor) 8.01 (arm64-vfpv4) 5 Jan 2016, 23:44:30 UTC 5 GigaFLOPS
Linux (ARM64 processor) 8.01 10 Feb 2017, 21:46:51 UTC 6 GigaFLOPS

As I understand you both speaking about last one, Linux one.
But what about Android-based?
Do they show bench results? Android comletely on Eric as I understand. Who built Linux A64?
5) Message boards : Number crunching : Linux (ARM processor) app and alternatives (Message 1853320)
Posted 18 days ago by Profile Raistmer
Post:
if run with -verb ?
6) Message boards : Number crunching : Looking for Linux x64 optimized apps (Message 1852403)
Posted 21 days ago by Profile Raistmer
Post:
Looking at the AVX one its r3345 by Urs.

The stock app is r3584 so is more recent than the AVX app.


For CPU stock and opt have different code bases so uncomparable just by rev number.
7) Message boards : Number crunching : Linux (ARM processor) app and alternatives (Message 1852021)
Posted 24 days ago by Profile Raistmer
Post:
I also wonder if I will be able to compile the Open CL app to run on its Mali-T628 MP6 GPU (it supports OpenCL 1.1 Full profile).

That's would be interesting indeed. AFAIK Urs also made some experiments with Mali. Maybe he could provide some hints here.
8) Message boards : Number crunching : Linux (ARM processor) app and alternatives (Message 1852019)
Posted 24 days ago by Profile Raistmer
Post:
Similar situation with Windows x64 builds driven me to different outcome: embedded benchmark, especially on multicore hosts, is very unstable thing that hardly can be trusted.
What I propose to do to make distinction between these explanations:
to make 2 builds,one with vfp_Chirp disabled,one with neon_Chirp disabled and identical otherwise.
Run them few tasks each with results + task AR logging. Then compare performance between each other _AND_ 'versatile" build that have both.
So, if switching between chirp selections is "real", not just bench artifact, we will see that "versatile" build faster on average than both fixed ones.
Or we will see what chirp really preferable on particular host.
I'm afraid this could be very long experiment though due to low performance of ARM core.

Similar could be done in more controlled environment of PG set benchmark. But again, one needs to reproduce real conditions for multicore processing (bench with both/all cores busy).
9) Message boards : SETI@home Science : Trappist-1 - did we really search it? (Message 1851913)
Posted 24 days ago by Profile Raistmer
Post:
Regarding origins of life on Earth there is one (among lots of others btw) theory that most appropriate conditions were at surroundings of geothermal geysers.
Periodical change in environment and appropriate salts contents, temperature regimes make them suitable for initial biochemistry synthesis.
10) Message boards : SETI@home Science : Proxima B (Message 1851911)
Posted 24 days ago by Profile Raistmer
Post:
Scientific American reported in late January that the scientific paper was under review for publication in Astrophysical Journal. That's presumably still the case. Link to journalistic article, below:

https://scientificamerican.com/article/signs-of-alien-air-herald-a-new-era-of-exoplanet-discoveries

yes, thanks. I found that article already but failed to find paper itself. Will see if it appears in some upcoming issue.
11) Message boards : Number crunching : Power consumption vs. Total credits (Message 1851910)
Posted 24 days ago by Profile Raistmer
Post:
You already point one uncertainty - efficiency of USB power supply.
Could you power these phones via USB plugs of very that laptop? Then measure with the same single power meter consumption of laptop alone and consumption of laptop + 1 or 2 phones.

Also carefully check that AR of tasks processed by all 3 devices is the same.
I would recommend to run benchmark with known to be exactly same tasks and compute power consumption vs processing time instead of your metric. Credits awarding too unstable to use it as serious measurement instrument.
12) Message boards : SETI@home Science : Proxima B (Message 1851866)
Posted 25 days ago by Profile Raistmer
Post:
we have the recent finding that Gliese 1132 b, an exoplanet orbiting very closely to its star, has a thick, un-eroded atmosphere.

Could you post link to such observation report please.

EDIT: saw your link on news article and did search through last few issues of that journal http://iopscience.iop.org/issue/0004-637X/837/1 seems not published still. Either pending or not passed review...
13) Message boards : SETI@home Science : Trappist-1 - did we really search it? (Message 1851865)
Posted 25 days ago by Profile Raistmer
Post:
"cold" or"warm" to live depends not only on spectral class of the star but mostly from distance to the star.
I would say "too warm" for us on Mercury or too cold on Neptune. No matter that both orbiting same star as our Earth.
The pecularity of this discovery is the 3 planets happened to be in "life zone" of that particular star (with correction on its different spectral class already made). Life zone is area with expected mean ambient temperature on planet surface near zero Celsius.
Of course it depends on the particular atmosphere (if any) (compare Earth and Venus) but it's good estimate to start with.
Such placement makes this particular system on the top list of candidates to habitable planets and natural candidate for especially attentive listening for artifical signals as well.

P.S. from photosynthesis point of view red stars could be even more preferable than our Sun's G one. Red light (~600nm) is sufficient for Earth's PS1/2-based plants to make initial charge separation. Shorter waves required mostly for process control and such control mechanisms could easely be adapted to other spectral pecularities. So, having spectral maximum on longer wavelength could make photosynthesis performance even higher.
14) Message boards : Number crunching : x64 Windows CPU build testing on beta (Message 1851342)
Posted 26 days ago by Profile Raistmer
Post:
Attempted to use clang toolchain from VS2015.
Even after dealing with IUnknown issue it can't compile SETI code:

'void __cdecl _mm256_maskstore_ps(float * __ptr64,union __m256i,union __m256)': Intrinsic not yet implemented:
1> call void @llvm.x86.avx.maskstore.ps.256(i8* %6, <8 x i32> %8, <8 x float> %9)
1>D:\R\seti_boinc\client\win_build\VS2015\analyzeFuncs_avx.cpp : fatal error C1001: An internal error has occurred in the compiler.
1> (compiler file 'llvm-bridge.cpp', line 5757)
1> To work around this problem, try simplifying or changing the program near the locations listed above.
1> Please choose the Technical Support command on the Visual C++
1> Help menu, or open the Technical Support help file for more information
1> 'union __m128 __cdecl _mm_max_ss(union __m128,union __m128)': Intrinsic not yet implemented:
1> %5 = call <4 x float> @llvm.x86.sse.max.ss(<4 x float> %3, <4 x float> %4)
1>D:\R\seti_boinc\client\win_build\VS2015\analyzeFuncs_sse.cpp : fatal error C1001: An internal error has occurred in the compiler.
1> (compiler file 'llvm-bridge.cpp', line 5757)
1> To work around this problem, try simplifying or changing the program near the locations listed above.
1> Please choose the Technical Support command on the Visual C++
1> Help menu, or open the Technical Support help file for more information
1> 'union __m128 __cdecl _mm_rcp_ps(union __m128)': Intrinsic not yet implemented:
1> %3 = call <4 x float> @llvm.x86.sse.rcp.ps(<4 x float> %2)
1>D:\R\seti_boinc\client\win_build\VS2015\analyzeFuncs_sse2.cpp : fatal error C1001: An internal error has occurred in the compiler.
1> (compiler file 'llvm-bridge.cpp', line 5757)
1> To work around this problem, try simplifying or changing the program near the locations listed above.
1> Please choose the Technical Support command on the Visual C++
1> Help menu, or open the Technical Support help file for more information
1> 'union __m128 __cdecl _mm_rcp_ps(union __m128)': Intrinsic not yet implemented:
1> %3 = call <4 x float> @llvm.x86.sse.rcp.ps(<4 x float> %2)
1>D:\R\seti_boinc\client\win_build\VS2015\analyzeFuncs_sse3.cpp : fatal error C1001: An internal error has occurred in the compiler.
1> (compiler file 'llvm-bridge.cpp', line 5757)
1> To work around this problem, try simplifying or changing the program near the locations listed above.
1> Please choose the Technical Support command on the Visual C++
1> Help menu, or open the Technical Support help file for more information
1> 'union __m128 __cdecl _mm_cvtpd_ps(struct __m128d)': Intrinsic not yet implemented:
1> %3 = call <4 x float> @llvm.x86.sse2.cvtpd2ps(<2 x double> %2)
1>D:\R\seti_boinc\client\win_build\VS2015\analyzeFuncs_x86_64.cpp : fatal error C1001: An internal error has occurred in the compiler.
1> (compiler file 'llvm-bridge.cpp', line 5757)
1> To work around this problem, try simplifying or changing the program near the locations listed above.
1> Please choose the Technical Support command on the Visual C++
1> Help menu, or open the Technical Support help file for more information


So, only VC++ so far.
15) Message boards : Number crunching : Linux (ARM processor) app and alternatives (Message 1850868)
Posted 28 days ago by Profile Raistmer
Post:
done At revision: 3643
16) Message boards : Number crunching : Linux (ARM processor) app and alternatives (Message 1850838)
Posted 29 days ago by Profile Raistmer
Post:
I'll look at that.
17) Message boards : Number crunching : Linux (ARM processor) app and alternatives (Message 1850762)
Posted 29 days ago by Profile Raistmer
Post:
Are there any proven cases of chosen fpu_chirp on hosts where it works correctly?
If it never get selected and if there is baseline replacement for it (like v_Chirp) exists I see no sense to keep it in benchmark at all.
18) Message boards : Number crunching : Linux (ARM processor) app and alternatives (Message 1850602)
Posted 22 Feb 2017 by Profile Raistmer
Post:
Well, change in size should not be puzzling.
Older Chirp used pre-computed Trigonometry arrays while optimized ones compute sin/cos in more efficient way.
Hence save on not creating TrigArray massive.

Hope we could get updated build in beta soon.

Regarding broken VFP folding - didn't spot obviouse issues so far. Need to compare line by line with original code.
From the other side Android buids are done from this new codebase and they work ("opt VFP" in some of stderrs confirm this). So, smth more complex then obvios typo there...
19) Message boards : SETI@home Science : Trappist-1 - did we really search it? (Message 1850594)
Posted 22 Feb 2017 by Profile Raistmer
Post:
In NASA's pressconference there was statement that SETI already listen this system and got no signal.

How much did we really listen it?
20) Message boards : Number crunching : x64 Windows CPU build testing on beta (Message 1850257)
Posted 20 Feb 2017 by Profile Raistmer
Post:
Just take some patience and wait while box will be filled with data. On my x64 PC it happened for some reason...


Next 20


 
©2017 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.