Topic: GekkoScience NewPac / Terminus R606 (BM1387) Official Support Thread - page 86. (Read 61906 times)

Thanks @vh.  I'll keep you updated and I am running the current 5/11 build.

---

@vh   Ok tried with logging and this time didn't even last an hour.  Below is the log.  It just gives the message that shutdown signal had been received.   However I never gave it any commands to end.  I remote into this box and had dropped my connection since I fired it back up.  About 20 minutes later it ended.

@WilcoWi

The miner has an upper frequency boundary for performance, that message is the code is trying re-target to it. The highest detected/computed of 3 attempts (1/3, 2/3, 3/3) is set as the new frequency.

It's information data at the moment, unless it unusually low.

---

@mstrozier

on linux append " 2> out.001.log" to the end of the command line run string.

Exiting to summary was reported before but I haven't been able to properly reproduce it. That normally only triggers when a special stop signal from the keyboard or another process activate. If you set this environment up before the 5/11 update, grab and build the latest code.

https://ibb.co/jW8Ss7R  <---  each newpac getting about 72Gh/s on average.

And here is a screen shot of the R606 now that I have it up and running on the other box.  I have this running on volt setting 5 at 700Mhz.  I had it clocked at 750 however as I'm posting this it finally autotuned itself to 700/700/698 running at 96%.  Don't think it'll reduce any lower.   I noticed at 750Mhz at volt setting 6 it would crash cgminer.  It hit up to 1.1Th/s before it ended.  I haven't tried volt setting 7.  It might would have held at that point.    I'm happy at this stage, a world difference than what I was getting before:

https://ibb.co/TLcZhn3 <--- R606 with AB enabled on the Ubuntu box.

** Edit **

@vh   is there a way to have cgminer output to a log file?  From the above post, on volt setting 5 and freq at 700, it ran for 1 hour 45 minutes before ending to a summary of stats and back at a command line.  Not sure if it's a voltage issue?  Where I'm not supplying enough so should bump it up.  Or if it's something entirely different.  As it doesn't give me any error messages to go by.  I've now bumped it down to 675 and trying again.  Dropping by 25Mhz each time I get the crash.

thx VH, using new version of cgminer for my newpac's now.

btw saw this today:


is that a new thing you build in? never saw it b4. what does 2/3 mean?

and now this:


these messages are new to me.

edit 14th may 2019: thx for explaning. must say this version is getting much more out of the newpac's, about 80 Gh higher on avarage in 24h. I also see the autotune has been changing the target frequency much up. Good job.

@rockmoney Thanks, I'm just glad to be mining again, if I can help...I will.

@sidehack I appreciate you leaving it up to me. As I said, there is no discernible difference between the functionality of the four units aside from the blinking lights. I targeted 600Mhz and they've all settled right around 565Mhz +/- 2hz with voltage setting 5 (440mv). KanoPool is showing me with a share rate of 3.37TH/s and a hash rate of 3.03TH/s. So, as far as I'm concerned, these units are working exactly as advertised. That said, it would be nice if the high temp warning indicators were fully functional. I'd be more than happy to ship the units back especially if it would help you out in any way moving forward. Just PM me with directions if you want to take a look at them.

my 1 unit on a robust pc (amd ryzen 2700)  works very well volt setting is 6  freq is 750  which settled at 737.5 and hash is pushing 1th

uses a spare pci cable from the psu that powers the  pc.  the psu is a hi end evga plat IIRC

Kingofhammers, I may have you send me one or both of those miners for some testing and repair or replacement. Temperature detection and blinking the LEDs was the last thing put into the firmware so error handling is less robust. I can probably fix the temp sensors to start reporting properly, and maybe use one as a testbench for removing the blink if the temp sensor reports an error condition; right now it can't tell the 0xFF of a disconnected/unresponsive sensor from a reported temperature of 255°C.

But if you don't mind the blinking, and they're still mining as expected, I'll leave that up to you.

@kingofhammers - Especially because of your background and knowledge, I would definitely wait to hear from sidehack, and get his input. He should be on in the morning, and be able to provide the info you're asking for.

Also, thanks for your willingness to work together with this great community in order to determine if there's actually a problem or not. Unfortunately, you guys are out of my league on this one, but please let me know if there's anything I can do to help!  

After more testing I wanted to post up and update to this.  Apparently the Raspberry Pi 3 B+ is my weak link in this chain.  It'll run the R606 however getting the 'stock' or higher speeds just wouldn't happen.  The Raspberry Pi 3 B+ has a quad-core ARM A53 CPU producing 1.4Ghz and carries 1GB of LPDDR2 RAM.  Granted this is a great tool for such a small SBC (small board computer), however for my application it just isn't working.

When I run the r606 on the Pi for non-AB supported pools, no matter what volt setting I use, it'll never go over 481Mhz.

I then found a Litecoin Cash pool that supported AB.  I finally broke past the 481 mark but not by much.  After 12 hours of running, it settled at 518Mhz.  Tested then on multiple volt settings with the freq set to 700 then in 4 hour increments.  Same results would slowly drop down and then remain steady at 518Mhz with AB enabled.

At this point I wondered if it was limited to these LCC pools I was using.  So I set my miner to point to solo ckpool and solo mine Bitcoin.  6 hours on this run, and leveled off at 512Mhz on this one.

