BITMAIN AntRouter R1: 1st wireless networking device with bitcoin mining chip

[aarons6]

Still getting some resets with 1 U3.  But less than 3 U3's.   So odd that it does seem to reset.

The interesting thing is there still appears to be not near as many of these online from antrouter page as I thought there would considering they sold out:
During the last 100 days in 126 valid miners.

your resets are probably due to high difficulty and timing out.
set the cgminer-monitor to run every 5 minutes instead of 3.

also i bet a good amount are on different pools..

[notlist3d]

Still getting some resets with 1 U3.  But less than 3 U3's.   So odd that it does seem to reset.

The interesting thing is there still appears to be not near as many of these online from antrouter page as I thought there would considering they sold out:
During the last 100 days in 126 valid miners.

your resets are probably due to high difficulty and timing out.
set the cgminer-monitor to run every 5 minutes instead of 3.

also i bet a good amount are on different pools..

Thanks for advice I am giving it a try and see what happens I will report back.   Maybe i will try a different pool with U3 was trying Kano for fun.  Anyone have any favorite to point miners with low power at?

And you could be right.  I wanted to give mine on default for a bit for fun, but I could see many switching to CK's solo.

[aarons6]

Still getting some resets with 1 U3.  But less than 3 U3's.   So odd that it does seem to reset.

The interesting thing is there still appears to be not near as many of these online from antrouter page as I thought there would considering they sold out:
During the last 100 days in 126 valid miners.

your resets are probably due to high difficulty and timing out.
set the cgminer-monitor to run every 5 minutes instead of 3.

also i bet a good amount are on different pools..

Thanks for advice I am giving it a try and see what happens I will report back.   Maybe i will try a different pool with U3 was trying Kano for fun.  Anyone have any favorite to point miners with low power at?

And you could be right.  I wanted to give mine on default for a bit for fun, but I could see many switching to CK's solo.

i use cksolo with nhsolo as backup.. just make sure to add the --suggest-diff 16 to the params and put -p diff_16 for nh pool.

is it just the u3 that gets reset or the whole thing?

in the monitor script the u3 only has 1 option and thats if you lose internet it shuts down. case e.. unfortunately you have to modify that script to make it tell you why.. its easy tho if you know what you are doing i can show you.

[notlist3d]

Still getting some resets with 1 U3.  But less than 3 U3's.   So odd that it does seem to reset.

The interesting thing is there still appears to be not near as many of these online from antrouter page as I thought there would considering they sold out:
During the last 100 days in 126 valid miners.

your resets are probably due to high difficulty and timing out.
set the cgminer-monitor to run every 5 minutes instead of 3.

also i bet a good amount are on different pools..

Thanks for advice I am giving it a try and see what happens I will report back.   Maybe i will try a different pool with U3 was trying Kano for fun.  Anyone have any favorite to point miners with low power at?

And you could be right.  I wanted to give mine on default for a bit for fun, but I could see many switching to CK's solo.

i use cksolo with nhsolo as backup.. just make sure to add the --suggest-diff 16 to the params and put -p diff_16 for nh pool.

is it just the u3 that gets reset or the whole thing?

in the monitor script the u3 only has 1 option and thats if you lose internet it shuts down. case e.. unfortunately you have to modify that script to make it tell you why.. its easy tho if you know what you are doing i can show you.

It is the entire antrouter that get's restarted.  it will start back at 0 uptime. 

And thanks I appreciate I might hit you up on it.  I took it to 5 minutes from 3 on the scheduled task.   I'm hoping that will make a difference.

[aarons6]

Still getting some resets with 1 U3.  But less than 3 U3's.   So odd that it does seem to reset.

The interesting thing is there still appears to be not near as many of these online from antrouter page as I thought there would considering they sold out:
During the last 100 days in 126 valid miners.

your resets are probably due to high difficulty and timing out.
set the cgminer-monitor to run every 5 minutes instead of 3.

also i bet a good amount are on different pools..

Thanks for advice I am giving it a try and see what happens I will report back.   Maybe i will try a different pool with U3 was trying Kano for fun.  Anyone have any favorite to point miners with low power at?

And you could be right.  I wanted to give mine on default for a bit for fun, but I could see many switching to CK's solo.

i use cksolo with nhsolo as backup.. just make sure to add the --suggest-diff 16 to the params and put -p diff_16 for nh pool.

is it just the u3 that gets reset or the whole thing?

in the monitor script the u3 only has 1 option and thats if you lose internet it shuts down. case e.. unfortunately you have to modify that script to make it tell you why.. its easy tho if you know what you are doing i can show you.

