hsgamma_FGRP5_1.08_windows_intelx86__FGRPSSE.exe sometimes runs about 13 processes using a total of about 230 MB RAM. My RAM-starved PC (8 GB with 700 MB used by Chrome alone) isn’t happy. Can I free up the RAM FGRP5 uses when I am active on the PC?
Just now it dropped to the same 13 processes using a total of about 38 MB RAM. I can live with that. Maybe it took a while to switch from full speed to throttled while my PC is in use? If so, why did it take so long (~15 minutes)
This thread started 9/5/23 with “The FGRP1BG (G for GPU) search will wind down (for now, see below) and will run out of new work in approximately 2 to 3 weeks from now.” So why is it running on my PC a year later?
Can I tell Einstein@Home to use the 128 GB memory card in a slot on my laptop instead of the 8 GB internal RAM?
If you need the specs on my PC or some logs, let me know what would help.
I’m a long time Seti@home user but pretty new to Einstein@Home.
You are confused. Yes, the FGRPB1G GPU tasks DID run out over a year ago.
You are running the FGRP5 CPU tasks currently. Not the same thing. Plenty of them to be found with the available data from the researchers still feeding the pipeline.
Please understand that the "Tech News" forum is where the Staff post important information about any problems with or changes to the project that all users need to be aware of. For that reason, it shouldn't be used for basic user help. You should use a more appropriate forum such as "Getting Started" or "Problems and Bug Reports".
Since you mention 'laptop' and '13 processes', please understand that your real problem is more likely to be one of overloading/overheating your CPU due to too many concurrent compute intensive jobs. You may be seeing high temperatures leading to throttling. To avoid this, you can change the % of processors BOINC is allowed to use, either on the website or locally in BOINC Manager. Depending on how well your laptop cooling works, you may need to heavily restrict the number of concurrent threads. Changing the pref setting locally makes it easier to test performance on that machine without needing to force a project update after each change. Run a single task to establish best performance and see how that degrades as you increase the number of cores being used.
For further discussion, please start a new thread in a more appropriate forum.
Reply for Gary and Bernd, spinoff from the O3AS thread. re: BRP7 validation.
many have noticed that the BRP7 application has a periodic or cyclical nature with invalid results, especially if you are on Linux. you can easily see this behavior in the cyclical nature of credit reward for hosts/users running BRP7 24/7 at a near constant rate. the cycles of invalids cause a direct dip in credit reward.
there seems to be a lot of contributing factors to this behavior, not a single smoking gun.
Gary mentioned something about noisy input data. i had forgotten about that, and certainly that could be a cause. Bernd, does the noisy data come in on this kind of repeating almost predictable period?
I had theorized that the periodic invalids might be caused by large pools of users (like Science United) bringing their users to Einstein@home on this kind of weekly period. since the majority of users are Windows, and those seeming to cause more issues with Linux hosts. it could be that these big pools of users coming and going in waves, causes waves of unfavorable wingman pairing which leads to invalids on this kind of cycle. I couldnt really prove it, since SU does not export stats for Einstein for tracking their contribution in a graphical way with 3rd part stats, but they do export their stats on some other projects and it does seem that they move users in waves on certain projects like this.
I also asked Petri about it, who had a good response regarding several things that the app does which causes differences at the computation level.
Quote:
I have thought your hosts theory too. Some users run on their home computers during weekends and some user use their new/fast work computers.
The brp7 uses a weird look up table method for sin() function values. The table has 65 entries and the missing values are interpolated. The table values are floats and all calculations for angle and the interpolation are done using doubles. NVIDIA float is 32 bits, Intel CPU float is 38 bits or so and NVIDIA double is 64 bits and Intel CPU double is 80 bits. AMD (Radeon) uses 32 and 64 bits too. Fused multiply and add (fma) has higher internal accuracy for intermediate results. That is one thing.
Another thing is that when calculating average the summing order effects the sum. If you sum one by one in sequential order you begin to lose "non significant" bits when doing 16M summations when the sum is big and individual values are sometimes small. With GPU you sum up the numbers pairwise and pairwise again and again keeping better accuracy. That result to a different average (between CPU and GPU) that is used to fill the resampled FFT.
Third thing is that the fft is done in float-math. CPU vs GPU results are not identical. CUDA vs OpenCL produce slightly different results.
All that means that the 100 'best' matches for a signal may differ a lot when a completely different signal is picked up as a match. Most often the same signal is picked, but it differs at 6th or 7th decimal.
Even the project has difficulties with the official v12, v16 and v17 vs each other and v.s. CPU. The official CUDA and OpenCL sometimes do not agree even within the same version.
Thanks for all of the
)
Thanks for all of the updates. Merry Christmas everyone! Sorry to message you by mistake,
Bernd.
Cheers!
probably better to put this
)
probably better to put this here, but BRP7 seems to have run out of work now. did we crunch them all, or some problem with the WU generator?
_________________________________________________________________________
Just a lull in the work
)
Just a lull in the work generator I suppose. 53K available now.
Oh my, where to
)
Oh my, where to start?
hsgamma_FGRP5_1.08_windows_intelx86__FGRPSSE.exe sometimes runs about 13 processes using a total of about 230 MB RAM. My RAM-starved PC (8 GB with 700 MB used by Chrome alone) isn’t happy. Can I free up the RAM FGRP5 uses when I am active on the PC?
Just now it dropped to the same 13 processes using a total of about 38 MB RAM. I can live with that. Maybe it took a while to switch from full speed to throttled while my PC is in use? If so, why did it take so long (~15 minutes)
This thread started 9/5/23 with “The FGRP1BG (G for GPU) search will wind down (for now, see below) and will run out of new work in approximately 2 to 3 weeks from now.” So why is it running on my PC a year later?
Can I tell Einstein@Home to use the 128 GB memory card in a slot on my laptop instead of the 8 GB internal RAM?
If you need the specs on my PC or some logs, let me know what would help.
I’m a long time Seti@home user but pretty new to Einstein@Home.
radiodave
KB6UYP?WQYV533
You are confused. Yes, the
)
You are confused. Yes, the FGRPB1G GPU tasks DID run out over a year ago.
You are running the FGRP5 CPU tasks currently. Not the same thing. Plenty of them to be found with the available data from the researchers still feeding the pipeline.
David Reichard wrote:Oh my,
)
Hi David,
Thank you for supporting the E@H project.
Please understand that the "Tech News" forum is where the Staff post important information about any problems with or changes to the project that all users need to be aware of. For that reason, it shouldn't be used for basic user help. You should use a more appropriate forum such as "Getting Started" or "Problems and Bug Reports".
Since you mention 'laptop' and '13 processes', please understand that your real problem is more likely to be one of overloading/overheating your CPU due to too many concurrent compute intensive jobs. You may be seeing high temperatures leading to throttling. To avoid this, you can change the % of processors BOINC is allowed to use, either on the website or locally in BOINC Manager. Depending on how well your laptop cooling works, you may need to heavily restrict the number of concurrent threads. Changing the pref setting locally makes it easier to test performance on that machine without needing to force a project update after each change. Run a single task to establish best performance and see how that degrades as you increase the number of cores being used.
For further discussion, please start a new thread in a more appropriate forum.
Cheers,
Gary.
Reply for Gary and Bernd,
)
Reply for Gary and Bernd, spinoff from the O3AS thread. re: BRP7 validation.
many have noticed that the BRP7 application has a periodic or cyclical nature with invalid results, especially if you are on Linux. you can easily see this behavior in the cyclical nature of credit reward for hosts/users running BRP7 24/7 at a near constant rate. the cycles of invalids cause a direct dip in credit reward.
there seems to be a lot of contributing factors to this behavior, not a single smoking gun.
Gary mentioned something about noisy input data. i had forgotten about that, and certainly that could be a cause. Bernd, does the noisy data come in on this kind of repeating almost predictable period?
I had theorized that the periodic invalids might be caused by large pools of users (like Science United) bringing their users to Einstein@home on this kind of weekly period. since the majority of users are Windows, and those seeming to cause more issues with Linux hosts. it could be that these big pools of users coming and going in waves, causes waves of unfavorable wingman pairing which leads to invalids on this kind of cycle. I couldnt really prove it, since SU does not export stats for Einstein for tracking their contribution in a graphical way with 3rd part stats, but they do export their stats on some other projects and it does seem that they move users in waves on certain projects like this.
I also asked Petri about it, who had a good response regarding several things that the app does which causes differences at the computation level.
seems like many things are causing this.
_________________________________________________________________________