FYI We are working on it. Just the GPU part (on Linux special sauce only). The CPU will remain untouched.

Hope we have news in the following weeks. Keep the fingers crossed.

---

The Check-pointing, and other items have been on the list for Years. Good Luck with that.
Freaking Hilarious some think this hasn't been thought of before.

I gather you have attempted to find the checkpointing code in the science app before and was unsuccessful.

Maybe Juan will be luckier.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Yep, Good Luck with that. Go back a few years on this board and you will find a post by Petri about removing the Checkpoint. A few people here were strongly against it, seems they should have taken him up on it back then. The Main problem with Bad Best Pulses on Shorties was around back when Jason was here, how long ago was that? Both those items were on the Top of last years to do list, instead we got 0.99, which fixed nothing, and made the code Linux only. The problem with missed pulses after boot has been narrowed down to the type of memory on the card, seems it disappears when you go from a 1070 to a 1080Ti. Unfortunately, most here don't have 1080s, and everything lower has the problem. At least time should fix that one, when people stop using GDDR5 GPUs.

How exactly did V0.99 make the app “linux only”? The only thing that was added was the mutex. And you don’t even have to use it if you don’t want to. When not running 2 WUs at a time, the code is functionally identical to V0.98.

Not that anyone was working on porting V0.98 to Windows anyway. So even without adding mutex, V0.98 would have still been linux only. The mutex bit isn’t the limiting factor for porting to Windows, and I would imagine the same thing can be implemented there. The limiting factor is lack of developer talent for CUDA on Windows to do what petri has done in Linux.

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

How exactly did V0.99 make the app “linux only”?

I think TBar is referring to the Apple family of operating systems, which I gather is a legitimate complaint.

---

The Mutex makes System calls which are not on the UNIX based Mac. If it doesn't work on another UNIX machine, the chances of it working on Windows are extremely Slim.
If you have modern Storage, the Mutex is useless. Definitely not worth making the code Linux only.

The problem with missed pulses after boot has been narrowed down to the type of memory on the card, seems it disappears when you go from a 1070 to a 1080Ti.

That sounds like a highly dubious claim. I can only assume that it implies a race condition: different kernels finishing at different times, data not being available at times when the code assumes that it is ready. That's a synchronisation problem which it is the duty of the programmer to solve.

So far my search of the message base for "checkpoint" didn't turn up anything useful. Most posts found for "checkpoint" were writing about checkpointing in context for SSD/hard drive longevity.

The only useful post I found from Petri in discussion with Raistmer was about the resorting of found pulses after stopping for a checkpoint. That devolved into the discussion of noisy work units and whether they were useful in the first place and the back and forth of whether to count 30 noisy triplets first or 30 noisy pulses first.

I'll keep looking.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I'll keep looking.

From a quick glance at the code and one of my state files, I suspect that you'll have to write to the state file as you go along, because it is the data in the state file that will eventually be returned as the result.
So what you should probably do instead, is to ignore the state file and always start from zero when the program starts (or, case in point, restarts).

---

Going back to my original suggestion which started this conversation, I said

just don't write a 'state.sah' file. That's all.

I'll run some tests on the side effects of that tomorrow - I have some suspicions that when the application 'restarts from scratch' after a recorded, but crippled, checkpoint that the timing record may be corrupted. But that's a relatively minor issue. Otherwise, the suggested change is trivial.

The Mutex makes System calls which are not on the UNIX based Mac. If it doesn't work on another UNIX machine, the chances of it working on Windows are extremely Slim.
If you have modern Storage, the Mutex is useless. Definitely not worth making the code Linux only.

which system call? can you point out which line in the namedMutex.cpp file?

is there a functional equivalent system call for MacOS? have you checked? a slight edit is probably possible to make it work on MacOS for the handful of people that are running the special app and MacOS (only you and TL come to mind). Looking through the top 500 systems, there are only 6 Darwin systems, only 2 of which (both belonging to Tbar) are running Nvidia cards. Expand that to top 1000 and you have about 20 Darwin system, and only 3 total that use nvidia cards/special app.

Apple effectively killed nvidia support on MacOS anyway...

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

The problem with missed pulses after boot has been narrowed down to the type of memory on the card, seems it disappears when you go from a 1070 to a 1080Ti.

That sounds like a highly dubious claim. I can only assume that it implies a race condition: different kernels finishing at different times, data not being available at times when the code assumes that it is ready. That's a synchronisation problem which it is the duty of the programmer to solve.

The 'Fix' for the lower end cards is to plug the monitor into the misbehaving card until you get a desktop, then switch the monitor back to the GPU that doesn't have the problem. How dubious is that? Since adding the two 1080Ti to the Mac neither one has had the problem, the 1070s still have the problem. So, how do you explain that? Pretty definitive proof in my book, 1080Ti no problem....1070s = problem. This machine, https://setiathome.berkeley.edu/show_host_detail.php?hostid=6796479

From a quick glance at the code and one of my state files, I suspect that you'll have to write to the state file as you go along, because it is the data in the state file that will eventually be returned as the result.

No, the final (returned) result file is written to incrementally as 'result.sah' in the slot directory. That's a soft link to the named upload file in the project directory. Obviously, it needs to be re-created from scratch if the application starts 'cold', without a state file to indicate the (partial) status of the internal counters on restart.

Edit - the 'state.sah' file starts with data like

<ncfft>94713</ncfft>
<cr>6.857660e+001</cr>
<fl>512</fl>
<prog>0.85297058</prog>
<potfreq>-1</potfreq>
<potactivity>0</potactivity>
<signal_count>15</signal_count>
<flops>0.000000</flops>
<spike_count>9</spike_count>
<autocorr_count>0</autocorr_count>
<pulse_count>4</pulse_count>
<gaussian_count>0</gaussian_count>
<triplet_count>2</triplet_count>

which does not form part of the final result. It does also contain details of the 'best so far' of the five signal types, in case there isn't anything better in the remaining portion of the run.

The 'Fix' for the lower end cards is ...

That's not a 'fix', it's a workround. It'll only become a fix when somebody demonstrates knowledge of how the observed behaviour is caused by the hardware in question, and devises some code to mitigate that observed behaviour.

Only TBar's systems seem to have made the connection between a missed pulse and a monitor connection. IIRC, TL was trying to work around a similar issue on his Mac, but couldn't fix it with the same monitor work around. Sounds more like a problem with the Mac platform honestly. The hundreds of Linux systems don't seem to be affected by this issue nearly as much, even with the majority of them running GDDR5 memory GPUs

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

I still think it's a timing problem, with the code not waiting for a result to be returned before using it.

When you plug the monitor into the card and display a desktop it changes the way the vram is being used, that's All it takes to get the card to start reporting Pulses instead of missing Pulses...a change to the vram usage.

When you plug the monitor into the card and display a desktop it changes the way the vram is being used, that's All it takes to get the card to start reporting Pulses instead of missing Pulses...a change to the vram usage.

Bo**ox.

If switching to 'display mode' changed the contents of a defined memory location, or changed the value returned when that memory location is interrogated, it would be such a fundamental design error that the whole production run would have to be recalled and scrapped.

I still think it's a timing problem, with the code not waiting for a result to be returned before using it.

very possible. some kind of idiosyncrasy with timing on the MacOS version of the app.

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours