[ANN] US/North American Bitfury sales NEW STOCK ***NOW SHIPPING*** - page 16.

xzempt

hero member

Activity: 504

Merit: 500

Quote from: bobcaticus on January 21, 2014, 11:46:36 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!

Taugeran

hero member

Activity: 658

Merit: 500

CCNA: There i fixed the internet.

Quote from: Morblias on January 22, 2014, 10:55:54 AM

Quote from: Keefe on January 22, 2014, 10:51:29 AM

Quote from: allinvain on January 22, 2014, 10:45:38 AM

Quote from: Morblias on January 22, 2014, 10:07:05 AM

Quote from: allinvain on January 22, 2014, 01:40:58 AM

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:

Quote from: Luke-Jr on November 14, 2013, 01:17:13 PM

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 Sad

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

Morblias

hero member

Activity: 576

Merit: 500

Quote from: Keefe on January 22, 2014, 10:51:29 AM

Quote from: allinvain on January 22, 2014, 10:45:38 AM

Quote from: Morblias on January 22, 2014, 10:07:05 AM

Quote from: allinvain on January 22, 2014, 01:40:58 AM

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:

Quote from: Luke-Jr on November 14, 2013, 01:17:13 PM

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 Sad

Keefe

hero member

Activity: 681

Merit: 500

Quote from: allinvain on January 22, 2014, 10:45:38 AM

Quote from: Morblias on January 22, 2014, 10:07:05 AM

Quote from: allinvain on January 22, 2014, 01:40:58 AM

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:

Quote from: Luke-Jr on November 14, 2013, 01:17:13 PM

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.

allinvain

legendary

Activity: 3080

Merit: 1083

Quote from: cypherdoc on January 22, 2014, 03:40:07 AM

Quote from: allinvain on January 22, 2014, 01:42:12 AM

Quote from: Doff on January 21, 2014, 10:06:21 PM

Quote from: cypherdoc on January 21, 2014, 04:02:59 PM

Quote from: Morblias on January 21, 2014, 01:04:25 PM

Quote from: cypherdoc on January 21, 2014, 11:28:27 AM

however, when i try to update bfgminer with:

Code:

cd bfgminer && git pull && make && sudo make install && sudo shutdown -r now

i get this:

Code:

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:

Quote from: kano on August 16, 2013, 07:04:11 PM

git checkout etc/miner.conf.donate
git pull

So I am guessing (might be wrong) your solution might be something like this:

Code:

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):

Quote

compile with --enable-bitfury
con is not going to make support for our hardware because it only runs on linux, pi and needs root access
so this is as far as cgminer support will go from our side Sad
./cgminer --help
--bitfury-board-type Bitfury board type, 0=i2c, 1=mboardv1, 2=mboardv2 (default: 0)
--bitfury-options Set bitfury chip options chip:speed,chip.. eg. 0:55,1:56... default: ALL:54
old M-board probably doesn't work because no-one has tested it
so use --bitfury-board-type 2

allinvain

legendary

Activity: 3080

Merit: 1083

Quote from: Morblias on January 22, 2014, 10:07:05 AM

Quote from: allinvain on January 22, 2014, 01:40:58 AM

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:

Quote from: Luke-Jr on November 14, 2013, 01:17:13 PM

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.

Morblias

hero member

Activity: 576

Merit: 500

Quote from: allinvain on January 22, 2014, 01:40:58 AM

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:

Quote from: Luke-Jr on November 14, 2013, 01:17:13 PM

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

cypherdoc

legendary

Activity: 1764

Merit: 1002

Quote from: allinvain on January 22, 2014, 01:42:12 AM

Quote from: Doff on January 21, 2014, 10:06:21 PM

Quote from: cypherdoc on January 21, 2014, 04:02:59 PM

Quote from: Morblias on January 21, 2014, 01:04:25 PM

Quote from: cypherdoc on January 21, 2014, 11:28:27 AM

however, when i try to update bfgminer with:

Code:

cd bfgminer && git pull && make && sudo make install && sudo shutdown -r now

i get this:

Code:

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:

Quote from: kano on August 16, 2013, 07:04:11 PM

git checkout etc/miner.conf.donate
git pull

So I am guessing (might be wrong) your solution might be something like this:

Code:

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?

allinvain

legendary

Activity: 3080

Merit: 1083

Quote from: Doff on January 21, 2014, 10:06:21 PM

Quote from: cypherdoc on January 21, 2014, 04:02:59 PM

Quote from: Morblias on January 21, 2014, 01:04:25 PM

Quote from: cypherdoc on January 21, 2014, 11:28:27 AM

however, when i try to update bfgminer with:

Code:

cd bfgminer && git pull && make && sudo make install && sudo shutdown -r now

i get this:

Code:

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:

Quote from: kano on August 16, 2013, 07:04:11 PM

git checkout etc/miner.conf.donate
git pull

So I am guessing (might be wrong) your solution might be something like this:

Code:

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.

allinvain

legendary

Activity: 3080

Merit: 1083

Quote from: cypherdoc on January 21, 2014, 06:42:01 PM

Quote from: allinvain on January 21, 2014, 06:39:41 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?

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.

Taugeran

hero member

Activity: 658

Merit: 500

CCNA: There i fixed the internet.

Quote from: Doff on January 21, 2014, 10:17:21 PM

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

bobcaticus

hero member

Activity: 553

Merit: 500

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.

Doff

sr. member

Activity: 327

Merit: 250

Oops, yep. lol.

Meant BFG sorry.

cypherdoc

legendary

Activity: 1764

Merit: 1002

Quote from: Doff on January 21, 2014, 10:06:21 PM

Quote from: cypherdoc on January 21, 2014, 04:02:59 PM

Quote from: Morblias on January 21, 2014, 01:04:25 PM

Quote from: cypherdoc on January 21, 2014, 11:28:27 AM

however, when i try to update bfgminer with:

Code:

cd bfgminer && git pull && make && sudo make install && sudo shutdown -r now

i get this:

Code:

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:

Quote from: kano on August 16, 2013, 07:04:11 PM

git checkout etc/miner.conf.donate
git pull

So I am guessing (might be wrong) your solution might be something like this:

Code:

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

sr. member

Activity: 327

Merit: 250

Quote from: cypherdoc on January 21, 2014, 04:02:59 PM

Quote from: Morblias on January 21, 2014, 01:04:25 PM

Quote from: cypherdoc on January 21, 2014, 11:28:27 AM

however, when i try to update bfgminer with:

Code:

cd bfgminer && git pull && make && sudo make install && sudo shutdown -r now

i get this:

Code:

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:

Quote from: kano on August 16, 2013, 07:04:11 PM

git checkout etc/miner.conf.donate
git pull

So I am guessing (might be wrong) your solution might be something like this:

Code:

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?

cypherdoc

legendary

Activity: 1764

Merit: 1002

Quote from: allinvain on January 21, 2014, 06:39:41 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?

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.

allinvain

legendary

Activity: 3080

Merit: 1083

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?

allinvain

legendary

Activity: 3080

Merit: 1083

Quote from: Keefe on January 21, 2014, 05:59:40 PM

Quote from: kendog77 on January 21, 2014, 05:17:54 PM

Quote from: xstr8guy on January 21, 2014, 05:08:51 PM

Quote from: superduh on January 21, 2014, 04:26:07 PM

Quote from: Trongersoll on January 21, 2014, 04:22:00 PM

Quote from: superduh on January 21, 2014, 04:20:38 PM

price target of $150 by end of month before people will actually start buying the hcards.
otherwise the whole inventory will be worth close to $0

How do you know people aren't buying?

they have a live inventory counter. they've sold about 200 h cards in dec/jan and still have about 1800 available in inventory.
it makes no financial sense to buy them with either bitcoins or USD

