cypherdoc
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
January 22, 2014, 03:15:46 AM |
|
however, when i try to update bfgminer with: cd bfgminer && git pull && make && sudo make install && sudo shutdown -r now
i get this: error: Your local changes to the following files would be overwritten by merge: driver-bfsb.c Please, commit your changes or stash them before you can merge. Aborting
how can i fix this error? I had that problem back when I tried to update cgminer in minepeon. Kano used this as a solution back then: git checkout etc/miner.conf.donate git pull
So I am guessing (might be wrong) your solution might be something like this: cd bfgminer && git checkout driver-bfsb.c && git pull && make && sudo make install && sudo shutdown -r now worked great Morblias, thank you. my stratum connection is rock solid now and i'm continuing to tweek chip settings. Can you actually tune individual chips with MFG? does MFG = bfgminer? if so, not sure. i'm just broadly changing the 3 values in driver-bfsb.c
|
|
|
|
Doff
|
|
January 22, 2014, 03:17:21 AM |
|
Oops, yep. lol.
Meant BFG sorry.
|
|
|
|
bobcaticus
|
|
January 22, 2014, 04:46:36 AM |
|
Let's clear this up:
1) We use the same equipment in our mine. 2) The boards we sell to customers are the same ones pulled from the shipments we use for the above mentioned mine.
All RMAs go to me and Yvonne to troubleshoot and are NEVER used / re-wrapped, or sold back to customers. That's just not right.
|
|
|
|
Taugeran
|
|
January 22, 2014, 04:55:16 AM |
|
Oops, yep. lol.
Meant BFG sorry.
It shouldn't be terribly hard to add tuning of individual chips. Most of the code already exists. Would just need to keep an index of what chip is at what speed etc... Would try if I had the hardware but alas I do not
|
Bitfury HW & Habañero : 1.625Th/s tips/Donations: 1NoS89H3Mr6U5CmP4VwWzU2318JEMxHL1 Come join Coinbase
|
|
|
allinvain
Legendary
Offline
Activity: 3080
Merit: 1083
|
|
January 22, 2014, 06:40:58 AM |
|
Has anyone tried bfgminer on a v3 m-board. I was under the impression that it does not work with v3 m-boards and using it could even damage the cards/system. Any info on this?
that's what i'm using as described above with v2.2 h boards been running rock solid for +48hr now. totally solved my intermittent, random disconnects which was destroying my HR. I've tried bfgminer on v2.3 m-board but not on my v3. I will have to give it a try out of curiosity. If it was easier to tune the chips with bfgminer or if it remembered the speed settings for it's own auto-tuning system I'd switch over from chainminer. On a different note has anyone found that bitfury gear did not work well for them on the Eligius mining pool? In my case it seems that they are far more stable on btcguild. Could it be due to network connectivity. Maybe the stratum proxy submit queue is getting overloaded and hashrate is getting destroyed.
|
|
|
|
allinvain
Legendary
Offline
Activity: 3080
Merit: 1083
|
|
January 22, 2014, 06:42:12 AM |
|
however, when i try to update bfgminer with: cd bfgminer && git pull && make && sudo make install && sudo shutdown -r now
i get this: error: Your local changes to the following files would be overwritten by merge: driver-bfsb.c Please, commit your changes or stash them before you can merge. Aborting
how can i fix this error? I had that problem back when I tried to update cgminer in minepeon. Kano used this as a solution back then: git checkout etc/miner.conf.donate git pull
So I am guessing (might be wrong) your solution might be something like this: cd bfgminer && git checkout driver-bfsb.c && git pull && make && sudo make install && sudo shutdown -r now worked great Morblias, thank you. my stratum connection is rock solid now and i'm continuing to tweek chip settings. Can you actually tune individual chips with MFG? There is but it's not as userfriendly as editing the best.cnf or .stats.log as with chainminer.
|
|
|
|
cypherdoc
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
January 22, 2014, 08:40:07 AM |
|
however, when i try to update bfgminer with: cd bfgminer && git pull && make && sudo make install && sudo shutdown -r now
i get this: error: Your local changes to the following files would be overwritten by merge: driver-bfsb.c Please, commit your changes or stash them before you can merge. Aborting
how can i fix this error? I had that problem back when I tried to update cgminer in minepeon. Kano used this as a solution back then: git checkout etc/miner.conf.donate git pull
So I am guessing (might be wrong) your solution might be something like this: cd bfgminer && git checkout driver-bfsb.c && git pull && make && sudo make install && sudo shutdown -r now worked great Morblias, thank you. my stratum connection is rock solid now and i'm continuing to tweek chip settings. Can you actually tune individual chips with MFG? There is but it's not as userfriendly as editing the best.cnf or .stats.log as with chainminer. Care to elaborate?
|
|
|
|
Morblias
|
|
January 22, 2014, 03:07:05 PM |
|
On a different note has anyone found that bitfury gear did not work well for them on the Eligius mining pool? In my case it seems that they are far more stable on btcguild. Could it be due to network connectivity. Maybe the stratum proxy submit queue is getting overloaded and hashrate is getting destroyed.
I couldn't get my V1 to work correctly on eligius. I had to put it on btcguild for it to work. I am guessing it has something to do with the min difficulty and it overloading, because it starts up, goes to ~400gh/s (it runs at 500gh/s on btcguild), then starts to slowly drop and shoot out a shit load of errors. I tried leaving it going for 30 minutes and no luck. Would keep shooting out errors and sit around 50-100gh/s. I also have been too afraid of using bfgminer with the V1: v1 M-boards can be fried if the software doesn't compensate. I don't make any effort to compensate in BFGMiner. Nobody has tested it, but I cannot recommend this combination. Do so at your own risk...
Side note: I've never had problems with chainminer on Eligius... (via stratum proxy of course) O.o
|
Tips / Donations accepted: 1Morb18DsDHNEv6TeQXBdba872ZSpiK9fY
|
|
|
allinvain
Legendary
Offline
Activity: 3080
Merit: 1083
|
|
January 22, 2014, 03:45:38 PM |
|
On a different note has anyone found that bitfury gear did not work well for them on the Eligius mining pool? In my case it seems that they are far more stable on btcguild. Could it be due to network connectivity. Maybe the stratum proxy submit queue is getting overloaded and hashrate is getting destroyed.
I couldn't get my V1 to work correctly on eligius. I had to put it on btcguild for it to work. I am guessing it has something to do with the min difficulty and it overloading, because it starts up, goes to ~400gh/s (it runs at 500gh/s on btcguild), then starts to slowly drop and shoot out a shit load of errors. I tried leaving it going for 30 minutes and no luck. Would keep shooting out errors and sit around 50-100gh/s. I also have been too afraid of using bfgminer with the V1: v1 M-boards can be fried if the software doesn't compensate. I don't make any effort to compensate in BFGMiner. Nobody has tested it, but I cannot recommend this combination. Do so at your own risk...
Side note: I've never had problems with chainminer on Eligius... (via stratum proxy of course) O.o
That's the exact same thing I've noticed! Damn, so it must be something related to the min diff which supposedly Eligius automatically sets to the "optimal value" - this clearly is not correct. Moving them back to btcguild solved all my stability issues. This is quite sad as I would've like to move all my miners over to Eligius to save on the 3% fee - hey every bit matters these days especially for low hashing power miners like me.
|
|
|
|
allinvain
Legendary
Offline
Activity: 3080
Merit: 1083
|
|
January 22, 2014, 03:49:54 PM |
|
however, when i try to update bfgminer with: cd bfgminer && git pull && make && sudo make install && sudo shutdown -r now
i get this: error: Your local changes to the following files would be overwritten by merge: driver-bfsb.c Please, commit your changes or stash them before you can merge. Aborting
how can i fix this error? I had that problem back when I tried to update cgminer in minepeon. Kano used this as a solution back then: git checkout etc/miner.conf.donate git pull
So I am guessing (might be wrong) your solution might be something like this: cd bfgminer && git checkout driver-bfsb.c && git pull && make && sudo make install && sudo shutdown -r now worked great Morblias, thank you. my stratum connection is rock solid now and i'm continuing to tweek chip settings. Can you actually tune individual chips with MFG? There is but it's not as userfriendly as editing the best.cnf or .stats.log as with chainminer. Care to elaborate? It works the way described in this quote by punin. You essentially have to tell bfgminer at startup the speed for each individual chip. As you can see it can result in a very long command line argument (naturally you can script this by creating a shell script): <punin> compile with --enable-bitfury <punin> con is not going to make support for our hardware because it only runs on linux, pi and needs root access <punin> so this is as far as cgminer support will go from our side Sad <punin> ./cgminer --help <punin> --bitfury-board-type <arg> Bitfury board type, 0=i2c, 1=mboardv1, 2=mboardv2 (default: 0) <punin> --bitfury-options <arg> Set bitfury chip options chip:speed,chip.. eg. 0:55,1:56... default: ALL:54 <punin> old M-board probably doesn't work because no-one has tested it <punin> so use --bitfury-board-type 2
|
|
|
|
Keefe
|
|
January 22, 2014, 03:51:29 PM |
|
On a different note has anyone found that bitfury gear did not work well for them on the Eligius mining pool? In my case it seems that they are far more stable on btcguild. Could it be due to network connectivity. Maybe the stratum proxy submit queue is getting overloaded and hashrate is getting destroyed.
I couldn't get my V1 to work correctly on eligius. I had to put it on btcguild for it to work. I am guessing it has something to do with the min difficulty and it overloading, because it starts up, goes to ~400gh/s (it runs at 500gh/s on btcguild), then starts to slowly drop and shoot out a shit load of errors. I tried leaving it going for 30 minutes and no luck. Would keep shooting out errors and sit around 50-100gh/s. I also have been too afraid of using bfgminer with the V1: v1 M-boards can be fried if the software doesn't compensate. I don't make any effort to compensate in BFGMiner. Nobody has tested it, but I cannot recommend this combination. Do so at your own risk...
Side note: I've never had problems with chainminer on Eligius... (via stratum proxy of course) O.o
That's the exact same thing I've noticed! Damn, so it must be something related to the min diff which supposedly Eligius automatically sets to the "optimal value" - this clearly is not correct. Moving them back to btcguild solved all my stability issues. This is quite sad as I would've like to move all my miners over to Eligius to save on the 3% fee - hey every bit matters these days especially for low hashing power miners like me. It seems chainminer can't handle the share diff changing once started. Does BTCGuild let you set a fixed or min diff? You don't want the pool changing it on the fly, so you want to set a high enough min that the pool doesn't think it's necessary to change it. I think Eligius is fully auto so is no good for chainminer.
|
|
|
|
Morblias
|
|
January 22, 2014, 03:55:54 PM |
|
On a different note has anyone found that bitfury gear did not work well for them on the Eligius mining pool? In my case it seems that they are far more stable on btcguild. Could it be due to network connectivity. Maybe the stratum proxy submit queue is getting overloaded and hashrate is getting destroyed.
I couldn't get my V1 to work correctly on eligius. I had to put it on btcguild for it to work. I am guessing it has something to do with the min difficulty and it overloading, because it starts up, goes to ~400gh/s (it runs at 500gh/s on btcguild), then starts to slowly drop and shoot out a shit load of errors. I tried leaving it going for 30 minutes and no luck. Would keep shooting out errors and sit around 50-100gh/s. I also have been too afraid of using bfgminer with the V1: v1 M-boards can be fried if the software doesn't compensate. I don't make any effort to compensate in BFGMiner. Nobody has tested it, but I cannot recommend this combination. Do so at your own risk...
Side note: I've never had problems with chainminer on Eligius... (via stratum proxy of course) O.o
That's the exact same thing I've noticed! Damn, so it must be something related to the min diff which supposedly Eligius automatically sets to the "optimal value" - this clearly is not correct. Moving them back to btcguild solved all my stability issues. This is quite sad as I would've like to move all my miners over to Eligius to save on the 3% fee - hey every bit matters these days especially for low hashing power miners like me. It seems chainminer can't handle the share diff changing once started. Does BTCGuild let you set a fixed or min diff? You don't want the pool changing it on the fly, so you want to set a high enough min that the pool doesn't think it's necessary to change it. I think Eligius is fully auto so is no good for chainminer. Yeah I got my worker set at 512 min diff in btcguild and it works perfect. It also worked back in Giga's private pool where I manually set the worker min difficulty. Eligius doesn't have the option to manually set a difficulty and chainminer doesn't like that
|
Tips / Donations accepted: 1Morb18DsDHNEv6TeQXBdba872ZSpiK9fY
|
|
|
Taugeran
|
|
January 22, 2014, 05:35:03 PM |
|
On a different note has anyone found that bitfury gear did not work well for them on the Eligius mining pool? In my case it seems that they are far more stable on btcguild. Could it be due to network connectivity. Maybe the stratum proxy submit queue is getting overloaded and hashrate is getting destroyed.
I couldn't get my V1 to work correctly on eligius. I had to put it on btcguild for it to work. I am guessing it has something to do with the min difficulty and it overloading, because it starts up, goes to ~400gh/s (it runs at 500gh/s on btcguild), then starts to slowly drop and shoot out a shit load of errors. I tried leaving it going for 30 minutes and no luck. Would keep shooting out errors and sit around 50-100gh/s. I also have been too afraid of using bfgminer with the V1: v1 M-boards can be fried if the software doesn't compensate. I don't make any effort to compensate in BFGMiner. Nobody has tested it, but I cannot recommend this combination. Do so at your own risk...
Side note: I've never had problems with chainminer on Eligius... (via stratum proxy of course) O.o
That's the exact same thing I've noticed! Damn, so it must be something related to the min diff which supposedly Eligius automatically sets to the "optimal value" - this clearly is not correct. Moving them back to btcguild solved all my stability issues. This is quite sad as I would've like to move all my miners over to Eligius to save on the 3% fee - hey every bit matters these days especially for low hashing power miners like me. It seems chainminer can't handle the share diff changing once started. Does BTCGuild let you set a fixed or min diff? You don't want the pool changing it on the fly, so you want to set a high enough min that the pool doesn't think it's necessary to change it. I think Eligius is fully auto so is no good for chainminer. Yeah I got my worker set at 512 min diff in btcguild and it works perfect. It also worked back in Giga's private pool where I manually set the worker min difficulty. Eligius doesn't have the option to manually set a difficulty and chainminer doesn't like that solution: use bfgminer as the stratum proxy instead. it doesnt adjust downstream difficulty ( YET). only side effect is bfgminer will show a lot of clientside rejects of the sort (H-not-zero) or similar. this is basically chainimine submitting to bfgminer a metric carpton of too low shares
|
Bitfury HW & Habañero : 1.625Th/s tips/Donations: 1NoS89H3Mr6U5CmP4VwWzU2318JEMxHL1 Come join Coinbase
|
|
|
xzempt
|
|
January 22, 2014, 10:08:47 PM |
|
Let's clear this up:
1) We use the same equipment in our mine. 2) The boards we sell to customers are the same ones pulled from the shipments we use for the above mentioned mine.
All RMAs go to me and Yvonne to troubleshoot and are NEVER used / re-wrapped, or sold back to customers. That's just not right.
all my stuff from them was new! Very Happy! just not really generating enough heat to keep my basement warm like asicminer did.... i'll survive tho! thanks mbp... and Yvonne rocks!
|
|
|
|
stan258
|
|
January 23, 2014, 01:46:18 AM |
|
Got mine set up today. Easy to set up. They have good customer service.
Bank 1 1: 30.537GH/s 2: 30.723GH/s 3: 30.423GH/s 4: 31.153GH/s
|
|
|
|
salfter
|
|
January 23, 2014, 03:33:08 PM |
|
Has anyone tried bfgminer on a v3 m-board. I was under the impression that it does not work with v3 m-boards and using it could even damage the cards/system. Any info on this?
Runs like a champ for me. See here for instructions, or you can download a prebuilt image here. (For the image, default username and password are unchanged from stock; edit /home/pi/bfgminer.conf to set your pool credentials unless you want to mine for me. ) On a different note has anyone found that bitfury gear did not work well for them on the Eligius mining pool? In my case it seems that they are far more stable on btcguild. I switched to Eligius right before their recent troubles. I've not had any issues, and I think it's paying a little bit more than BTC Guild did. http://eligius.st/~wizkid057/newstats/userstats.php/1mineL5pWepg1WGKfDWDAFstQw4smUoFeWith six v3 H-boards, an AntMiner S1, and a couple of BFL Jalapeños, I'm getting about 375 GH/s. I'm waiting for more heatsinks to arrive before I order more H-boards; I came up one short on the boards I have right now. I've been buying these...they arrive here pretty quickly, and it only takes a few minutes to stick 17 of them on a board...one for each ASIC and one for the voltage regulator.
|
|
|
|
klondike_bar
Legendary
Offline
Activity: 2128
Merit: 1005
ASIC Wannabe
|
|
January 23, 2014, 04:39:53 PM |
|
you could be doing a bit better. 6 H-boards with some small pencil modding can give you ~34*6= 204GH + 197GH for an antminer running at 387.5Mhz = 401GH its worth squeezing a little more out while the difficulty is low
|
|
|
|
allinvain
Legendary
Offline
Activity: 3080
Merit: 1083
|
|
January 23, 2014, 05:06:36 PM |
|
Has anyone tried bfgminer on a v3 m-board. I was under the impression that it does not work with v3 m-boards and using it could even damage the cards/system. Any info on this?
Runs like a champ for me. See here for instructions, or you can download a prebuilt image here. (For the image, default username and password are unchanged from stock; edit /home/pi/bfgminer.conf to set your pool credentials unless you want to mine for me. ) On a different note has anyone found that bitfury gear did not work well for them on the Eligius mining pool? In my case it seems that they are far more stable on btcguild. I switched to Eligius right before their recent troubles. I've not had any issues, and I think it's paying a little bit more than BTC Guild did. http://eligius.st/~wizkid057/newstats/userstats.php/1mineL5pWepg1WGKfDWDAFstQw4smUoFeWith six v3 H-boards, an AntMiner S1, and a couple of BFL Jalapeños, I'm getting about 375 GH/s. I'm waiting for more heatsinks to arrive before I order more H-boards; I came up one short on the boards I have right now. I've been buying these...they arrive here pretty quickly, and it only takes a few minutes to stick 17 of them on a board...one for each ASIC and one for the voltage regulator. I dunno, I guess you got lucky with Eligius. I one the other hand noticed horrible drops in hashrate. My guess (like I mentioned before) is it has something to do with the way Eligius handles variable difficulty. With btc guild I set a manual minimum diff and it work very stable. I dunno, I guess my setup is a bit different as my rigs contain more cards (some 16 card rigs), so perhaps this issue manifests itself only when the work queue for the stratum proxy gets too high that the rpi can't handle it? Your guess is as good as mine. Now as for the heatsinks, I bought a bunch of those from that exact seller a while back I intend to get some more soon. They are very effective, but one top is if you're using one of Sportwood's cases make sure you attach the heatsinks that go at the top of the card a tiny bit lower so when you pull the card out or mount it in the m-board slot you don't run up against the board stabilizers.
|
|
|
|
Beans
|
|
January 23, 2014, 06:23:39 PM |
|
Is anyone else still waiting for a refund on the October batch?
Please shoot both me and Yvonne an email so we can get to the bottom of this. First time I'd heard of it. sales@ support@ Thanks, Jason I have still not received my refund from you guys or even heard from you in a couple weeks.
|
|
|
|
bobcaticus
|
|
January 23, 2014, 07:31:06 PM |
|
Is anyone else still waiting for a refund on the October batch?
Please shoot both me and Yvonne an email so we can get to the bottom of this. First time I'd heard of it. sales@ support@ Thanks, Jason I have still not received my refund from you guys or even heard from you in a couple weeks. I have sent you back several emails explaining that your case lies with Dave and Dave only.
|
|
|
|
|