cgminer probably can't claim the device.  
 
try disabling any possibly active vcp modem drivers.  

find them with:


unload the driver to keep it from interfering.


or


change from kextunload to kextload if you want them back.

@goldsounds

"If i just do one it runs fine, the best at 350mhz (about 65gh/s) any other speed resets and no nonce errors"

see diagram.

You've ran out of power past 350mhz.  
Changing software and software settings is not going to fix it.

Adding more miners to the current setup and seeing it behave worse is yet another sign you're having power contention issues.

Try to replace your power source.

The good news is that the miners are okay if they work by themselves.

You're good.   No need to adjust the miner itself.

I have enough from your description to make improvements.
I'll move the software towards a balance between the working build and the R606 line.

Use "--gekko-noboost" for the time being, or the older build.

Would be awesome if you can circle back on the next build and confirm the issue is no more.

@Kano

Over in the r606 branch.

@gt_addict

Got one of my test system set up to mimic your test.

Device : Dell Optiplex
OS     : Microsoft Windows 10 Pro - Version 1809 (OS Build 17763.404)
Miners : NewPac x 4
Hub    : GekkoScience
Code   : cgminer-4.11.1-windows-gekko-363d879.7z

I was able to get hashing to get stuck at 60%, on one occasion while connected to eu1, but i didn't have enough logging to see anything useful.

Now I can't seem to trigger it again.   Working as expected every run since then.
The pool handles AB correctly from all angles I can tell on Windows & Linux.  

10 hour run:


I have a todo item to loosen up the no nonce check.  
It was intended to be overly sensitive, but may be backfiring on windows.

edit:

@all
A running tally of the pools and its asic-boost condition is at the bottom of This initial post.
The top "okay" section are pools that I've confirmed to accept work and nonces from the extra ab midstate(s).

If you spot something different, using a different combination or set of settings + pools + local environment.
Post as much detail to replicate as you can and I'll continue to recheck/investigate.

That's some mighty fine sleuthing there.  

If you have a user.worker you can PM me, I'll take a closer look at bitminter.

Most pool post a hashrate and luck value.   WU would be the luck component.
Hash% WU:Luck%

the "o" and "-" was just a quick way to tag which chip the no nonce is associated with.
it's there temporarily to help with the R606.

edit:
My explanation on WU was a little too generically put.
From the README:

You'll need to set a target frequency.

Based on what you described there, you'd want to have "--gekko-newpac-freq 600" in your file.

98% on both sticks not dropping below 100MHz is the expected behaviour as you have it now.

@Gage-Miner

(Re) Read the first post.

How far did you get in the build process?

@gt_addict

If you just launch the test file as is, the target frequency will set to 100MHz.  

200MHz is the chip's built in frequency when a reset is applied, so it will flash that value temporarily.

In normal cases it will start there and move up to the target.

Something seem off in the windows build.   The "no nonces" seems likely to be the underlying culprit.

The missing nonces could be software timing or hardware events hidden in the previous build.   This build is very sensitive to that.

Same todos items on the hardware side to check hardware interaction.
    Do you still get no nonces with just one miner on the hub?
    Try a different port to get onto usb2 if possible.

I'll switch to windows 10 this evening to check if it's repeatable and approach it from the software side.

Auto anything is usually too generic to accommodate every case.  
A little hesitant to pursue it much but it looked very promising while locally testing.
When the build finalizes for the R606 release, it may or may not be still there.

Anyways, It waits a little bit to check quality before moving up in frequency.

On my test area:
10 minutes to settle in at 200MHz, no adjustments, all ports are minimum 2A.
45 minutes when I targeted 700MHz to pass peak, then another 30 minutes to return to peak.

Setup 1:
Device : Dell Optiplex
OS     : Ubuntu 16.04
Miners : NewPac x 3, Compac x 3, 2Pac x 3
Hub    : Sipolar 30, + 1 Y Cable.

Setup 2:
Device : Pi3
OS     : Rasbian - Latest
Miners : NewPac(s)
Hub    : GekkoScience Hub.

Reset is normal, but reporting 0 chips I wasn't expecting either.

Along the same questioning as sidehack mentioned, can you include your more detail on your current setup, so I can reconfigure my test area to look similar?

Yes, "Dec 13, 2018 @ 3339a51" is the latest version (for the NewPac).

While we're on the topic:

Here's info on an updated version of the cgminer gekko driver (363d879, branch: r606), prepping for the Terminus R606.

Opening to early adopters.   Neat new options, with lots of bugs pre-squashed, (but probably not fully bug free).

To install:


Windows Binary: edit
April 8  @ 363d879 : cgminer-4.11.1-windows-gekko-363d879.7z
April 26 @ 5c757f5 : cgminer-4.11.1-windows-gekko-5c757f5.7z
April 30 @ 0d524aa - cgminer-4.11.1-windows-gekko-0d524aa.7z
May 11 @ ef74c27- cgminer-4.11.1-windows-gekko-ef74c27.7z
May 13 @ a62385f- cgminer-4.11.1-windows-gekko-a62385f.7z
May 26 @ 9e51f0b- cgminer-4.11.1-windows-gekko-9e51f0b.7z


Changes:

- Merged in upstream cgminer.

- Added initial support for Terminus R606

