SETI@home v8 beta to begin on Tuesday

Message boards : News : SETI@home v8 beta to begin on Tuesday
Message board moderation

To post messages, you must log in.

Previous · 1 . . . 92 · 93 · 94 · 95 · 96 · 97 · 98 . . . 99 · Next

AuthorMessage
TBar
Volunteer tester

Send message
Joined: 2 Jul 13
Posts: 505
Credit: 2,051,937
RAC: 940
Message 61387 - Posted: 26 Oct 2017, 19:03:08 UTC - in response to Message 61384.  

The last one is easy, the new OS doesn't work at all with the SoG App, I'd say that is good reason for an update.


OS for that case sample is 16.7 - is it new or not? SoG worked OK on that host. It's possible that he updated OS just very recently though...

He could update the OS tonight, or sooner for all we know.
I'm going to change the "number" to Most. From what I just saw, Most Macs in All OSes are having this "New" Error. So, we go from none of the Macs on Beta having this error for almost a Year, to, Most of the Macs on Main in all OS versions having this error. How likely is that?
ID: 61387 · Report as offensive     Reply Quote
TBar
Volunteer tester

Send message
Joined: 2 Jul 13
Posts: 505
Credit: 2,051,937
RAC: 940
Message 61388 - Posted: 26 Oct 2017, 19:15:05 UTC - in response to Message 61386.  

And while we are on active page - there is another issue to think about - validness of validation process.
When "tiebreaker" task sent to same anonymous platform app that 2 (or more) other tasks were it can't be named "validation".
Preferably each pair should be sent to different plan class apps. And if third result required task should be sent preferably to stock CPU plan class host.
With current resends scheduling we easely will have subsets of incorrect results that passed validator just because happened to land to host with same malfunction (that probability can be GREATLY reduced by choosing different plan class apps, especially for GPU plan classes and anonymous platform apps).

I vote we do this for the Windows AstroPulse ATI machines. I just got robbed again by two of these notoriously Bad Windows AMD machines. I'm going to get robbed again very soon as once again two of these known bad machines are teaming up against my known Good Linux ATI machine. My ATI machine has a perfect record until it gets assaulted by two of these Windows machines, https://setiathome.berkeley.edu/workunit.php?wuid=2719529050 Can we please stop this robbery?
ID: 61388 · Report as offensive     Reply Quote
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,679
RAC: 0
Message 61389 - Posted: 26 Oct 2017, 21:35:15 UTC - in response to Message 61388.  

And while we are on active page - there is another issue to think about - validness of validation process.
When "tiebreaker" task sent to same anonymous platform app that 2 (or more) other tasks were it can't be named "validation".
Preferably each pair should be sent to different plan class apps. And if third result required task should be sent preferably to stock CPU plan class host.
With current resends scheduling we easely will have subsets of incorrect results that passed validator just because happened to land to host with same malfunction (that probability can be GREATLY reduced by choosing different plan class apps, especially for GPU plan classes and anonymous platform apps).

I vote we do this for the Windows AstroPulse ATI machines. I just got robbed again by two of these notoriously Bad Windows AMD machines. I'm going to get robbed again very soon as once again two of these known bad machines are teaming up against my known Good Linux ATI machine. My ATI machine has a perfect record until it gets assaulted by two of these Windows machines, https://setiathome.berkeley.edu/workunit.php?wuid=2719529050 Can we please stop this robbery?


This should be done on scheduler server level, for all plan classes and all apps.

Regarding Windows ATi AP - could you define subset that should be excluded? I know my own Ati Windows GPU handle AP just well, for example.
News about SETI opt app releases: https://twitter.com/Raistmer
ID: 61389 · Report as offensive     Reply Quote
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,679
RAC: 0
Message 61390 - Posted: 26 Oct 2017, 21:36:30 UTC - in response to Message 61387.  

The last one is easy, the new OS doesn't work at all with the SoG App, I'd say that is good reason for an update.


OS for that case sample is 16.7 - is it new or not? SoG worked OK on that host. It's possible that he updated OS just very recently though...

He could update the OS tonight, or sooner for all we know.
I'm going to change the "number" to Most. From what I just saw, Most Macs in All OSes are having this "New" Error. So, we go from none of the Macs on Beta having this error for almost a Year, to, Most of the Macs on Main in all OS versions having this error. How likely is that?

Quite unlikely.