It is the entire antrouter that get's restarted.  it will start back at 0 uptime. 

And thanks I appreciate I might hit you up on it.  I took it to 5 minutes from 3 on the scheduled task.   I'm hoping that will make a difference.

0 uptime on the miner tab or 0 on the status overview tab?

there is nothing in the script or anywhere i know of that will reboot the whole thing..

[RichBC]

Thanks to aarons6 for the irc chat am now trying a few things.

I have actually reduced the Monitor time from 3 Mins to 1 Min so that I don't heave to wait so long for things to get going again, this does cause it to cut in when you first go to a pool but I can live with that. I think that the higher the clock the more stops I get? I have modified the Monitor script replacing echo with logger as then the reason for the stop can be seen in the System Log.

Looking back at it mine are mostly Case B although I have had a Case D.

Have added the --suggest-diff 16 and changed --queue 10 to --queue 1

However I am still getting stops, but am running at 375Mhz, so will slow things down a bit.

I have been running recently on NiceHash as I find the graph useful. NH does not seem to accept difficulty less than 256.  Here is the overnight run I did at 300MHz



There are definitely a couple of points where it stopped, but less than I am seeing at 375MHz. The rate looks very scrappy perhaps because the Hash rate is so low? However overall it shows 15.36GH which is close to the theoretical rate of 16.5GH given that there weretimes when it was not hashing.

Rich

[RichBC]

With the above changes and having put the Monitor script up from 1 Min to 2 Min I have been running at 375MHz, 20.6GH for a couple of Hours now without a stop. I think another problem that I had was having a PC connected to the serial. Any data on the serial stops the Mining?

Amusingly with the way the BTC has risen at the most efficient Frequency of 225MHz I make $.02 / Day and electricity cost $0.015 / Day net $.005 / Day  

Spoke too soon, while typing I have just had a stop, Error code is unfortunately not reported until the restart..... (Can this be changed?)..... It was case B again, I will up the Monitor again (Should have listened to aarons6)


Rich

Update

Latest stop, miner not hashing, after 45 Mins. Has not restarted, however cron is still being called every 4 Mins and not reporting a problem. Edited the Cron script as I saw a couple of echo's I had missed & on saving immediate restart. Any ideas?



Rich

[aarons6]

With the above changes and having put the Monitor script up from 1 Min to 2 Min I have been running at 375MHz, 20.6GH for a couple of Hours now without a stop. I think another problem that I had was having a PC connected to the serial. Any data on the serial stops the Mining?

Amusingly with the way the BTC has risen at the most efficient Frequency of 225MHz I make $.02 / Day and electricity cost $0.015 / Day net $.005 / Day  

Spoke too soon, while typing I have just had a stop, Error code is unfortunately not reported until the restart..... (Can this be changed?)..... It was case B again, I will up the Monitor again (Should have listened to aarons6)


Rich

Update

Latest stop, miner not hashing, after 45 Mins. Has not restarted, however cron is still being called every 4 Mins and not reporting a problem. Edited the Cron script as I saw a couple of echo's I had missed & on saving immediate restart. Any ideas?



Rich

does it stop on other pools?
i was thinking.. with NH.. even my s3 and my s5 dropped down sometimes when i mined on it.. its because you dont always mine bitcoin.. you are essentially renting hash to someone that tells your miner what to mine.. you could be mining some low difficulty crap coin and the switch jams it up..

maybe try NH solo and check the graph to see if it drops out the same.. like i said tho you will prob get the miner not hashing reset if the difficulty is too high.

[RichBC]

Yes good point on NH. I may go back to the Antrouter Solo as that automatically setd difficulty 16.

Not sure what to make of this? I have had another stop that has not restarted, been down for about 30 mins. One of the lines that I had missed to change to logger has the Last Valid Work.

Code:

Sun Oct 25 17:24:01 2015 cron.info crond[839]: crond: USER root pid 6522 cmd /usr/bin/cgminer-monitor
Sun Oct 25 17:24:02 2015 user.notice root:    [Last Valid Work] => 1445793841

Sun Oct 25 17:28:01 2015 cron.info crond[839]: crond: USER root pid 6664 cmd /usr/bin/cgminer-monitor
Sun Oct 25 17:28:02 2015 user.notice root:    [Last Valid Work] => 1445794081
Sun Oct 25 17:32:01 2015 cron.info crond[839]: crond: USER root pid 6716 cmd /usr/bin/cgminer-monitor
Sun Oct 25 17:32:02 2015 user.notice root:    [Last Valid Work] => 1445794321
C
Sun Oct 25 17:36:01 2015 cron.info crond[839]: crond: USER root pid 6759 cmd /usr/bin/cgminer-monitor
Sun Oct 25 17:36:02 2015 user.notice root:    [Last Valid Work] => 1445794562

