I don't understand how bfgminer got this working without zadig but cgminer needs it?
BFG and CGMiner both used to use the FTDI drivers for USB devices. CGMiner switched to libusb, but requires you to reinstall new drivers. Once you do it one, it should be all set. I understand that part, but why make people do the extra step? bfgminer doesn't need it when ASIC's are run there. Because direct USB is better, plain and simple. (inb4 Luke-jr's trolling) Define better. Hashes more? Once it's working properly (see caveats regarding multiple lancelot based hardware not working properly so far), lower overhead, lower cpu, scaleable to higher hashrates for the same hardware, less points of failure (no driver between cgminer and the device), lower latencies and finer control over the device. See the Avalon and BFLSC performance for examples of it working successfully. |
|
|
|
Hello, On my Raspberry Pi I am having the issue described here (describing the same issue in Ubuntu 12.04LTS): http://bitcoin.stackexchange.com/questions/11829/bitcoin-erupters-not-stable-on-ubuntu-and-cgminer-3-3Basically in 3.3.1 (or 3.2.1, 3.2.0) with 1 USB AsicMiner Erupter, on a USB2.0 hub all is good hashing around 333MHs stable. If I add a second stick (or more) hashrate jumps all around with all chips eventually getting SICK and restarting. Built following instructions and verifying prereqs. I'm rebuilding an Ubuntu box to try to reproduce there. Any tips on something I may be doing wrong or ideas on the problem? Only cgminer 3.1.1 is stable with that hardware, using the old serial usb interface. We moved to a new driver model from 3.2.0+ for this sort of hardware and it has proved problematic for this hardware when multiple are in use. Oh and we do update our code a LOT, it's just that we hit a snag with this hardware and the new driver model and have as yet been unable to resolve it. |
|
|
|
|
Aggression is not a cgminer term. You're already using intensity which is the equivalent.
|
|
|
|
I'm also going to post another revision, with 2 additions: Jalapenos that are flashed to 8GH/s, and Bitfurys ASICs.
Updated OP with those 2 revisions. How does BitFury plan on getting 3x the power efficiency as BFL at the same 65nm? He's claiming even 50% more efficient than KNC, which is supposed to be using a 28nm process. Weird. At this stage it remains a claim then, much like earlier BFL claims... |
|
|
|
The firmware tests the engine (and chip if you have multiple chips) performance at startup and adjusts the speed accordingly based on how "correct" the answers are from each engine. It is not unusual for the existing Jals out there to be somewhere between 27 and 30 units when run at the higher speeds. 30 is the most that can be activated on 2+ chip units. When run at their lowest speed as 5GH units, most of the engines seem to work making all 30 start at 189MHz ~5.7GH. I posted firmware which relaxes the test dramatically making it far more likely to activate all 30 engines at speed setting "7" which is 274MHz, so 30 engines at 274 ~8.2 GH. I can't comment on the binned versus unbinned policy for chips by BFL but it looks like earlier units were unbinned making them potentially full speed, while later ones were chosen to reach the guaranteed speed as a minimum.
Unfortunately some of the hardware errors are currently counted towards the hashrate so you cannot simply look at the hashrate and determine whether you're creating all good work. I'm planning on rectifying that next cgminer version.
Can you be so kind to please post the code to the modified firmware, since I want to test my Jally at speeds "9" and using all engines.  Just comment out these lines in ASIC_Engine.c if (iReadBackNonceCount < 4)
{
// This engine is DEAD!
bWasAnyEngineDecommissioned = TRUE;
DECOMMISSION_PROCESSOR(cDiagChip, cDiagEngine);
}
Then it won't decommission any engines regardless. My firmware was slightly more conservative and made sure the engine returned at least one valid nonce. |
|
|
|
Is this hardware error target per module? If one module has 3% error, and the other 2 modules have 0% error, that would be fine. Total |
|
|
|
Hello ckolivas Great job! Everything is going great. I love the fix value for the fans speed! Let my 5 Avalon for a few hours on your donation pool! Many thanks Greetings from Switzerland Tinu PS: What I see is, "memory usage" in the "process status" is at 119%  Thanks, much appreciated hash donation! Memory usage on linux looks like that often as it includes all sorts of cached data as well as what's actually in use. It's of no major significance. |
|
|
|
Ugh... why is disabling wireless considered a fix? Wasn't wireless one of the selling points? It should just work.
Should? Yes. Does? No. Fail comes in all sorts of different forms in this world. This is another example of it. |
|
|
|
I am interested in trying my hand at creating yet another FPGA cluster hasher, with each cluster connected via a single USB connection to the host (rather than 1 per FPGA).
I've looked at the Cairnsmore 1, Ztex, and Icarus drivers; each one has hard-coded some of the idiosyncrasies of those particular devices. I'm wondering if there is something like a generic CGminer driver skeleton I could fill in / develop against.
Is there a simple block of code that easily links with CGminer, passes up the relevant info from the device chain (estimated duration of one hash-cycle iteration, number of hashes completed per cycle) to the main miner program on initialization, downloads base header data and range to be hashed against from the miner to the device with each getwork or stratum fetch, receives proof of work from the device to send to the mining pool, and sends an interrupt to the device when assigned work becomes invalid?
Given the proliferation of mining devices, there's almost a need for a "miner driver" specification just like the old "packet driver" specification back in the days of Win32s enabling Win3.11 to connect to the internet, so that the people creating the new mining devices would be responsible for driver creation, rather than the mining stack software creators.
Thanks,
-Tom
+1 Trying to do the same with an Arduino Leonardo acting as controller of several devices. Unfortunately we're not a committee nor a huge team with emphasis on infrastructure and frameworks. Kano and I do this in our spare time and the model keeps changing dynamically as we progress and each new device comes along with its own new set of issues. We work on what gets things done and we have hardware to play with or care about or get sponsored to work on. This is nothing more than a hobby/pastime/passion gone mad for us. That and I'm leaving to go overseas shortly for 6 weeks... |
|
|
|
As I am a little frightend to flash it right after it arrives, could I instead disconnect the wr703 and use a pi to test the overclockin so I have a fallback with the original firmware?
You can, but the new firmware doesn't overclock, it just gives you the ability to overclock if you desire... |
|
|
|
Minor mistake, it won't be going to maximum frequency by default. I will post another firmware shortly. I've reuploaded it. If you're flashing, this is the md5sum of the proper 20130701 firmware: a57305b42abe77d3335d44790e938d9e *openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory.bin just to be safe, the firmware is also for avalon batch #2 ? It is for all avalons. The settings you choose will depend on your hardware but default settings are safe on all of them. |
|
|
|
Minor mistake, it won't be going to maximum frequency by default. I will post another firmware shortly. Conman, Will you make a post reviewing all the extra commands and how they work. (When you have time of course.) I'm not sure of what all is available and the usage of each. If there's a separate readme that I missed just point me to it. Thanks. |
|
|
|
Minor mistake, it won't be going to maximum frequency by default. I will post another firmware shortly. I've reuploaded it. If you're flashing, this is the md5sum of the proper 20130701 firmware: a57305b42abe77d3335d44790e938d9e *openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory.bin |
|
|
|
when installing your firmware, should we always not check the "Keep Settings" box?
Actually you shouldn't need to do this except when you're changing from very old firmware that used the old serial interface as that might have had commands which are no longer valid. |
|
|
|
New avalon firmware: http://ck.kolivas.org/apps/cgminer/avalon/20130701/Changes: I've changed the default hardware error target with avalon-auto to a bit lower so it hovers closer to 1.2% instead of 1.8%. The hashrate increase of the higher error rate was marginal at best but I'd prefer a little more headroom so that auto can be left on. (Yes it will give slightly lower hashrates, if you don't like it then set a manual value!) Auto now will not raise the frequency if you are over the target temperature. Auto will try to drop the frequency to minimum if it has to idle the avalon due to overheat. New command line options: --avalon-fan <arg> Set fanspeed percentage for avalon, single value or range (default: 20-100) --avalon-freq <arg> Set frequency range for avalon-auto, single value or range These of course have to be added to the "More options" box in the web interface if you're not running cgminer directly. Note that if you give invalid options it will not start mining! |
|
|
|
i'm still not getting full "passthrough" of my hashrates from ckolivas (4th down) to ozcoin?
are my temps ok?:
Your temps are fine and the pools all use different algorithms to determine hashrate and fluctuate wildly especially with higher diffs so that looks about right (mine reports +/-20% at the pool usually). |
|
|
|
|
The firmware tests the engine (and chip if you have multiple chips) performance at startup and adjusts the speed accordingly based on how "correct" the answers are from each engine. It is not unusual for the existing Jals out there to be somewhere between 27 and 30 units when run at the higher speeds. 30 is the most that can be activated on 2+ chip units. When run at their lowest speed as 5GH units, most of the engines seem to work making all 30 start at 189MHz ~5.7GH. I posted firmware which relaxes the test dramatically making it far more likely to activate all 30 engines at speed setting "7" which is 274MHz, so 30 engines at 274 ~8.2 GH. I can't comment on the binned versus unbinned policy for chips by BFL but it looks like earlier units were unbinned making them potentially full speed, while later ones were chosen to reach the guaranteed speed as a minimum.
Unfortunately some of the hardware errors are currently counted towards the hashrate so you cannot simply look at the hashrate and determine whether you're creating all good work. I'm planning on rectifying that next cgminer version.
|
|
|
|
Cool guide. Got one for us Single owners? OH that's right only about 10 people have their Singles at this point so what's the point?
Don't rub it in  |
|
|
|
|
Most of them will be overloaded by hardware errors at speed 9. Most peoples' Jals will work best at 7 or 8.
|
|
|
|
|
Show Posts