Eric, could you check that CL file not omitted for example or named wrongly or smth alike.
Silent death usually occurs when no correct CL file found at all.
News about SETI opt app releases: https://twitter.com/Raistmer
ID: 61390 · Report as offensive     Reply Quote
Richard Haselgrove
Volunteer tester

Send message
Joined: 3 Jan 07
Posts: 1444
Credit: 3,263,946
RAC: 0
Message 61403 - Posted: 2 Nov 2017, 16:54:00 UTC - in response to Message 61390.  

Eric, could you check that CL file not omitted for example or named wrongly or smth alike.
Silent death usually occurs when no correct CL file found at all.
Raistmer,

You can test that in seconds, by getting someone with a Mac to attach to both Main and Beta: compare the files you receive and the entries made (especially <app_version>) in client_state.xml

@ Eric and Raistmer,

Have a look at the main project thread Mac Client Bug which user 'Havoc' started this morning. It is abundantly clear that:

a) 'CL file missing' fails as an explanation
b) TBar is talking rubbish, as usual.

The app is showing errors, but at a very low rate - 1% or 2% max. That can't be a deployment error.

Havoc linked a workunit where two different Mac hosts both running the same app had both errored out with the same error: two Windows computers had completed and validated.

All of this suggests to me that the application fails on certain types / classes / examples of workunits only: from the examples in the linked threads the vast majority of tasks run successfully.

We have had this before: one of Raistmers apps passed testing here at Beta, but failed with excessive memory usage when exposed to a wider range of tasks on Main. I suspect something similar is happening now.

If the app has been deployed for testing here at Beta for a year, then it probably also needs revising to take account of the substantial changes in Mac OS X last month.
ID: 61403 · Report as offensive     Reply Quote
TBar
Volunteer tester

Send message
Joined: 2 Jul 13
Posts: 505
Credit: 2,051,937
RAC: 940
Message 61406 - Posted: 3 Nov 2017, 8:40:18 UTC - in response to Message 61403.  

Just a little update on a few Mac Apps. These Apps have more in common than the version numbers;
(Main) 8.19r3551 (opencl_nvidia_mac)
(Main) 8.20r3552 (opencl_ati5_mac)
(Beta) 8.19r3553 (opencl_intel_gpu_sah)
They are from the Exact same code, in fact, r3551 & 3553 are the Exact same Apps. The only difference is the Name.
The only difference with the ATI App is it uses the HD5 tag instead of Intel, otherwise, it is the same.
So, when one of these three is accused of suffering some Bug, it might help your case if the other two displayed the same symptoms. That is Not the case in this instance.
The nVidia App has been running on Main for about a year, and along with it's Intel sister on Beta hasn't suffered any startup errors, or alleged particular WU problems.
This is why Raistmer and myself deem it unlikely the ATI r3552 App has suddenly, after a year, developed some isolated problem with a certain WU. The Non-SoG ATI App is much closer to the Intel builds than the SoG build and the other two 355x Apps are still going strong. I believe if you check the results at main you will find the problem exists with a wide range of WUs, GPUs, and Operating systems. Machines running Mavericks are suddenly having this problem. Mavericks is from 2013, someone care to explain to me what recent changes Mavericks has suffered?
No trash, just Fact.
ID: 61406 · Report as offensive     Reply Quote
Tutankhamon
Volunteer tester
Avatar

Send message
Joined: 10 Mar 12
Posts: 1346
Credit: 6,318,151
RAC: 3,811
Message 61410 - Posted: 3 Nov 2017, 14:46:15 UTC

No great mix of work here now.
It's 100% *DIAG_KIC*
ID: 61410 · Report as offensive     Reply Quote
Richard Haselgrove
Volunteer tester

Send message
Joined: 3 Jan 07
Posts: 1444
Credit: 3,263,946
RAC: 0
Message 61413 - Posted: 3 Nov 2017, 19:06:16 UTC - in response to Message 61406.  

Just a little update on a few Mac Apps. These Apps have more in common than the version numbers;
(Main) 8.19r3551 (opencl_nvidia_mac)
(Main) 8.20r3552 (opencl_ati5_mac)
(Beta) 8.19r3553 (opencl_intel_gpu_sah)
They are from the Exact same code, in fact, r3551 & 3553 are the Exact same Apps. The only difference is the Name.
Yes, I'd agree with that. r3551 was Raistmer's "OpenCL MB: - improvement of validation rate on overflows - debug output": r3552 and r3553 were Eric Korpela working on the Android apps, which use a completely different codebase - so his changes don't concern us here.