Sun Oct 25 17:40:01 2015 cron.info crond[839]: crond: USER root pid 6793 cmd /usr/bin/cgminer-monitor
Sun Oct 25 17:40:02 2015 user.notice root:    [Last Valid Work] => 1445794801
Sun Oct 25 17:44:01 2015 cron.info crond[839]: crond: USER root pid 6824 cmd /usr/bin/cgminer-monitor
Sun Oct 25 17:44:02 2015 user.notice root:    [Last Valid Work] => 1445795042

Sun Oct 25 17:48:02 2015 user.notice root:    [Last Valid Work] => 1445795282
Sun Oct 25 17:52:01 2015 cron.info crond[839]: crond: USER root pid 6888 cmd /usr/bin/cgminer-monitor
Sun Oct 25 17:52:02 2015 user.notice root:    [Last Valid Work] => 1445795521
d-PC
Sun Oct 25 17:56:01 2015 cron.info crond[839]: crond: USER root pid 6923 cmd /usr/bin/cgminer-monitor
Sun Oct 25 17:56:02 2015 user.notice root:    [Last Valid Work] => 1445795762

Sun Oct 25 18:00:01 2015 cron.info crond[839]: crond: USER root pid 6952 cmd /usr/bin/cgminer-monitor
Sun Oct 25 18:00:02 2015 user.notice root:    [Last Valid Work] => 1445795839
Sun Oct 25 18:04:01 2015 cron.info crond[839]: crond: USER root pid 6986 cmd /usr/bin/cgminer-monitor
Sun Oct 25 18:04:02 2015 user.notice root:    [Last Valid Work] => 1445795841

Sun Oct 25 18:08:01 2015 cron.info crond[839]: crond: USER root pid 7038 cmd /usr/bin/cgminer-monitor
Sun Oct 25 18:08:02 2015 user.notice root:    [Last Valid Work] => 1445795846
Sun Oct 25 18:12:01 2015 cron.info crond[839]: crond: USER root pid 7085 cmd /usr/bin/cgminer-monitor
Sun Oct 25 18:12:02 2015 user.notice root:    [Last Valid Work] => 1445795846

Sun Oct 25 18:16:01 2015 cron.info crond[839]: crond: USER root pid 7176 cmd /usr/bin/cgminer-monitor
Sun Oct 25 18:16:02 2015 user.notice root:    [Last Valid Work] => 1445795852
0
Sun Oct 25 18:20:01 2015 cron.info crond[839]: crond: USER root pid 7213 cmd /usr/bin/cgminer-monitor
Sun Oct 25 18:20:02 2015 user.notice root:    [Last Valid Work] => 1445795860

Sun Oct 25 18:24:01 2015 cron.info crond[839]: crond: USER root pid 7237 cmd /usr/bin/cgminer-monitor
Sun Oct 25 18:24:02 2015 user.notice root:    [Last Valid Work] => 1445795862

Sun Oct 25 18:28:01 2015 cron.info crond[839]: crond: USER root pid 7326 cmd /usr/bin/cgminer-monitor
Sun Oct 25 18:28:02 2015 user.notice root:    [Last Valid Work] => 1445795868

I have edited out the log lines not relevant to Cron.

As you can see initially there are quite large increases in LVW. I think the miner stopped somewhere around 18:00 after that the increases in LVW are much smaller however they do increase although at one point 1445795846 it is repeated. So not sure what LVW is or what the cron job is looking for to trigger a restart of cgm however it did not do a restart?

What do you think?

Rich

[aarons6]

Yes good point on NH. I may go back to the Antrouter Solo as that automatically setd difficulty 16.

Not sure what to make of this? I have had another stop that has not restarted, been down for about 30 mins. One of the lines that I had missed to change to logger has the Last Valid Work.

Code:

Sun Oct 25 17:24:01 2015 cron.info crond[839]: crond: USER root pid 6522 cmd /usr/bin/cgminer-monitor
Sun Oct 25 17:24:02 2015 user.notice root:    [Last Valid Work] => 1445793841