They constantly add to the inventory so you would have no idea how much they are selling.

Also, their inventory is constantly earning BTC, so I'm sure they are in no hurry to sell it for less than they think it will earn.

If they're not hashing with their inventory, it's really a shame. All that inventory sitting on shelves loses 16% of its value per week. Personally I don't mind at all if they are selling used (tested) hardware. That's only a problem in a pre-order scenario where doing so delays delivery of hardware paid for in advance. That said, my guess is they're not mining with their inventory, unfortunately for everyone since they might be more inclined to lower prices if it didn't feel like a loss to do so.

I would be very surprised if they were not mining with the inventory. If I had to guess I'd say they are just pulling the cards/rigs from their live farm as customer orders come through. They may have a bunch of brand new cards in stock too that they may throw in once in a while.

Either way we are all just speculating and we can never know for sure until we hear from MBP.

Like you I really don't care if they used the cards as long as they are not offloading troublesome cards on to us.

allinvain

legendary

Activity: 3080

Merit: 1083

Quote from: Trongersoll on January 21, 2014, 05:22:19 PM

Quote from: kendog77 on January 21, 2014, 05:17:54 PM

Quote from: xstr8guy on January 21, 2014, 05:08:51 PM

Quote from: superduh on January 21, 2014, 04:26:07 PM

Quote from: Trongersoll on January 21, 2014, 04:22:00 PM

Quote from: superduh on January 21, 2014, 04:20:38 PM

price target of $150 by end of month before people will actually start buying the hcards.
otherwise the whole inventory will be worth close to $0

How do you know people aren't buying?

they have a live inventory counter. they've sold about 200 h cards in dec/jan and still have about 1800 available in inventory.
it makes no financial sense to buy them with either bitcoins or USD

They constantly add to the inventory so you would have no idea how much they are selling.

Also, their inventory is constantly earning BTC, so I'm sure they are in no hurry to sell it for less than they think it will earn.

I don't think this is true. My recent purchase have all come sealed in ESD bags. So unless they went to the trouble of buying new bags and a sealer just to hide that they are using the cards, i suspect that your statement is just speculation presented as fact. and possibly Libel.

Maybe YOUR cards all came in sealed ESD bags, but my order came in a mixed combination of sealed and non sealed (ie just tape to close the edb bag). In fact the majority of the cards I got were not fully sealed. I bet you anything others got cards that were not fully sealed too.

Keefe

hero member

Activity: 681

Merit: 500

Quote from: kendog77 on January 21, 2014, 05:17:54 PM

Quote from: xstr8guy on January 21, 2014, 05:08:51 PM

Quote from: superduh on January 21, 2014, 04:26:07 PM

Quote from: Trongersoll on January 21, 2014, 04:22:00 PM

Quote from: superduh on January 21, 2014, 04:20:38 PM

price target of $150 by end of month before people will actually start buying the hcards.
otherwise the whole inventory will be worth close to $0

How do you know people aren't buying?

they have a live inventory counter. they've sold about 200 h cards in dec/jan and still have about 1800 available in inventory.
it makes no financial sense to buy them with either bitcoins or USD

They constantly add to the inventory so you would have no idea how much they are selling.

Also, their inventory is constantly earning BTC, so I'm sure they are in no hurry to sell it for less than they think it will earn.

If they're not hashing with their inventory, it's really a shame. All that inventory sitting on shelves loses 16% of its value per week. Personally I don't mind at all if they are selling used (tested) hardware. That's only a problem in a pre-order scenario where doing so delays delivery of hardware paid for in advance. That said, my guess is they're not mining with their inventory, unfortunately for everyone since they might be more inclined to lower prices if it didn't feel like a loss to do so.

Topic: [ANN] US/North American Bitfury sales NEW STOCK ***NOW SHIPPING*** - page 16. (Read 576801 times)

Topic: [ANN] US/North American Bitfury sales NEW STOCK NOW SHIPPING - page 16. (Read 576801 times)