But it goes on from there:

Rev	Age		Author		Log Message
r3551  	12 months	raistmer	OpemCL MB: - improvement of validation rate on overflows - debug output …
r3555  	12 months	raistmer	OpenCL MB: TwinChirp? path updates
r3556  	12 months	raistmer	OpenCL MB: - massive improvement in overflow validation rate - bugfix for …
r3557  	12 months	raistmer	OpenCL MB: - Twinchirp path separated to make compiler for FERMI-class …
r3564  	12 months	raistmer	opt MB: - FLOP counter incrementing disabled (obsolete) - progress for GPU …
r3565  	12 months	raistmer	Urs' changes: - fix : SmallInts? to double conversion problems in …
r3566  	12 months	raistmer	OpenCL MB: -WG size fix
r3567  	12 months	raistmer	OpenCL/CPU MB: - fix for PulseFind? in TwinChirp? path - WG size selection …
r3568  	12 months	raistmer	OpenCL MB: -CPUlock re-done - SoG and APU paths incompatibility check …
r3570  	11 months	raistmer	OpenCL MB: - compatibility fixes for Linux.modern compilers - …
r3571  	11 months	raistmer	Windows OpenCL MB: - new configs added
r3574  	11 months	raistmer	OpenCL MB TwinChirp?: -bugfixes
r3578  	11 months	raistmer	OpenCL SoG MB: - make sure that at least 100 times through task progress …
r3581  	11 months	raistmer	OpenCL MB: - subtle synchronization bug fixed in TwinChirp? path
r3584  	11 months	raistmer	OpenCL MB: -Urs' *nix changes: + version to 8.22 + several make file …
r3585  	11 months	raistmer	OpenCL MB: - iGPU event handling
r3600  	10 months	raistmer	MB: -added missing VS2010 solution file.
r3602  	10 months	raistmer	OpenCL: - making errors in profiling recoverable
r3604  	10 months	raistmer	MultiBeam?: - making sources compatible with new (C++11) compilers (thanks …
r3605  	10 months	raistmer	MultiBeam?: -enabling higher than SSE2 SIMD levels for MSVC-based x64 …
r3623  	9 months	raistmer	MultiBeam?: - making VS2010 config for x64 graphics binary workable
r3631  	9 months	raistmer	MultiBeam? for Linux on ARM hard float: - merging EABI params …
r3632  	9 months	raistmer	"MultiBeam?: - making VS2008 solution buildable for Win x64, both app and …"
r3633  	9 months	raistmer	MultiBeam?: - fix VFP ChirpData? for armhf - both NEON and VFP chirp enabled …
r3643  	8 months	raistmer	MultiBeam?: - Tom Rinehart's fix for fpu_ChirpData in ARM path
r3658  	7 months	raistmer	-added VS2015 config -make sources compatible with VC2015
r3674  	6 months	raistmer	MultiBeam?: -added VS2017 config -preparations for PGO
And that's just the code changes. As you know from your own experience with BOINC code, different operating systems require different compilers and different build settings.

Let me give you an example of what can happen. Just before that sequence of changes, round about r3541, Raistmer and I were having a similarly inconclusive conversation about the poor validation rates for the intel_gpu app on Haswell chips under Windows. We weren't making any progress, so I went out and bought an HD530 (i5-6500) for testing. Raistmer and I spent a whole weekend running through the possibilities: every hour or two, he'd email me another build, I'd run it under the bench test suite, and I'd reply "No, still not accurate enough."

The initial assumption was that the iGPU drivers were causing the problem? Nope. The Intel FFT implementation? Nope. Something in code? Couldn't find it. Finally - Eureka: the accuracy shot up and we were good to go. That turned out to be a compiler optimisation flag set too high - the code ran fast, but lost accuracy. With a lower setting, less speed, but better results.

In the thread at Main, people are saying that the temporary exit event log message is

Task postponed: Suspicious pulse results, host needs reboot or maintenance
I'm sorry, but I don't believe that every Mac attached to BOINC needs maintenance that often: it sounds more like an inaccuracy in the application triggering a sanity check more than necessary. I'd suggest that it's the app that needs maintenance to find and correct the cause of the inaccuracy, the same as Raistmer and I did last year for the iGPU.
ID: 61413 · Report as offensive     Reply Quote
TBar
Volunteer tester

Send message
Joined: 2 Jul 13
Posts: 505
Credit: 2,051,937
RAC: 940
Message 61414 - Posted: 3 Nov 2017, 21:02:02 UTC - in response to Message 61413.  

Just a little update on a few Mac Apps. These Apps have more in common than the version numbers;
(Main) 8.19r3551 (opencl_nvidia_mac)
(Main) 8.20r3552 (opencl_ati5_mac)
(Beta) 8.19r3553 (opencl_intel_gpu_sah)
They are from the Exact same code, in fact, r3551 & 3553 are the Exact same Apps. The only difference is the Name.
Yes, I'd agree with that. r3551 was Raistmer's "OpenCL MB: - improvement of validation rate on overflows - debug output": r3552 and r3553 were Eric Korpela working on the Android apps, which use a completely different codebase - so his changes don't concern us here....
I'm sorry, but I don't believe that every Mac attached to BOINC needs maintenance that often: it sounds more like an inaccuracy in the application triggering a sanity check more than necessary. I'd suggest that it's the app that needs maintenance to find and correct the cause of the inaccuracy, the same as Raistmer and I did last year for the iGPU.
I'll repeat it in a little more detail. All three of those App were compiled from the Exact same r3551 folder. The only reason the version numbers are different is so they will produce a different Wisdom file on the same machine. Make clean was used between compiles with slight changes between compiles, they are basically the Same App, meaning, they all will have the exact same bugs, or not. I'm still not buying one App out of the three has suddenly developed a bug that didn't exist for the Year of the Apps existence. Those current Errors are occurring in Older OSes and GPUs that have Not Changed in the past year. That would mean it is the App that has changed somehow. I would suggest trying a fresh copy of the App and if that doesn't work go with r3610 which has been run on machines on Main without any trouble for the better part of a year.
ID: 61414 · Report as offensive     Reply Quote
Richard Haselgrove
Volunteer tester

Send message
Joined: 3 Jan 07
Posts: 1444
Credit: 3,263,946
RAC: 0
Message 61415 - Posted: 3 Nov 2017, 22:44:15 UTC - in response to Message 61414.  

Were the exact same three compilers, with the same three sets of configuration settings, used for all apps? I buy the rest of the explanation, but not that one.
ID: 61415 · Report as offensive     Reply Quote
TBar
Volunteer tester

Send message
Joined: 2 Jul 13
Posts: 505
Credit: 2,051,937
RAC: 940
Message 61416 - Posted: 4 Nov 2017, 0:02:03 UTC - in response to Message 61415.  
Last modified: 4 Nov 2017, 0:02:30 UTC

Were the exact same three compilers, with the same three sets of configuration settings, used for all apps? I buy the rest of the explanation, but not that one.
All three Apps were compiled during a 3 hour period using the same source folder and probably the same Terminal window. The only difference is one used -DUSE_OPENCL_HD5xxx while the other 2 used -DUSE_OPENCL_INTEL, and the version numbers were changed in the Makefile. Basically, if you're having problems with one, you should have the same problems with the other two. Check the creation times, they will read;
MBv8_8.19r3552_ati5_ssse3_x86_64-apple-darwin
5,547,108 bytes (5.6 MB on disk)
Saturday, November 5, 2016 at 1:41 AM
MBv8_8.19r3551_NV_ssse3_x86_64-apple-darwin
5,543,040 bytes (5.5 MB on disk)
Saturday, November 5, 2016 at 4:05 AM
MBv8_8.19r3553_Intel_ssse3_x86_64-apple-darwin
5,543,040 bytes (5.5 MB on disk)
Saturday, November 5, 2016 at 4:18 AM
Busy night.
ID: 61416 · Report as offensive     Reply Quote
Richard Haselgrove
Volunteer tester

Send message
Joined: 3 Jan 07
Posts: 1444
Credit: 3,263,946
RAC: 0
Message 61417 - Posted: 4 Nov 2017, 17:18:45 UTC - in response to Message 61416.  

Fair enough. But be aware that Raistmer makes extensive use of #if constructs in his code, so changing those compiler directive flags effectively means you're changing the contents of the code files - you're using different parts of them. For example,

...
#elif USE_OPENCL_HD5xxx
#if __APPLE__
    strcpy(buildoptions,"-w -D__APPLE__ -cl-unsafe-math-optimizations -DUSE_OPENCL_HD5xxx");
#else
		strcpy(buildoptions,"-w -cl-unsafe-math-optimizations -DUSE_OPENCL_HD5xxx -fno-bin-amdil");
#endif
...
- that's one line of code that will only be used with ATI HD5 on a Mac, with a different version for other platforms (it's from GPU_lock.cpp, line 702). There will be many other examples scattered throughout the code files.
ID: 61417 · Report as offensive     Reply Quote
TBar
Volunteer tester

