hmmm... i read the readme's honest. I ran the aticonfig .... --initial thing. i did export DISPLAY=:0 as for "needing" the plug jumper(Dummy Plug), i figured doing it wouldn't hurt. If the aticonfig isn't the xorg thing you are talking about i'll go read it again. Is there anymore data that i can get ya that might help? I believe this should be working and am baffled that it isn't. This is what i did to dummy it: http://blog.zorinaq.com/?e=11Did you do aticonfig with "-f" as well? Try a different driver version? AMD are awesome at reinventing old bugs with newer drivers. |
|
|
|
con,
i've pointed my avalons with your firmware at my server to solo mine. will there be any performance issues that occur in that situation versus pool mining?
Provided you've set up pool software for your solo mining it's fine, however avalon+cgminer mining directly to bitcoind is a disaster. |
|
|
|
lets try this again i have two video cards installed. the primary one, a 7970, is in a PCIe X16 slot and mines fine. the second, is a 7950 in a PCIe X4 slot and cgminer doesn't see it as being enabled. aticonfig sees them both. i have a resistor in the 7950's DVI connector to dummy it. i loaded the latest catalyst package. Since cgminer mines fine on the one board i'm guessing that the SDK is loaded as part of catalyst? i'm using
cgminer-3.3.1-x86_64-built The MB conector on the X is a full connector and i'm on an extender,
aticonfig --lsa
* 0. 01:00.0 AMD Radeon HD 7900 Series
1. 04:00.0 AMD Radeon HD 7900 Series
* - Default adapter
./cgminer -n
[2013-07-02 14:19:59] CL Platform 0 vendor: Advanced Micro Devices, Inc.
[2013-07-02 14:19:59] CL Platform 0 name: AMD Accelerated Parallel Processing
[2013-07-02 14:19:59] CL Platform 0 version: OpenCL 1.2 AMD-APP (1084.4)
[2013-07-02 14:19:59] Platform 0 devices: 1
[2013-07-02 14:19:59] 0 Tahiti
[2013-07-02 14:19:59] Failed to ADL_Adapter_ID_Get. Error -10
[2013-07-02 14:19:59] This error says the device is not enabled
[2013-07-02 14:19:59] Failed to ADL_Adapter_ID_Get. Error -10
[2013-07-02 14:19:59] This error says the device is not enabled
[2013-07-02 14:19:59] GPU 0 AMD Radeon HD 7900 Series hardware monitoring enabled
[2013-07-02 14:19:59] 1 GPU devices max detected
[2013-07-02 14:19:59] USB all: found 7 devices - listing known devices
[2013-07-02 14:19:59] No known USB devices
As per the GPU-README... have you reconfigured xorg for the 2nd device? Have you exported the DISPLAY variable? Are you using a driver version that needs a dummy plug? etc.. |
|
|
|
How long do I have to wait till "avalon-auto" finds the optimal frequency? Or after what time I can say thats the optimal freq now to set locked?
It will usually continue to fluctuate indefinitely but you'll find it hovering +/-2 MHz, and that value's about the optimal. It will of course go lower if it starts getting too hot. Most seem to fall into two camps, close to 350 or close to 365. I run mine slightly lower than 350 since it seems to end up rebooting the router eventually at the highest setting (not cgminer but the whole hardware which is a little disconcerting). This is why I was experimenting with a less aggressive firmware yesterday, but in this world maximum hashrate seems to be the only thing that matters for most people... does --avalon auto require that default be left at 282? reason being, hashrate the other day wasn't going up as fast as i expected so i gave it a boost by changing default to 325 which obviously immediately jacked up the MH/s. everything seems ok since but should i not have done that and is it affecting the auto function? Nope. Whatever you want as starting speed. |
|
|
|
|
Start it from a command prompt rather than a batch file and you'll see something...
|
|
|
|
How long do I have to wait till "avalon-auto" finds the optimal frequency? Or after what time I can say thats the optimal freq now to set locked?
It will usually continue to fluctuate indefinitely but you'll find it hovering +/-2 MHz, and that value's about the optimal. It will of course go lower if it starts getting too hot. Most seem to fall into two camps, close to 350 or close to 365. I run mine slightly lower than 350 since it seems to end up rebooting the router eventually at the highest setting (not cgminer but the whole hardware which is a little disconcerting). This is why I was experimenting with a less aggressive firmware yesterday, but in this world maximum hashrate seems to be the only thing that matters for most people... |
|
|
|
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 |
|
|
|
|
Show Posts
