Show Posts
|
Pages: « 1 [2]
|
Hi all. Just got my Gridseed 5-chip "orbit" in the mail. Attempting to use it with Mac OS X. I've followed nwoolls's blog article and even loaded the FTDI kext driver. No matter what, the Gridseed keeps showing up as: [2014-03-31 10:29:02] lowlevel_scan: Found vcom device at dev_t:0d000012 (path=/dev/cu.usbmodemfa14141, vid=0000, pid=0000, manuf=(null), prod=(null), serial=(null))
Can I still mine? How do I tell bfgminer to use this device?
|
|
|
You could just re-clone it into a different directory. I personally find git to be a major pain in the ass and the best solution (like Windows) is just to erase and start over with a fresh copy.
|
|
|
I dunno, sounded right to me so I went with it... I'd love to just run one proxy though as it will simplify things... Maybe it's splitting hairs and only a small improvement?
I can only speak to my personal 1st hand experience. I run 1 instance of slush's proxy, pointed to BTCGuild, and all 3 cubes show as independent workers. Also, all 3 cubes can handle the same difficulty so whatever the OP of that page was referring to about difficulties is a moot point for me. I believe the latest version of slush's proxy has a flag for propagating difficulties so if that's of need to you (like you run cubes and other hardware that's not as powerful), you might want to test that. But if you are cube-only, you should be fine with just one instance of proxy running.
|
|
|
...and they are all running through Slush's proxy (one for each, different ports) on an older laptop.
Why are you running separate instances of the proxy? You should only be running 1 instance of the proxy for any number of cubes. I have 3 cubes and 1 instance of the proxy and I get >32GHs on all 3 cubes. Regarding running slush's proxy on RPi. I haven't seen anyone reporting more than 1 cube on an RPi getting full hashing rate. I tried my 3 cubes on RPi and it pegged the cpu 100% and hash rates were < 16GHs. I have not yet tried bfgminer proxy on RPi. I might get around to trying that tomorrow.
|
|
|
Hello all, I have just bought my 1st Asic Cube, i have it setup and running the proxy (on my windows PC)as per descriptions on here, all good so far! but i would like to run in with my Rasp Pi, i have configured the proxy from slush and everything connects ok and the cube starts to run now, my Pis CPU goes to 100% and stays there, and only half the cubes processors run and its producing around 15gh max, can anyone help with this? i have tried to use bfgminer but this simply will not connect! any ideas as i know people are running 4/5 cubes from there pis.
Thanks Steve
Hey Steve, I tried running slush's proxy on RPi Model B and I was only able to get 1 cube running at max hashrate. 3 cubes pegged the RPi cpu and hashrates for each cube were around 12-15GHs. I happen to have a ReadyNAS with an Intel ATOM that is running slush's proxy and uses about 20-30% cpu but all cubes are >32GHs. You say the bfgminer proxy is better? Since it compiles to C, I'll have to give that a try on RPi.
|
|
|
Recent version of cgminer supports the nanofury. So the patch should not be needed. Does it not work on the raspberry?
Hey rgr_rgr, No, the latest version of cgminer does not detect nanofury/YJ on RaspberryPi. bfgminer does but requires hidapi which reports hardware errors. The patch I merged allows cgminer to detect NF/YJ without hidapi. I'm getting 0 hardware errors and hash rates faster than bfgminer on my MacBookPro.
|
|
|
By the way I think Con did incorporate exactly those changes into the mainstream cgminer (I think as of version 3.11 everything should be stable, he also added a speed override option)
Hrmm. I didn't see any references to this patch in the main branch, which is why I created my fork ( https://github.com/utdrmac/cgminer). If I clone ckolivas's main branch, and compile, I have to use hidapi and I get hardware errors or I get no detection of NFY at all. Using my fork, with the patch from technobit, there's no need for hidapi (known to be cumbersome with RPis), YellowJackets are detected, run more efficiently and produce 0 hardware errors.
|
|
|
After struggling for days/weeks in getting my RaspberryPi to work properly with 2 YellowJacket I have finally succeeded. I was using bfgminer but experienced the "Detected 50% Frequency Drop" constantly. I then found another post about a patch created by Technobit against cgminer. But this was an old version of cgminer and I wanted to use the latest. So I forked cgminer and tediously applied the patch against the master branch. You can clone my repo from here: https://github.com/utdrmac/cgminerMy pull request for merging back in to main cgminer: https://github.com/ckolivas/cgminer/pull/541The follow steps were done on a fresh install of a model B RaspberryPi with Raspian. - sudo apt-get update
- sudo apt-get upgrade
- sudo apt-get install screen autoconf automake autotools-dev libtool libevent uthash-dev libjansson-dev libcurl-dev libcurl4-openssl-dev libncurses5-dev libncursesw5-dev # Not all may be necessary. I just scrolled through my history.
- git clone https://github.com/utdrmac/cgminer
- cd cgminer
- ./autogen.sh --enable-hexmineru
- make
- sudo make install
- screen
- sudo cgminer -c /home/pi/.cgminer/cgminer.conf
Let me know if it works for you! I'm actually getting better hashrate than with bfgminer. Tips Appreciated: 1 drmacW6UYAfHNjRrxN7SYuN3Q9R9v6K6
|
|
|
Success! Perfect! RaspberryPI Model B. 2 YellowJacket NanoFury's (powered hub required)! 2.2-2.5GHs each! No more 50% frequency errors! Why doesn't master branch of cgminer have this patch included?
|
|
|
I tried running stratum-mining-proxy on my RaspberryPi. I pointed 2 ASIC Block Erupter Cubes to it and CPU pegged at 98%. Never got hash rates above 27GHs. As opposed to when I run proxy on my MacBookPro, consistently over 32GHs. Seems the RPi is underpowered to handle that much computation that fast. Suggestions? Others with similar experience?
|
|
|
Hey all, So I compiled stratum-mining-proxy on my RaspberryPi just fine. Ran into a couple of issues with bad python but was able to patch it with a couple pull requests. Problem is, I pointed two ASIC Block Erupter Cubes to the Pi proxy and CPU pegged at 99%. Neither cube was able to get higher than 28GHs. When I run the proxy on my MacBookPro, all three of my cubes reach 32GHs easy. It doesn't look like the Pi will be able to handle all that computation. Need to start looking for alternative to host the proxy.
|
|
|
Does anyone know if there is there a way for me to "sell" my GHs as a commodity on CEX.IO and turn a faster profit than pool mining?
|
|
|
I'd say no it cannot for two reasons. 1) Each cube needs 2 PCIe power adapters. Your power supply only comes with 2. So you can only power 1 cube with this, not 2 cubes. You'd need 4 PCIe power adapters coming from the PSU. 2) Each cube uses 400W at baseline. Overclocking will require about 450. Your power supply is only 650. I purchased two Corsair AX850's refurb from local electronics store for $108 each. Both come with 4 PCIe cables so I am powering 4 cubes with 2 PSUs. Non-overclocked, getting about 32GHs each.
|
|
|
Hi all, I just purchased my first 3 ASIC Block Erupters (the black boxes) and have a curiosity question about cloud-hasing. I'm getting a constant 96GHs with my 3 BlockErupters. I paid $1,830 for all three devices. Thus, my $USD/GHs is $19.
Currently on cex.io, 1GHs is 0.044012BTC. So my 96GHs translates to 4.225152BTC which, converted just now on preev.com, is $3,374.
So, doesn't that make it still cheaper/more economical to own your own hardware vs investing in a GHs commodity?
In the end, why would I spend $3,374 on cex.io to purchase 96GHs when I can spend a little over half of that and run my own hardware?
Cheers!
|
|
|
Hello all, Just got two of these today. Powered by a Corsair AX850 ($109 refurb Fry's). Everywhere I read, the USB port is for firmware upgrades. But what I can't find out is if there are any upgrades for my unit. Are there any? What's the manuf website where this would be posted if one came out?
|
|
|
|