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

I'm new to bitcoin world  so hello !

I'd like to know, how do your code is compatible with asic miners ? all of the fpga/asics are on the same design ?
Is there a open source VHDL of the fpga circulating (if i want to test on my cyclone4 dev board for example, is there a way ? )

Stratum work isn't large.
It sends a merkle tree slice size O(log2(n)) (n=txn count) plus a coinbase txn - where the size of the coinbase txn will of course depend on what extra 'stuff' is put in there.
P2pool likes to put a bucket load of micro-payments in there - yep - so use something other than p2pool.

Also, if you are saying that multiplying it by a large number makes it large - well yep that's true of any number >=1

A network packet is up to 64k - but of course they are broken up depending on the network connection settings.
But again you're looking at it the wrong way.
Indeed a single stratum response is bigger than a single getwork response, but the stratum response is usable for 30s (longer on bad pools ) and with a small 32bit nonce2 will support > 6millionTH/s for that 30s.
With all of that work being rolled up to the cgminer maximum of 90s, that's of course more than 500millionTH/s
Thus a proxy for up to 500millionTH/s of miners is a few K of work sent to the proxy every 30 seconds.

The original rollntime was a bad design idea to start with.
Doing small rolls on stratum (up to 90) is a reasonable solution to reduce workload generating internal stratum work.
Doing large rolls is actually an issue on the bitcoin network itself. The larger the roll, the more the small possibility of valid blocks being rejected, increases.

My point being that if there is a getwork endian issue - submit a cgminer pull request fix.
No I don't test getwork - I don't even have a reasonable source of it setup anywhere that will find results.

Not sure - the only good proxy I know of isn't ready yet.

Not really. The latency between the sites is up to 30ms, which causes only about 0.2% stales by itself. However, it would increase non-linearly with addition of units, since each of them receives several kilobytes (because of large coinbase) simultaneously at work restart.

The trick I am trying to do is increasing rollntime to say 1000, which means 1 getwork request per 20s per unit. Getwork response fits within 1 packet, while stratum response from p2pool is several kB. Please correct me if I am wrong.

I may be wrong but it seems like it has something to do with the endian issue. It was fixed at some time before your last build. In the stock binary (I mean that old one, supplied as a part of S1 ROM), getwork sends wrong nonce, while in your last build, it sends empty responses (does not submit solutions). Maybe you just didn't test getwork?

Which proxy do you suggest? The stratum-mining-proxy by slush?

Thank you!

First problem in what you are doing:
 p2pool and the farm located remotely from each other
Bad idea. P2pool is extremely dependent upon latency due to the excessive restart rate.

Getwork will use way more bandwidth than stratum.
The Getwork in my S1 binary is the Getwork in cgminer - same thing - I'm part of the cgminer team, not a fork.

Your setup is the fault.
Add a proxy if you wish to reduce bandwidth.
Moving away from stratum would only be due to you misunderstanding how the protocols work.

Cross compiling is the same as for the avalon.
Read their info on how to do that ... or the abundant info provided by openwrt.