On each test, there were many ASIC Plateau errors and Missing Nonces from chip 0, 7, 9 and 1 throughout all of my testing on the Raspberry Pi.

Today I changed my hardware around.  I moved my Gekko newpac's and Futurebit Moonlanders over to the Raspberry Pi.   And I moved the R606 over to my Ubuntu Linux Box.   This is now the only device attached to this box and it's specs is a AMD  FX-6300 with 16GB DDR3 RAM with 1TB of storage.  Originally was a FX-8350 however I really didn't need the power draw from the 8 core processor so swapped it out with the 6300.

And so far on this machine, I have had 0 Asic Platues and 0 Nonce errors.   I am still waiting for it to level off on the non-AB supported pool.  So later this week I will come back to this post and update it my tests on this Linux box on various pools.

All in all, very happy with my purchase....and while shopping on Amazon today for some electronic parts (needed some resistors / caps) the r606 showed up in my suggested items....so bought another one

Yep and for 15 bucks meter cost you have extra confirmation that the gear is good.

Since the gear is 1200 cost the meter is worth it.

You know if btc keeps going up I may not solo mine this gear.

I could break even if btc goes higher.

I've updated cgminer to the most current version, thank you for that @vh


The temps do seem fine.


I tested the temperatures on them by pointing the laser at the heat sink through the access area where all the connections are made. I did this on each individual unit.

The leds blink before I even connect the units to the pi that I'm using as a controller. I've cycled power on the units several times. I could disconnect them and reconnect them one at a time but I don't see the point in doing that, given their behavior. Without a great depth of knowledge on the design and which components are all tied to the I²C bus, I am very hesitant to go in and touch anything for anything but testing purposes, which at this point doesn't seem necessary as the voltage adjustments appear to be functioning correctly. I am able to destabilize the units and crash them by lowering voltages.

I'll keep an eye on the temps but I don't think there is anything that is actually wrong. If it becomes an issue I may go in and probe around the areas that were named earlier.

@sidehack said it before and I agree, at this point its purely academic, given that the units are performing as expected.

So looks like your temps are good. Must be the heat sensors.

Assuming you tested each one by itself. And the blinkers blink when stand alone one unit at a time.

Thank you vh! I just switched all of my R606 miners to this latest version. First, those stray characters have disappeared now, which is good. Will let you know if I experience any problems, but all has been good so far! Thanks again!

This is correct.

My temperature sensor comes came in today, so I'll check for temps and update later. All four topside heat sinks are showing ~26^oC. I'll also update the cgminer to the most recent version and see if that changes anything.

Here's my current cgminer screen:

https://imgur.com/a/pZpetQg

Everything seems fine.

Thank you, will be moving to Kano pool, changing power supplies and will change the controller to a pi perhaps.

Morning all.  And just confirming sidehack mining on a pool without ASICBoost enabled.  I pointed the R606 back at Magnificent Pool which does not support AB. After running for 14 hours now it settled on (on volt setting 3) at 481Mhz and hashing at 625Gh.s for an average.

Screen shot: https://ibb.co/92Nv1x1

Maybe if I bumped the voltage settings a bit more I could level out at 500 - 550Mhz however I'm pretty happy where it's at.

New build (ef74c27)

Instructions for linux:
    rename old (save), clone again, build.

Windows binary: cgminer-4.11.1-windows-gekko-ef74c27.7z
    
Fixed statline overflow.
    + display shows garbage string in windows when driver appended info exceeds 64 bytes.
    + possible trigger for core dump.
    + possible cause of "shutdown signal received" via feedback through ncurses.

Suspended periodic frequency checks.
    + use case does not apply anymore.  free up some traffic on the bus.

Step down BM1384 frequency on shutdown.
    + part of december code lost in r606.

The blinkly lights has nothing to do with power or communication. It's an issue with the temp sensor, which is connected to the onboard microcontroller, which is not affected by voltage or USB anything.
Just to be double-clear, the white light is flashing while hashing on all of them, but on two of them the red volt-setting LEDs are blinking?

Without ASICBoost, the theoretical peak speed is about 575MHz (~800GH) on a wide-open USB bus. If the bus is shared out with something else and/or the processor is slow and timings aren't perfect, it'll be less than that. See the guy above whose pod, without AB, only saw about 500MHz. This is a USB limitation completely independent of core voltage setting. You may need to get a system working with AB, or plug into a more powerful controller, to get stock speed.

Have you tried running only 2 or 3 units at once to isolate a potential power insufficiency (or possible limitation of pi), and/or data/throughput jam?

Sounds like a lack of power or communication jam, especially when using AsicBoost. I would try running the two units with the flashing lights by themselves, and see if that helps.

Not very familiar with raspberry pi, but ~400 Watts+ seems like a big ask?

---

Move it up to 7!  

---

@kano - I currently have four R606 miners on your pool, all with R606 in their worker names. My newest one is averaging 1.10Th/s on the pool if you want to grab some stats. I'm back in PA now btw, and two additional R606 miners will be online soon!

Added the --gekko-noboost setting for btc.viabtc.com and it seems to be working. no crashes so far after 20 minutes.

I set the target freq of the R606 as 600. It has run over an hour and changed the target to 368 and then 15 minutes later changed again down to 362 which result in about 460gh. I have the R606 set to 450mv (setting 6) should I move it up to 7 or down to another setting to reach stock 750gh.