Stephen being confused? Absolutely nothing new.
My Post was about Version zi3v, Any version of zi3v.
Only Stephen could turn such an easy to understand Post into something to be debated for half a page.

I wondered about your previous post TBar about the large number of Inconclusives you said were still occurring. I looked at your hosts, mine and a few others and didn't see any except for your Darwin system which I believe just generally has basic issues based on my bad Darwin wingmen.

So, I was confused too. See you now have updated your post to indicate that most of the past Inconclusives were caused by the Arecibo work. So I concur, update to zi3v today. Everyone will be much happier. I love my zi3v CUDA90 app.

---

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

A proud member of the OFA (Old Farts Association)

These are some of the Large number of Inconclusives I was referring to;
https://setiathome.berkeley.edu/results.php?hostid=8161267
https://setiathome.berkeley.edu/results.php?hostid=7985986
https://setiathome.berkeley.edu/results.php?hostid=8382978
etc.
Those machines are Not running zi3v. There are others...

My earlier post Today was simply an attempt to get people such as those to Update to zi3v.
Strange it would be confusing to some considering the Posts immediately above it.
What parts do you consider confusing?

Stephen being confused? Absolutely nothing new.
My Post was about Version zi3v, Any version of zi3v.
Only Stephen could turn such an easy to understand Post into something to be debated for half a page.

. . You really are a sad little puppy aren't you TBar ..

. . Oh well ...

Stephen

<shrug>

I don't have time to search for the message exchange. Probably a month at least back. The conversation was added to Jeff's usual diatribe against Petri for running an alpha app in Main and your post was about the large number of Inconclusives caused by the old zi3tb or whatever apps as in your example in today's post.

My confusion was just trying to reconcile that conversation with your post today about Arecibo tasks being the primary cause.

---

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

A proud member of the OFA (Old Farts Association)

Jeff's usual diatribe against Petri for running an alpha app in Main

Jeff?? Jeff??!! My name isn't Jeff ;)

---

Ah, you mean this part;

Since the Arecibo work has stopped it has become clear Most of the previous Inconclusive Results were resulting from the Arecibo tasks. Now with just the BLC tasks the CUDA zi3v has Very Few Inconclusive results, mostly from Bad WingPeople and a couple of Flaws in other Apps. There is still an occasional Bad Best Pulse, but much fewer than the Flaws in the other Apps, most notably the Missing Pulse with a score of exactly One that occurs with Most the Apps compiled from the AKv8 source.

The Arecibo tasks were contributing to Inconclusives in All versions of the Special App, HOWEVER, Now the zi3v version is producing Extremely Few Inconclusive results with the BLC tasks other than those mentioned above. Check My Mac results for the last 2 Days, the only Inconclusive results are from Obviously Bad WingPeople and about 3 tasks where the WingPerson had a Missing Pulse with a score of Exactly One. Basically zi3v is currently batting 1000.

The Same can Not be said for the earlier versions of the Special App. Which is why I made a rather simple Post asking People using the Older versions to Upgrade to zi3v.

Is there any question about the intent of the Post being to have people using Older versions to upgrade to zi3v?

Jeff's usual diatribe against Petri for running an alpha app in Main

Jeff?? Jeff??!! My name isn't Jeff ;)

I remember you have voiced your opinion on the special app and Linux in general. Jeff's voice has always been MUCH louder.

---

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

A proud member of the OFA (Old Farts Association)

Is there any question about the intent of the Post being to have people using Older versions to upgrade to zi3v?

No, none at all. Perfectly understood and agreed with.

---

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

A proud member of the OFA (Old Farts Association)

Is there any question about the intent of the Post being to have people using Older versions to upgrade to zi3v?

No, none at all. Perfectly understood and agreed with.

. . Indeed, I think even Jeff would agree with that :)

Stephen

:)

Hi all,

Since no one has tested the special app on Linux and Volta GPU I ordered a Titan V so I can test it myself.
It has been shipped and I expect to receive it next week. First of all I'll have to test for compatibility. Then for performance.
I'll post news as soon as possible -- after the initial set-up and test runs. Btw. Then I'll have two 1080's collecting dust on the shelf.

And it is a good thing it will arrive next week. The forthcoming weekend will be well spent installing and testing a brand new BenQ W1700 4k home theater projector.

Petri

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

Hi all,

Since no one has tested the special app on Linux and Volta GPU I ordered a Titan V so I can test it myself.
It has been shipped and I expect to receive it next week. First of all I'll have to test for compatibility. Then for performance.
I'll post news as soon as possible -- after the initial set-up and test runs. Btw. Then I'll have two 1080's collecting dust on the shelf.

And it is a good thing it will arrive next week. The forthcoming weekend will be well spent installing and testing a brand new BenQ W1700 4k home theater projector.

Petri

. . Maybe you could have an auction :) or just keep them as 1) spares or 2) the beginnings of a second rig. :)

Stephen

:)

Brought up zi3v on my Linux + 750Ti system 3 hours ago. It ran o.k. on four sample work units in the KWSN benchmark environment so I'm turning it loose on production work. I'll keep an eye out for inconclusives or any other strange behavior. "at-a-boy" to petri33 and TBar.
[Host info access is open; so take a look at system config and work results if you care to.]

Gene, which distribution are you running? I'm interested in how you got such a good benchmark score at only 3200 Mhz on a 1700. I can't figure out why my 1700X and 1800X benchmark so much lower at much higher clocks.

I am wondering if the kernel and distribution differences are solely to blame for my low scores.

---

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

A proud member of the OFA (Old Farts Association)