Send message
Joined: 2 Jul 13
Posts: 505
Credit: 2,051,937
RAC: 940
Message 61418 - Posted: 4 Nov 2017, 18:11:36 UTC - in response to Message 61417.  
Last modified: 4 Nov 2017, 18:22:12 UTC

It all becomes mute once you accept that just about All the Mac AMD machines on Main are having this error within seconds of launch at least every day or two, and that NONE of the machines at Beta had this error over almost a year. Have you accepted that most of the Macs on Main are having this error? Because once you accept that, it's impossible for a rational person to to think this error went unnoticed on Beta for almost a year. There are just too many machines having this error to think it escaped Beta if it was occurring on that many machines.
It sounds as though you've accepted it back here,
I'm sorry, but I don't believe that every Mac attached to BOINC needs maintenance that often..
Can you rationally explain how such a widespread problem could escape Beta for almost a year?
Oh, am I still talking 'rubbish' now that you've accepted that just about every AMD Mac on Main is having this Error?
ID: 61418 · Report as offensive     Reply Quote
Richard Haselgrove
Volunteer tester

Send message
Joined: 3 Jan 07
Posts: 1444
Credit: 3,263,946
RAC: 0
Message 61419 - Posted: 4 Nov 2017, 19:18:43 UTC - in response to Message 61418.  

And they are having it relatively rarely. As Tut pointed out again today, the Beta site commonly supplies a very limited range of work types. And as I've pointed out during this conversation, there is at least one previous example of an application having no problems at Beta, but developing problems at Main when they encountered workunit characteristics that weren't tested here.

The usual next step is to download the datafile for one or more of the tasks which have failed in live running, and try them again offline 'under the microscope' as a bench test on the type of computer which is failing them.
ID: 61419 · Report as offensive     Reply Quote
TBar
Volunteer tester

Send message
Joined: 2 Jul 13
Posts: 505
Credit: 2,051,937
RAC: 940
Message 61420 - Posted: 5 Nov 2017, 0:43:44 UTC - in response to Message 61419.  

It should be the shortest test in some time. The App launches and in about 7 seconds it either continues running or spits out an error and moves to the next task, not much to test there. Was this memory error you keep mentioning that easy to see, or did you have to look at some tool and see how much memory was being used? The one is pretty easy to see -> run for 7 seconds and error with an error result which on Beta stays for quite a while. From what I've seen the Macs on Main are having this error with all types of WUs, OSes, and GPUS above the 6 series. I haven't seen an AMD 5 series with this error...yet. Certainly there are machines on Beta that would have produced this error after a year of trying, if the error was present on Beta. The Error appeared on Main after just one day.
ID: 61420 · Report as offensive     Reply Quote
TBar
Volunteer tester

Send message
Joined: 2 Jul 13
Posts: 505
Credit: 2,051,937
RAC: 940
Message 61421 - Posted: 5 Nov 2017, 5:27:39 UTC

After another scroll down the Hosts list it seems most of the machines receiving -226 (0xFFFFFF1E) ERR_TOO_MANY_EXITS with v8.20r3552 (opencl_ati5_mac) App are running Arecibo tasks. There are a few running v8.20r3552 with BLC tasks receiving a different error, 197 (0x000000C5) EXIT_TIME_LIMIT_EXCEEDED. However, it seems the TIME_LIMIT_EXCEEDED error was also occurring with the older v8.00r3321 App, https://setiathome.berkeley.edu/results.php?hostid=8353212&state=6 where the TOO_MANY_EXITS error is new to Main.

I did find a couple machines running the nVidia v8.19r3551 receiving the -226 (0xFFFFFF1E) ERR_TOO_MANY_EXITS error, but they were running Non-Apple GPUs on a Mac, or, were running a Hackintosh with Non-Apple GPUs. I didn't find any Apple nVidia GPUs receiving the TOO_MANY_EXITS error. So, it appears r3551 may be a little touchy with the TOO_MANY_EXITS error even though there aren't any of those errors on Beta.
ID: 61421 · Report as offensive     Reply Quote
Richard Haselgrove
Volunteer tester