The distro running on it is Angstrom.
It's pretty much pointless swapping distros since you'd have to build the full distro with all the required support.
Also, the S2 has 2 kernel modules ... and no source available for one of them.
So if the bitmain_spi.ko doesn't work on the distro you build - you've got no solution.
The "firmware" file is simply the initrd of the full Angstrom linux it runs.
"Firmware" is in quotes because ... it isn't "firmware"
So (as I've been doing) to update it you first pull apart the one on the S2, change/replace the files you want to change, and then put it back together again.
I have the 'putting it together' automated so I can make a "firmware" with a single command - but of course that's to build one - you first have to work on changing/testing everything as required.

How do I (cross-)build cgminer for AntMiner S1?

The problem I am trying to solve now is poor scalability of S1 + p2pool (the node and the farm located remotely from each other). Stratum connection results in transfering several kilobytes once per ~30s for every S1 unit simultaneously, which increases latency. At the same time, getwork seems to be broken in current cgminer builds for AntS1 (both stock and latest kano's build), so I want to rebuild and debug it.

That looks like what I was seeing with my r-box only it was CGminer detecting my Antminer U1's that were running on BFG. To get it to stop I had to place a limit on the number of devices CGminer initiates and starts once it has my R-boxes started it reaches the max device limit and stops scanning for more devices. I was looking for command line statements to load just the R-boxes but someone told me how to do it this way and it works so I left well enough alone.

The steps for controlling USB device scan are listed in the Advance USB section of the readme.... (probably around line 319 if I were a betting man since that is where ckolivas pointed you to).

It's telling you exactly what to do. Read the readme - I can lead a horse to a readme but I can't make it read it. Install the winusb driver and associate your new device with the winusb driver using zadig , and always use the latest cgminer. Let me be explicit: Go to line 319 on the file README.txt

hi Everyone, i m in trouble with a RED FURY Bitfury USB ASIC 5 Gh/s, i ve done all the downloads as advised in many guides but still get errors, it mines apparently but loads of errors.

I was thinking if i am using an old version of cgminer, searched everywhere and cnt find anything that can help me.

Below is the pic of the errors im getting. Please...is there any1 that could give me a help me?  http://i61.tinypic.com/2lt4uo4.png
 Please please pretty please, 

Hi, I am using BitBurner Fury Rev 1.1 boards that show as BTB in CGMiner 4.3.4

Is this correct or should they be labeled as BBF?? I've installed the latest firmware available from www.asichardware.com (now no longer available, blame Cryptx)

Boards are hashing well though

Thank you. Not quite what I was looking for but it worked.

The Advanced USB options section of the readme explains how to include and exclude mining hardware.

Can anyone tell me how to detect and start one or more rockminer R-box miners without the display constantly scrolling messages about a wrong driver for devices that are mining already on a different mining software. Is there a way to directly start the R-box's without scanning and attempting to start all the Antminer U1's? I just want the R-box's loading on CGminer as the others are running and stable on the other platform.

Any help will be greatly appreciated.

T.

Solving this myself, the previous version did work without -o http:// . So to anyone who's wondering, running 4.3.4 successfully will simply require:

cgminer.exe -o http://localhost:8332 -u something -p something --btc-address insertbitcoinwalletaddresshere

Thanks for the tip, but adding --btc-address [insert bitcoin wallet address here] to the command-line does not change the picture. As said, cgminer 3.12.3 worked out of the box with these settings.

Did you tell it which bitcoin address to mine for?

If not read the readme.

I've been solo mining with cgminer 3.12.3 and now updated to 4.3.4.

However, the same setup (BITMAIN AntMiner U1) which worked on the earlier version, no longer seems to work on the new. (Startup simply: "cgminer.exe -u blah -p blah -o 127.0.0.1:8332")

Running a --debug gives the following:

Popping work from get queue to get work
Testing pool stratum+tcp://localhost:8332
Succeeded delayed connect
Socket closed waiting in recv_line
Closing socket for stratum pool 0
Failed to parse a \n terminated string in recv_line
Initiate stratum failed
Closing socket for stratum pool 0
Waiting for work to be available from pools


I tried starting it with the --fix-protocol -option, but to no avail.

Hi again guys - another question about the S2 thing. I've noticed that there is an Ubuntu distro for the Beaglebone, which is the S2 controller, so was wondering if it would be possible to use cgminer on this instead of the current Linux distro? Would cgminer be able to detect the hashing boards via pci though? Maybe in the same way it used to detect GPU's? I'm not sure - just throwing stuff out there.........if only they were usb .......

Peace 

Hello after a few of tests, I think its a compatibility problem between Cgminer and a other Software (RaspControl for the Cgminer) to Log the Cgminer!


But the crashes are only by the Antminers and very often with the new 4.3.4 with 4.2.0 it's better.

regards

I hear you, it's very frustrating - especially as I can't use it on p2pool without losing even more hashing rate. I must have been lucky with mine though, only minor courier impact (loose/disconnected cables) & it hashes at ~1050Gh/s steady. I'd be happy to help if you need any testers by the way - just let me know.

Thanks again Kano