Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 91. (Read 5805523 times)

Thanks for the info Kano. Just to clarify, in order to override the default "--queue 320" options, I can simply add "--queue 0" (required for p2pool) to the script you mentioned in /config/cgminer - this will then override the default commands? Have I got that right?  Or, can I simply add "-Q 0" after the password on the web interface as with the S1 fix?

Of course, I wont do this until you've investigated the p2pool issue. Just planning ahead 

This is a gross exaggeration for any existing hardware that uses the bifury protocol on cgminer which produces only tiny amounts of traffic. Scaling device internal diff to pool diff will just make the hashrate calculation more and more inaccurate but not have any significant effect on performance or decrease CPU utilisation. Your OSM devices max out at 32GH which produces only 7 shares per second - even an RPi wouldn't register any measurable CPU usage processing those to filter out and send only the suitable shares to the pool. That's not to say the change won't eventually be required and welcome, just that it is not something I have time to work on at the moment since there is no benefit to existing miners.

Yes it is simply cgminer 4.3.5 no changes.
Master cgminer git has the S2 code in it.
The Web interface may wipe out any options you add to it, if you later use the web interface to update the cgminer.conf

There is one way around this:
Create a script file /config/cgminer
Then chmod +x /config/cgminer
From now on, the S2 will run that script and thus any changes you put in there will not be lost on a reboot

You can even completely override the settings that way by not using "$@"
"$@" means put there all the options that were passed in.

The default settings are:
--bitmain-dev /dev/bitmain-asic --bitmain-options 115200:32:8:40:196:5f06 --bitmain-checkn2diff --bitmain-hwerror --queue 320
plus the options/pools in the /config/cgminer.conf

Also, never remove "--bitmain-hwerror" since it all goes to crap if you do.

Edit: oh I guess I should have said, that the /config/cgminer change only works with my 'firmware' I changed it like that on purpose due to the fact the that S2 filesystem doesn't save changes - the only permanent writable areas are /config/ and /mnt/mmc/
/mnt/mmc/ is where the 'firmware' is
Don't leave anything in there though, since it isn't very big.

On the other hand! /config/ is 1.5GB to store a few K of data
Warning about /config/
The Bitmain factory reset deletes everything in there.
My factory reset deletes everything in /config/ but not in sub directories - so files in sub directories will survive a reset.

Maybe that's why p2pool is completely non functional?  I'm pretty sure it starts at 1.  I didn't try manually setting it higher.

Maybe also why the stratum proxy fails hard with difficulty errors?

M

Thanks kano.

Does your version allow for all the standard cgminer options in the conf file? ie: failover-only : "true", queue : "0" etc?

5m I purposely show blank until ... 5m has passed.

The API is the standard cgminer API - not the bitmain hacked changed API with the wrong field names and different field scales.

OK, I'll fix my p2pool tomorrow and point it at it and see what's up.

Also note: the hash rate should initially vary a lot since the shares returned will be 2^N that is below the pool difficulty.
So e.g. mining at difficulty 60 would set the S2 to mine at difficulty 32 (2^N below 60) - so the driver would only get a reply from the boards every time they find a difficulty 32 nonce or better (similar to the original driver)
This means that the cgminer code that calculates the stats will get 1/32 of the results (of diff 32) to determine the hash rate and thus it takes longer to average out.
I set an upper limit of 4096 to ensure results are coming back and thus we can see it's all working (but the bitmain driver doesn't have a limit)
Normally give it at least 10 minutes, if not an hour, to show the proper hash rate.

Another of my changes there vs the Bitmain driver, is to use the lowest difficulty of all the work sent in a batch.
Bitmain's version uses the first difficulty, which since a batch of work is 64 work items, there is the tiny possibility that some work would be different to the first work item.
Also note that the bitmain driver discards stale shares ... so on p2pool where a stale block is actually a valid block 95% of the time, the bitmain driver throws those blocks away ... literally.
I of course don't do that

Another change is that I fully check all the share's returned.

However, this means that if a pool starts of at 1diff, it will indeed get a lot of problems (due to lack of CPU) until the difficulty rises high enough.
If that happens, blame the pool for allowing 1diff
No pool should be doing that now since anyone mining only with hardware that slow is wasting theirs and the pool's time.