Send message
Joined: 3 Jan 07
Posts: 1444
Credit: 3,263,946
RAC: 0
Message 61422 - Posted: 5 Nov 2017, 10:05:23 UTC - in response to Message 61421.  

So, it appears r3551 may be a little touchy with the TOO_MANY_EXITS error even though there aren't any of those errors on Beta.
Yes, I would agree with that description. I'd also agree that a loss of 7 seconds elapsed time doesn't look too bad on the face of it, but I'm a little suspicious about BOINC's time recording at those very small levels - I'm not sure it fully accounts for the setup time before crunching really gets under way. Also, if an app exits before the first checkpoint, the elapsed time is rewound to zero for the restart. We might be looking at 700 seconds (for the 100 attempts) - we'd probably have to pore through an event log to check that.

The memory problem caused quite a stir on the Main forum when it happened, but it was some time ago: IIRC, it was after one of the big upgrades, possibly SAH v6 to v7. It'll take some finding, but I'll have a look.
ID: 61422 · Report as offensive     Reply Quote
TBar
Volunteer tester

Send message
Joined: 2 Jul 13
Posts: 505
Credit: 2,051,937
RAC: 940
Message 61423 - Posted: 5 Nov 2017, 18:10:09 UTC - in response to Message 61422.  

The best fix for the AMD GPUs is running on Beta right now, and appears to be doing well, http://setiweb.ssl.berkeley.edu/beta/setiathome_v8_x86_64-apple-darwin__opencl_ati5_mac.html
The question is how long will it take to move it to Main.
The other OpenCL r3551 App is doing well with the Apple nVidia GPUs, but giving errors with some of the Non-Apple supplied nVidia GPUs. I use the CUDA App, which doesn't have any trouble with the Non-Apple nVidia GPUs...providing you use the correct CUDA driver. One CUDA App that is giving problems is the 8.11 (cuda75_mac) App. As with the Linux Apps, the older nVidia GPUs don't work well with anything above CUDA 6.0, and most of the Older GPUs are not working with the 8.11 (cuda75_mac) Baseline App as seen here, https://setiathome.berkeley.edu/results.php?hostid=7823473&state=5. For some reason the Server isn't sending that Host the CUDA 4.2 App which would probably work just fine with the older GPU. Since the Baseline CUDA 75 Mac App is just slightly faster than the CUDA 42 App, and doesn't work on the older Apple supplied nVidia GPUs, it should probably be removed. Any GPU that can work with the Baseline CUDA 75 App can also work with the CUDA 42 App, and probably work successfully. I would recommend the 8.11 (cuda75_mac) Baseline App be removed from Main and Beta and the 8.11 (cuda42_mac) plan class allow the App to work on all nVidia GPUs. That would probably eliminate a few Inconclusive/Invalid results being produced by the Older GPUs running the 8.11 (cuda75_mac) Baseline App. The newer Non-Apple nVidia GPUs with CC=5.0 and above should be using the CUDA 75 Special App anyway, it's much better than the Baseline App and seems to be working well;
https://setiathome.berkeley.edu/results.php?hostid=7942417&offset=320
https://setiathome.berkeley.edu/results.php?hostid=4726043&offset=120
ID: 61423 · Report as offensive     Reply Quote
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,679
RAC: 0
Message 61424 - Posted: 5 Nov 2017, 22:41:14 UTC - in response to Message 61403.  


You can test that in seconds, by getting someone with a Mac to attach to both Main and Beta: compare the files you receive and the entries made (especially <app_version>) in client_state.xml


Those seconds will be weeks in real life it seems.
News about SETI opt app releases: https://twitter.com/Raistmer
ID: 61424 · Report as offensive     Reply Quote
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,679
RAC: 0
Message 61425 - Posted: 5 Nov 2017, 22:42:44 UTC - in response to Message 61422.  


The memory problem caused quite a stir on the Main forum when it happened, but it was some time ago: IIRC, it was after one of the big upgrades, possibly SAH v6 to v7. It'll take some finding, but I'll have a look.


Single memory issue I can recall is overflow with AstroPulse.
News about SETI opt app releases: https://twitter.com/Raistmer
ID: 61425 · Report as offensive     Reply Quote
Previous · 1 . . . 92 · 93 · 94 · 95 · 96 · 97 · 98 . . . 99 · Next

Message boards : News : SETI@home v8 beta to begin on Tuesday


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