Sun Oct 25 17:28:01 2015 cron.info crond[839]: crond: USER root pid 6664 cmd /usr/bin/cgminer-monitor
Sun Oct 25 17:28:02 2015 user.notice root:    [Last Valid Work] => 1445794081
Sun Oct 25 17:32:01 2015 cron.info crond[839]: crond: USER root pid 6716 cmd /usr/bin/cgminer-monitor
Sun Oct 25 17:32:02 2015 user.notice root:    [Last Valid Work] => 1445794321
C
Sun Oct 25 17:36:01 2015 cron.info crond[839]: crond: USER root pid 6759 cmd /usr/bin/cgminer-monitor
Sun Oct 25 17:36:02 2015 user.notice root:    [Last Valid Work] => 1445794562

Sun Oct 25 17:40:01 2015 cron.info crond[839]: crond: USER root pid 6793 cmd /usr/bin/cgminer-monitor
Sun Oct 25 17:40:02 2015 user.notice root:    [Last Valid Work] => 1445794801
Sun Oct 25 17:44:01 2015 cron.info crond[839]: crond: USER root pid 6824 cmd /usr/bin/cgminer-monitor
Sun Oct 25 17:44:02 2015 user.notice root:    [Last Valid Work] => 1445795042

Sun Oct 25 17:48:02 2015 user.notice root:    [Last Valid Work] => 1445795282
Sun Oct 25 17:52:01 2015 cron.info crond[839]: crond: USER root pid 6888 cmd /usr/bin/cgminer-monitor
Sun Oct 25 17:52:02 2015 user.notice root:    [Last Valid Work] => 1445795521
d-PC
Sun Oct 25 17:56:01 2015 cron.info crond[839]: crond: USER root pid 6923 cmd /usr/bin/cgminer-monitor
Sun Oct 25 17:56:02 2015 user.notice root:    [Last Valid Work] => 1445795762

Sun Oct 25 18:00:01 2015 cron.info crond[839]: crond: USER root pid 6952 cmd /usr/bin/cgminer-monitor
Sun Oct 25 18:00:02 2015 user.notice root:    [Last Valid Work] => 1445795839
Sun Oct 25 18:04:01 2015 cron.info crond[839]: crond: USER root pid 6986 cmd /usr/bin/cgminer-monitor
Sun Oct 25 18:04:02 2015 user.notice root:    [Last Valid Work] => 1445795841

Sun Oct 25 18:08:01 2015 cron.info crond[839]: crond: USER root pid 7038 cmd /usr/bin/cgminer-monitor
Sun Oct 25 18:08:02 2015 user.notice root:    [Last Valid Work] => 1445795846
Sun Oct 25 18:12:01 2015 cron.info crond[839]: crond: USER root pid 7085 cmd /usr/bin/cgminer-monitor
Sun Oct 25 18:12:02 2015 user.notice root:    [Last Valid Work] => 1445795846

Sun Oct 25 18:16:01 2015 cron.info crond[839]: crond: USER root pid 7176 cmd /usr/bin/cgminer-monitor
Sun Oct 25 18:16:02 2015 user.notice root:    [Last Valid Work] => 1445795852
0
Sun Oct 25 18:20:01 2015 cron.info crond[839]: crond: USER root pid 7213 cmd /usr/bin/cgminer-monitor
Sun Oct 25 18:20:02 2015 user.notice root:    [Last Valid Work] => 1445795860

Sun Oct 25 18:24:01 2015 cron.info crond[839]: crond: USER root pid 7237 cmd /usr/bin/cgminer-monitor
Sun Oct 25 18:24:02 2015 user.notice root:    [Last Valid Work] => 1445795862

Sun Oct 25 18:28:01 2015 cron.info crond[839]: crond: USER root pid 7326 cmd /usr/bin/cgminer-monitor
Sun Oct 25 18:28:02 2015 user.notice root:    [Last Valid Work] => 1445795868

I have edited out the log lines not relevant to Cron.

As you can see initially there are quite large increases in LVW. I think the miner stopped somewhere around 18:00 after that the increases in LVW are much smaller however they do increase although at one point 1445795846 it is repeated. So not sure what LVW is or what the cron job is looking for to trigger a restart of cgm however it did not do a restart?

What do you think?

Rich

did you change this line?
echo "$B" > /tmp/cm.log

you want to not change that line..

[RichBC]

I did and can see now that the log will not be updating...

I also changed echo $cpuifo should that be put back as well?

Rich

[aarons6]

I did and can see now that the log will not be updating...

I also changed echo $cpuifo should that be put back as well?

Rich

yeah those are important for the script to run.
well maybe not the cpuinfo one. doesnt look like that does anything.


if you want it to still show the share in the log you can just add the line under it..
hm i think that line has a bug in it tho, cause if you edited the echo, cgminer should have restarted every time the script ran.. let me tweak it