I'll let you know tomorrow how I fare with p2pool

I couldn't get any hashrate to p2pool or slush's proxy.  I like the additional visual changes to the status page.. however the avg hashrate was unintelligible (said something like 16423), and the 5m hashrate was blank.  API response on hashrate was also gone/unintelligible.

M

Yup, same here - unable to connect to p2pool node. I'm also seeing some HUGE hash rate variation - anything between 2000Gh/s(!) to 600Gh/s - but the average rate is slightly higher than the standard firmware. I'll keep playing.......

Thanks!

I applied it to one of my S2s.  Results haven't been good.

It won't connect at all to p2pool.  On the p2pool side, it throws a TON of errors I've never seen before.
I then pointed it to my slush proxy for Eligius.  Every single hash is rejected. "u'high-hash'".

Going back to prior firmware...

M

So, if I understand you correctly I need to make the following changes to driver-bitfury.c :

   sprintf(buf, "target ffffffff\n");
into
   sprintf(buf, "target %08lx\n",(0xffffffff/pool_difficulty));

      ret = (double)0xffffffff * nonce_rate;
into
      ret = (double)(0xffffffff/pool_difficulty) * nonce_rate;

      info->nonces++;
(occurs twice) into
      info->nonces += pool_difficulty;

I do understand that I also need to take into account that more than one OneStringMiner could be connected and that they could be mining on different difficulty, but normal use will be one or more connected miners mining on the same pool on the same account and hence the same difficulty.

I also understand that if you change it for one device, you will be asked/want to change it for all.
To me it looks like a valuable change, given the waste of traffic that now occurs.

Hello guys,

First off, thanks to Kano for all his work on the S1 & S2's - it is appreciated - thanks 

I've been testing out the newly released S2 firmware on one of my S2's in the hope it would improve it's compatibility with p2pool, but I'm unable to even connect with my local node using the "stratum+tcp" prefix using both the IP address or the web address - the pool shows up as "dead" on the S2 web interface. I've also tried using "http" which gives me 100% stales & just the IP address:port but still am unable to connect - can you give me any pointers at all?

Cheers guys.

From the protocol document:


As for cgminer, the hashrate reported is based on shares returned via bitfury_rate * a fixed value for one full nonce range (0xffffffff) by the number of info->nonces returned which increments in parse_bxf_submit.  As the full nonce range is hardcoded in the bitfury rate function, it would need a rewrite to support variable difficulty being changed on the fly or if you want to play with a hardcoded value for your own use, just change the full nonce range to how much bigger you're aiming for, so if you halve the target diff you double the value. As you can see it affects a lot of different types of devices and the code for associating a changing diff with the nonce range would need quite some rework still.

I have a rather technical question about using cgminer with Bitfury based hardware (The OneStringMiner boards I am selling).
In driver-bitfury.c, the target that is sent to the boards is always ffffffff, no matter what the difficulty is on the pool.
I think the value of ffffffff corresponds to a difficulty of 2.
If the pool is set or gets to a higher difficulty, a lot of shares are thrown away because they are above target.
This means a lot of useless traffic between the boards and the host computer running cgminer.

In order to prevent this, I changed the above mentioned ffffffff to 0fffffff to lower the number of shares that are thrown away. A simple trick with a drawback, the speeds shown by cgminer is now incorrect. Not a big issue, but it would be nice if the values would be correct.
Also 0fffffff corresponds with a fixed pool difficulty. It would be better if this would be changed automatically when the pool sets a new difficulty.

Of course, the speed that I see on the pool is correct, because that's calculated by the pool software.

What's the best way to improve this ?

Did support for the R-Box make it into this release?  I did not see it listed but I was hoping it made it in there.
Thanks again. 

Kano is king!!!  You da man 

Will begin testing straight away & report back - many, many thanks Kano!!

I've created an AntMinerS2 firmware.
Master cgminer code - and no changes/hacks (that are required for the S1)

I've been using various versions of this for a while now without cgminer problems.
However, do consider it still in testing until it has been run more widely ... than just a few people
It's easy to undo - just flash a Bitmain 'firmware'

