Enable the option noted here.

Once you have hit the limit of the existing hub's power (which you may be getting close), you can also try turning the pot down.

Counter intuitively, turn the pot back to 3 o'clock.  
Look like you can squeeze out another 15% in energy reduction if you are at or under 500MHz.

You might lose some stability with more HW errors, but still keep the expected overall higher hashrate.

Be prepared to set it back towards default if your hashrate looks off or when you get the shiny new gekkoscience hub.

If you get around to more tweaking, watch your cable quality/length and various adapters along the way.

voltage loss = (current x resistance)

It can subtly create a current limit like scenario and drop voltage.

5V may end up being 4V when it arrives at a miner trying to use 2Amp+.
This can also cause the effect you are seeing.

A 2pac table but still relevant for the NewPac at higher frequencies:



Higher frequency will amplify resistance based voltage loss.

Thanks for the feedback.   I found a possible cause and pushed up a fix to GitHub (3339a51).

Feel free to settle into a particular build if you have a working setup that you no longer want to tweak.

Frequent updates may start to feel overwhelming.    As always, the feedback is appreciated and makes for a better next build.

edit
Windows build: cgminer-4.11.1-windows-gekko-3339a51.7z

link references to the previous build has been updated.

Assuming that was the end of this issue.

I matched the sleep time in one of the threads to be similar to that of the build you pointed out as allowing the faster speeds.
Why it is fine on linux but appears to have an impact some windows machine with usb3, I haven't made that connection yet.    
Since I found a machine I can recreate it on, I'm making a note to revisit it someday to understand it more.

New build (7a48c8f)

Same instructions:
    rename (save), clone, build.
    
Add new testing parameter --gekko-serial
    Accepts double quoted, comma seperated list of Serial Numbers to target.
    Available for all gekko miner types.   Especially the 2pac type.
    --gekko-serial "GS-10001010,GS-10001011"

Remove excess noise from default display.
    - Individual device HW errors can be found by pressing d, i, then [space].
    - Move ramping notes to LOG_INFO during restarts.  

Misc Tuning & Fixes
    - Additional thread priorities and timing adjustments.
        - Solves some windows + usb 3.0 combo capping miners at 65GHs
        - Free up some cpu cycles where possible.
    - Fix errors cause by lost precision on fractional frequency steps.


Windows binary: cgminer-4.11.1-windows-gekko-7a48c8f.7z

Windows binary: cgminer-4.11.1-windows-gekko-60d9f64.7z

Windows binary: cgminer-4.11.1-windows-gekko-3339a51.7z
    sha1sum 4c2b86473f1b7ae51ffa0aa415bbd916b3e62954 cgminer.exe

edit:
Looks like that frequency fix didn't make it in on this build.  
Use frequency steps/multiples of 25 for better results until the next build.

edit:
That was important enough to squeeze in.

edit:
Fix for segfault

That's good news that the sticks aren't limiting that upper bound.  
Let me see if I can find a machine that behaves the same to take a closer look.  


Before you do the reinstall, try getting your resolution up so that your terminal can fit about 120 columns, 75 rows.
It looked a little cramped from your earlier screenshot.

Here are the usual troubleshooting swap-able parts that will typically pick up an anomaly:  

• Using a different hub or no hub.
• Using a different usb port.
• Using a different PC.
• Using a different build of cgminer.
• Using a lower frequency.
• Using a different vcore.

strike-thru-ing the ones you've mentioned you've tried or are not relevant.

Stray troublemakers (better to avoid using)

• Extension cables
• USB 3.0
• Other devices on USB bus
• Windows

I think most of this is in the first post, but a few are not so I'll cross reference and update it a moment.

Return the stick to it's factory vcore to ease power draw at high frequency.  



Test them one at a time to see if you can push past 55GHs.

Start at 300MHz, unless you get 68GHs (0.228 x 300) don't go higher .

Try with and without the hub - single stick.  

I find my dell's usb port does pretty well with a single stick, fan, no powered hub.

Once you get 68GHs, bump the freq up by no more than 25-50MHz at a time, test for 24hrs...

One at a time first and you should be able to find where the bottleneck is.

I don't recall explicitly adjusting anything related to hardware error percentages.
Try attaching a screen shot of what you notice was omitted in this build.

Not much has changed recently on the display side.

Jan 2017 (about two years ago)



Dec 2018 (this build)



If you are comparing pre 4.10, I wouldn't be able to answer.  

There would probably be some notes in GitHub.

Tweaking the voltage should be done with some measuring tools available to properly undo.

The stock value should provide the chips enough voltage to handle up to 600MHz.

The plugable are noted to provide 1.5A per port or 7.5W.
7.5W can get you in the range of 275MHz without asicboost.

Pulling more power than the hub can provide will be one cause of the symptom you are seeing.

Adjusting the pot/vcore higher will increase amp/watt usage, effectively lowering your max achievable MHz instead.

Sounds like the text UI library is not installed by default in Ubuntu 18.


clone and build again afterwards.

I'll update the first post accordingly.

---

Yes, linux only.
Windows support has recently been discontinued upstream.   
I'll continue to post a link to the binary so long as it's still build-able.

A new build is available (9d66fd3):

Windows binary: cgminer-4.11.1-windows-gekko-9d66fd3.7z

  - Fixed datetime display.

  - Closed gaps in data transmission to reduce line power fluxations.
    - Spin off dedicated work tx thread.
    - Switch from blocking get_work to get_queued.
    - Send null work to keep asic busy during network glitches and when pool is reacting to block events.

Reminder best practice update process: keep old working (or favorite) build readily available.

• move the existing "cgminer" folder to "cgminer.yyyymmdd"
• clone repository to create a new cgminer folder as noted from first post instructions.

Copy and paste back what you get from running this code block:

darn,  i was hoping it would be a simple one.

retried but my basic check seems fine:

• Single NewPac - Windows 7, direct usb no hub
• wiped and downloaded latested windows build
• open up single_test_mining.bat, changed pool.ckpool.org to solo.ckpool.org, added --gekko-newpac-boost
• started up bat, no unusual errors, hashrate as expected.  checked in --verbose and still seems normal

-- edit --

note:

if you are running your own build steps and reusing directories, make sure to run the associated autogen / autoreconf + configure steps.  
there are some flags in configure.ac that needs to be picked up that will be missed with just a pull & make.
^ this may cause invalid work to be generated.

Post the pool name.

I’m going to take an initial assumption and start with bravo-mining.com does not support Asicboost.

Yes, that is correct.

Somewhere in the approximate neighborhood of 5X the total hash rate in Gh/s is a good place to be at.

New build (90e7d31).  

Some minor updates (medium-to-major if it affects you)

Windows binary: cgminer-4.11.1-windows-gekko-90e7d31.7z

- Merged in some needed changes for macOS build.
- Found and fix a cgminer crash condition when receiving noise from the asic.
- Lowered no nonce detection sensitivity.

Best practice update process: keep old working version handy.

• move the existing "cgminer" folder to "cgminer.yyyymmdd"
• clone repository to create a new cgminer folder as noted from first post instructions.

I suspect the 2Pac is also bringing up the average quite a bit.