Brought up zi3v on my Linux + 750Ti system 3 hours ago. It ran o.k. on four sample work units in the KWSN benchmark environment so I'm turning it loose on production work. I'll keep an eye out for inconclusives or any other strange behavior. "at-a-boy" to petri33 and TBar.
[Host info access is open; so take a look at system config and work results if you care to.]

. . You should not have any problems, zi3v works pretty well on all the rigs of people I chat with.

Stephen

. .

As well as zi3v works, the newer zi3xs3 seems to work slightly better on the Pascal cards. The only problem with zi3xs3 is it fails on a few of the Instant Overflows that are Aborted within 10 seconds. Why we are bothering to analyze the first 30 signals in a WU that probably has Thousands, or more, is a mystery. The only thing you are checking is that the Apps were looking at the same parts of the WU when Aborted. If allowed to continue on the WU zi3xs3 would most assuredly find the correct singles as it does with the non-Aborted tasks. Short version, the Special App does not work well when Aborted or Suspended. You should set your Checkpoint to a number higher than the longest estimated GPU run-time so the App runs from beginning to end without being restarted partially completed. Other than that, it seems to work rather well on the BLC tasks and it Does report Pulses with a Score of Exactly One, unlike most of the Apps around here.

@Keith
The Linux distribution is Debian 9.3 although I have installed the "testing" kernel 4.12.12. It's an AsRock ABM350M motherboard, with DDR4 2667 Mhz (2x8GB) not OC'd. A couple of things I discovered in bringing the Ryzen onboard last year: (1) the Ryzen 1700, out of the box, is clocked at 3.0 Ghz, and as you have noted, I OC it to 3.2 Ghz. Not a very significant boost but the best my system (air) cooling could tolerate with all 8 cores going full blast. (gets up to 70C) If I remember correctly, setting the MB BIOS to a custom clock was necessary for the Linux kernel to allow OS clock speed control, otherwise Linux sticks with the bios setting. The kernel was compiled with several CPU_FREQ_GOV flags set for "on demand" and "performance" modes. If you're using a distribution kernel image they are -probably- setup so that the kernel will have control of the cpu clock. In Linux, do an "apropos cpufreq" for more info. (2) I have disabled SMT (multi-threading) on the "theory" that additional threads will contribute to cache misses enough to offset the gain from the extra thead processes. A debatable and unproven decision. (3) P-States are all disabled in the bios, except for P0. Ryzen architecture apparently likes to throttle down the clock speed whenever a core is momentarily idle (perhaps waiting for a cache fill) and then takes some time (many microseconds!) to ramp back up. To defeat this "feature" (which makes sense for reducing power draw) one has to disable the other lower speed/power P-states. The down side is that the cores run at 3.2 Ghz all the time, even when in a wait state.
There are probably other nitty details, especially in the BIOS settings, that I haven't thought of. But take this as an overview answer to your question.

---

Thanks very much for the detailed reply, Gene. So you are compiling your own kernel and get to use better cpu compilation flags. I am just using what the distribution sends me. I'll have to investigate that keyword you mentioned.

I had expected to see much better benchmark numbers based on my observation of other Linux systems. Seems on average they were always noticeably better than comparable hardware Windows systems. So when I got a much lower benchmark number on the 1800X compared to the Windows 1700X, I was baffled.

I just run both systems flat out all the time since they are dedicated crunchers. I have never messed with P-States which seems to be a major thing in the Ryzen forum threads. The 1800X runs at 3950Mhz and the 1700X runs at 3925Mhz. Both systems are running 3333Mhz CL14 memory at fast timings. I use all the threads but force cpu and gpu task with affinity to the appropriate processing locations.

Wonder what changes the Ubuntu 18.04 LTS kernel will bring to the table in a few months. I wonder if the kernel will be better at maths?

---

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

A proud member of the OFA (Old Farts Association)

@Keith
...more... After your question, re: boinc manager benchmark score, I looked again at my "reported" integer speed of 82+ Gips. Something is odd there. It is reported as "speed per core" but it seems to me unrealistically high - i.e. it implies >25 instructions per clock. Yeah, I know AMD took great pains to increase the IPC performance of Ryzen but it still stretches one's credulity. Maybe a bug in boinc manager's calculation? Didn't properly account for 8 cores? Didn't get the right time interval from the kernel? Farther down my speculation list, along the lines of optimizing compilers completely skipping chunks of code in benchmarks because the results are never used (merely loops to burn instruction cycles), is the possibility that Ryzen instruction "look ahead" skips instructions in a similar manner. Just thinking out loud with no factual basis... If it's a Ryzen thing it should show up in the details of other Ryzen hosts. I haven't found others, except yours, so for the moment I'm not putting much faith in that reported value.
Ahh, but I stray from the thread topic. So I'll leave it there.

---

Hey Gene, yes I don't want to hijack the thread. Pretty easy to find Ryzens and Threadrippers, just look in the Top 20-40 Hosts list. In general I see benchmarks falling around 15-16 billion ops/sec for Ryzens in Linux and around 16-18 billion ops/sec in Windows. That seems to hold true for Threadrippers. Haven't found many TR's on Linux though.

So your benchmark scores are definitely an outlier. But what raised my question and interest is that there are quite a few Intel hosts on older Linux distributions that score in the 32- 45 billion ops/sec range. I always figured that was the normal benchmark bias toward Intel architecture. So when your Ryzen popped up with out of the park scores, I wanted to know what secret recipe you were using.

---

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

A proud member of the OFA (Old Farts Association)