There are issues with the Bitmain AntMinerS2 firmware that for some would make this upgrade rather important

The README and "How to" information is here:
https://github.com/kanoi/cgminer-binaries/tree/master/AntS2

Some of that:

How to upgrade your AntS2:
Download the lastest 'firmware' file from:
 https://github.com/kanoi/cgminer-binaries/tree/master/AntS2
 The filename will be like:
   initramfs.bin.SD-Kano-NNNNNNNNNNNNNN.tar
  where NNNNNNNNNNNNNN is the date stamp
  the newest one will be last down the page
 To download it, you will need to first click on the filename and then on the
  page that comes up, "right-click" on "View Raw" and then "Save Link As..."
  or "Save Target As..." to save it on your computer

Upgrading is the same as the standard Bitmain 'firmware' upgrade details:
 From the AntS2 web interface tab: "System" -> "Upgrade":
  make sure you have "Keep settings:" ticked,
  click on "Browse..." to select the 'firmware' file you downloaded
  then click on "Flash image..."

See "SD Recovery" below for possible ways how to recover the SD card if the
 udpate was interrupted or failed

Releases:

The cgminer binary is compiled on a BeagleBone Black with the configure:
 CFLAGS="-W -Wall -O2" ./configure --enable-ants2

11-Jun-2014
 initramfs.bin.SD-Kano-20140611145346.tar
 cgminer official release version 4.3.5 plus initial 'firmware' changes

Changelog:

Initial 11-Jun-2014
 cgminer 4.3.5 with a modified AntS2 driver - see master git for details
 Web "Miner Status" uses standard cgminer API fields, highlights some issues
  in the "AntMiner" section in colour, provides good/bad chip counts and also
  displays an expected performance
 Web "Miner Configuration" expanded to include setting "API Allow"
 LCD display includes block found count "N" in the bottom left "B:N"
 If an executable exists "/config/cgminer", that will be used instead of the
  system /usr/bin/cgminer - this allows for easy cgminer binary upgrades
 If you factory reset the AntS2, the default mining is Kano instead of Bitmain
 Tidied up the default mining configuration to be only in one place (rather
  than 3 copies of it) /etc/cgminer.conf.factory
 Web interface and LCD report "Ant Miner/K" and a little (kano) in the top
  right of the AntMiner image - so you can definitely see if you are running
  a modified Kano 'firmware' or an original Bitmain 'firmware'

Is there a changelog somewhere for the updated hashfast driver?

edit: found it "Avoid dereference on getting API stats on partially initialised HFA instances"

Thanks!

Firstly, this should show up in the API stats as [SPI Waiting] or [SPI Sent] growing.
That's the work waiting to be sent to the board or that has been sent but waiting for the code to process the reply.
It should be low (0 or 1 - possibly 2 ...)

One most likely cause of this is if you are getting a LOT of HW errors due to faulty hardware it can overload the CPU checking all the bad results.
This will show up as high CPU usage.
It can thus starve the SPI thread of CPU so it takes longer than expected to send the work and store the reply.

To check your CPU usage:
In one terminal window run 'top' and press 'P'
In another window do an API summary ... and at the same time note the CPU usage of cgminer under TIME+

e.g. for me just now:
 10821 root      10 -10  199356  17700   2716 S 15.0  3.7  73:59.57 cgminer-4.+
and
 [Elapsed] => 31890

So that says cgminer elapsed total 31890 seconds, used 73m 59.57s of CPU or ... 13.92% of CPU for my 7 boards - not bad

Uptime for me shows:
 load average: 0.26, 0.57, 0.62
So clearly no CPU issue

Also check [Delay Bands] and see if they are high.
Most work should be in "<1.5" or less

The API estats (or API stats if you are running an older cgminer) has a truck load of data in there for BaB0 saying what is going on
I guess a link to a pastebin of that, if you are not getting high CPU, would help.
Also add API summary since that says a lot of useful info also.

Hey guys,

I keep getting an error that I have never seen before running cgminer 4.3.4 on Arch via the Raspi.

The error is BaB0: Delay getting work reply

I cant find any one else having this issue, any help is greatly appreciated.