- Added self preservation / performance tuning code:  

  leverages the standard stages of hash performance as frequency increase:

  | normal | peak | pleateau (80-90% peak - stress or "no nonces") | no hashing |

  this code update will step back from pleateau into peak.

    + okay to slightly over estimate frequency, it will back down to best healthy hashrate.
    + 5-10% increase in hashrate as you return to peak
    + adjust with "--gekko-tune-down" to suit your needs.   [90-95]% is a healthy range, 95 is default, set to 0 to disable.

    
    
        1.  Adjusts frequency according to each miner's unique charateristics
        2.  To keep a hash performance above 95%.  
        3.  Based on the idea that (95% of 275MHz) hashes better than (80% of 300MHz)
    
- Modified asic-boost pool startup sequence.

  + cleared issue sending AB stratum message on non AB pools.  
  + if pool indicates AB is supported, AB will be enabled.
  + removed option "--gekko-newpac-boost", use "--gekko-noboost" to force non AB mode.
  + added [plus] flag after chip count to indicate asic-boost is functioning.

@0d524aa
  + tune rx buffer handling.
  + drop vmask param when noboost is enabled.   better support for non compatible vmask implementation (prohashing.com)

@ef74c27
  + fix statline overflow

@a62385f
  + works with all tested AB pools below
  + added lowboost mode

@9e51f0b
  + performance improvements
  + bug fixes

---

Asic Boost Pool notes:

okay - auto detected - Asic Boost Pool(s):

    stratum+tcp://solo.ckpool.org:3333
    stratum+tcp://stratum.kano.is:3333
    stratum+tcp://pool.ckpool.org:3333
    stratum+tcp://btc.viabtc.com:3333
    stratum+tcp://us1.bitminter.com:3333
    stratum+tcp://stratum.slushpool.com:3333
    stratum+tcp://us.ss.btc.com:1800
    stratum+tcp://prohashing.com:3335
    
okay - auto detect - Non Asic Boost Pool(s):

    stratum+tcp://mmpool.org:3333
    
not okay - detected but rejected ab work:  (use "--gekko-noboost")

     N/A

Try setting them at 175MHz.    You might get another 10-25GH/s if you set it between 160MHz - 175MHz.

edit:

Drawing out a rough sketch to explain.

In the normal range, Hashrate = Frequency x 0.228  



If the formula doesn't work, there's not enough power to move forward with a higher frequency.

Unplug the miner and let it rest for an hour without power.

Confirm the potentiometer is at its default location.

https://bitcointalk.org/index.php?topic=5053833.msg48600421#msg48600421

The chips may respond once cooled, if they haven’t fully overheated.

+1

Even on that nice hub, keep in mind the power output will still be constrained by the power input and the shared regulators.

While the "All" option is still available near the site's page navigation, click it and search for "serial".

voltage setting (potentiometer) and available power (hub) has an affect to the max stable MHz.

As gt_addict mentioned, its effect varies per stick.

If you want to test voltage tuning, focus in on one stick (without anything else drawing power) and adjust 1-2 degrees at time.
Try to stay within a few degrees of its original setting.

Each time you move clockwise that it consumes more power and runs hotter, even at lower frequencies.

If unchecked, this can quickly lead to heat based damage so keep it as low as you can, or don't change it at all.

In case the original comment didn't register.

Leave them at stock, you'll end up destroying the stick otherwise.

Potentiometer @ 3 o'clock can run up to 500MHz.
The default is at about 4-5 o'clock.   You can run up to 600MHz+ there.   Don't change it.

Again, It is highly recommended you don't change the default voltage.

At 4.3GH/s, a 1 diff nonce should appear every second on average.
Scaled to your speed, if enough time passes where 20 of those appear consecutively missing from the asic, a "missing nonces" message will appear.
At that point, the software applies a quick reset on the chip to clear out any lingering issues in an attempt to revive it.
It's essentially the ZOMBIE clearing mechanism kicking in, an additional improvement over the 2Pac.

An occasional one of those at higher frequency could probably be overlooked, if all else looks normal.

If you run multiple instances of cgminer, you can target each instance to specific miners with the gekko-serial option.
https://bitcointalk.org/index.php?topic=5053833.msg48649259#msg48649259

@ElbaInvest
Go to the first post and scroll down to the OSX section.

@Cipto1758
Add an externally powered hub to your setup.  
OSX might also disable the device if it notices it's drawing an unusual amount of power.

run the test_mining.bat file that is included in the directory.

if it doesn't start mining, reread the first post for possible missed steps and then post the error here.

if it starts mining, make a copy of it and adjust it a little at a time until it does what you need.

if there is a problem while changing it, reset to the original file to find what causes it to stop running.

Typically pools won't have stats for your miner unless you send a share that is accepted.
The pool's default diff is 1M.   Waiting for that 1M share makes it look like you're not mining.

See if you can set it pool side by worker.   The notes I saw say they honor suggested diff.

Probably possible to do:


Look for the VALUE at the top of cgminer where it says "Connected to pool mmpool.org diff VALUE with stratum..."

Frequency is capped at 500MHz in the code. 
I've only ever reached 325MHz due to heat concerns.
https://bitcointalk.org/index.php?topic=1845307.msg18647593#msg18647593

Success case running @ 350MHz
https://bitcointalk.org/index.php?topic=1764803.msg29114535#msg29114535

A rare attempt at 400Mhz.
https://bitcointalk.org/index.php?topic=1764803.msg26468690#msg26468690

Sounds like the execute permission of files in the folder were lost during transit.
The permission mask was likely lost in a directory copy; or the local git configuration is broken.   Remove the folder completely and proceed from the git clone line again.