[ANN] US/North American Bitfury sales NEW STOCK ***NOW SHIPPING***

[Trongersoll]

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.

[Keefe]

At the moment, I would pay $225/card for Feb 1 delivery, or $285/card for Jan 23 delivery. That's mostly based on the current value of BTC, so will change if the exchange rate goes up. It would need to get up to $1020/BTC by tomorrow to make it worth buying a 14-card v3 rig for $5100 (1/4 rig plus 10 more discounted cards).

[Keefe]

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.

[allinvain]

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.

[allinvain]

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]

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?

[cypherdoc]

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.

[Doff]

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:

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]

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:

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]

Oops, yep. lol.

Meant BFG sorry.

[bobcaticus]

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]

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

[allinvain]

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]

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:

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.

[cypherdoc]

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:

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?

[Morblias]

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

[allinvain]

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]

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:

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

<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]

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]

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