[RichBC]

Yes I have copied the line, will do the same with cpuinfo in case it's being used. What is the test / comparison that is being done at this point?

Rich

[aarons6]

Yes I have copied the line, will do the same with cpuinfo in case it's being used. What is the test / comparison that is being done at this point?

Rich

its comparing the last share to the current share, if they are the same == or if its blank "" cgminer restarts..

but try this..
every where it says this..

    killall -s 9 cgminer
    sleep 1
    /etc/init.d/cgminer restart



change it to this
    /etc/init.d/cgminer stop
    sleep 3
    /etc/init.d/cgminer start


im wondering if the killall command isnt working right.

[RichBC]

Will try that but just looked in cm.log after putting the echo back and there is nothing there? Not sure if it get's deleted?

Rich

I will need to go back to NH to test this of course. Have checked cm.log several times during running and nothing there.

Update the logger command seems to be stopping the write, even if it followed the echo?

Also remember that several times there has been a restart after a stop with a Case B

The other thing that is odd and would stop things working, if you look in the log above, is that after the miner had stopped hashing the Last Valid Work kept incrementing?

[RichBC]

OK rewind. I had just put logger in front of "$B" > /tmp/cm.log
I think that just put a blank into cm.log so have changed to logger $B

Seems fine now and I can see the Last Valid Work in the log file and cm.log is being updated.

So back on NH and will let that run to a stop before trying your code. Do not think the restart code is the problem as most times it works. Now if I do not get a restart after a stop I can see the LVW in the system log....

Rich

[CrazyGuy]

Somebody with an R1 should check to see if  /usr/bin/cgminer-monitor is a real program, or just some kind of script. If it's a script, it might provide some useful guidance to folks with U3's on how to "work around" the zombie issue. While they might still go zombie, maybe the "hand holding" could be reduced.

i just checked this script and all it does for the cgminer-u3 is stop it if it cant reach the internet..
it wont do anything for zero hash or zombie condition..

it does stop and restart the internal chip if it doesnt send a share in x amount of time.. it woudlnt be hard to make a new script to do the same for the u3.

You can use their cgminer-api binary for the u3 instance and retrieve stats with the following commands:

Code:

cgminer-api stats localhost 4029
cgminer-api devs localhost 4029

The only issue is that you could be dealing with multiple devices, so the U3 check will need to be a little more complex.

[RichBC]

Time for an update. Here is the latest setup.



I have stacked a few more heatsinks on the chip, you can see the voltage adjust pot on the RHS, probes are montoring the Core Voltage. I ran overnight at 375MHz, 0.74V on the Core, Hashing at just over 20GH/s. Chip temperature held by the fan controller at a steady cool 35 Deg.

Here is the result of my overnight run on the Antrouter Pool.



Reported hash rate is a fairly solid 20GH/s

The miner stops hashing at irregular intervals anything from 5 Minutes to an Hour. The Cron Job then detects that the miner is not working and restarts cgminer. Here is a typical sequence from the System Log.

Code:

Mon Oct 26 07:12:01 2015 cron.info crond[839]: crond: USER root pid 30265 cmd /usr/bin/cgminer-monitor
Mon Oct 26 07:12:01 2015 user.notice root: [Last Valid Work] => 1445843521
Mon Oct 26 07:14:01 2015 cron.info crond[839]: crond: USER root pid 30289 cmd /usr/bin/cgminer-monitor
Mon Oct 26 07:14:01 2015 user.notice root: [Last Valid Work] => 1445843641
Mon Oct 26 07:16:01 2015 cron.info crond[839]: crond: USER root pid 30315 cmd /usr/bin/cgminer-monitor
Mon Oct 26 07:16:01 2015 user.notice root: [Last Valid Work] => 1445843750
Mon Oct 26 07:18:01 2015 cron.info crond[839]: crond: USER root pid 30341 cmd /usr/bin/cgminer-monitor
Mon Oct 26 07:18:01 2015 user.notice root: [Last Valid Work] => 1445843750
Mon Oct 26 07:18:01 2015 user.notice root: Case B

You can see the repeated LVW that the script has picked up and these are valid stops as I have sat and watched some stops.

So bottom line is that the Cron script is doing a good job of keeping the Miner going, the question is why does the miner stop in the first place?

I will wind the frequency right down to standard Today and see if it is frequency related?


Rich

[valkir]

wow thats a nice mod!  20gh is huge for this little device. Great job Rich!

[citronick]

Question:

assuming i have a few U3 to spare and connect it to the R1 with hub...

how do i add my U3 hash to the current R1 hash?