 Show Posts
|
|
Pages: [1] 2 »
|
|
i just had a bad experience w/sinosigma. legit seller but no commitment to shipping timeframe.
|
|
|
|
|
Hey all,
Just wanted to follow-up with a negative experience.
I placed an order on January 5 under the agreement (via private message) that they would ship an antminer within 10-15 days. They didn't. On Jan 20, watching antminer prices drop to 1.9 BTC here on the forums, i offered them the opportunity to still ship it to me expedited. They told me it would likely ship out Feb 9. I canceled my order with the reason "seller did not ship on time" and they refused to honor the cancellation, repeatedly reopening the order, until I changed my reason to "I ordered the wrong product". As of now I've changed the reason to that and they have still not processed the cancellation. If they don't by end of tomorrow (they probably will — their communication is good, just not their commitment to shipping) I'll just do a chargeback with VISA.
I'm sure lots of others had good experiences, but since I opened this thread I thought it's worth posting the outcome. Thanks.
|
|
|
|
Hey, I have a question about hardware errors. I have 3 BIF running under ubuntu / bfg 3.9 with 15 BEEs... The hardware issues are droping the performance, here is an extract after running for 22 hours. Any ideas whats up? Couldn't be temperature and it is plugged into a 10 port USB 3.0 hub with 7 BEEs... Had the same data when they were in the same hub with 3 BEEs. 3.9 % is okay IMO, but 11% and 15% are too high? Using default settings (no changes to the Oscillator bits). Thanks bfgminer version 3.9.0 - Started: [2014-01-06 16:02:04] - [ 0 days 22:04:57]
Connected to eu-stratum-lb489kj.btcguild.com diff 16 with stratum as user XXX
Block: ...ccf74b16 #279120 Diff:1.42G (10.15Ph/s) Started: [14:02:35]
ST:7 F:0 NB:178 AS:0 BW:[ 52/ 36 B/s] E:106.00 I: 292uBTC/hr BS:652k
18/21 56.8C | 23.17/21.64/19.75Gh/s | A:23027 R:133+0(.54%) HW:31035/7.8%
--------------------------------------------------------------------------------
.
.
.
BEE14: | 336.0/335.8/338.8Mh/s | A: 368 R: 0+0(none) HW: 21/.33%
BEE15: | 336.0/336.0/328.3Mh/s | A: 381 R: 1+0(.26%) HW: 36/.59%
BIF 0: 47.1C | 5.37/ 5.37/ 5.12Gh/s | A: 5997 R: 44+0(.68%) HW: 3907/3.9%
BIF 1: 55.6C | 5.63/ 5.62/ 4.95Gh/s | A: 5838 R: 36+0(.59%) HW:11259/ 11%
BIF 2: 56.8C | 5.59/ 5.59/ 4.68Gh/s | A: 5454 R: 32+0(.52%) HW:15431/ 15%
-------------------------------------------------------------------------------- How are you sure it isn't temperature? Mine is running >10º C less than that. Do you have any fans on the assembly? Before I put one on mine I had failures all the time. |
|
|
|
Hi all, http://www.aliexpress.com/store/534873There's a thread on here where many people suggest this person is a scammer. Then there are other threads that indicate others have bought product from them. Can anyone confirm or deny the legitimacy of this company? Wondering if I should cancel my order... |
|
|
|
OMG SUCCESS ON MAC! 4.8 Gh/s! I'm so excited  Ok, here's what you need to do. CScape it wouldn't hurt if you throw jedimstr and me some thanks ( cough another bifury cough) for debugging this for you and your mac users.  To update firmware on Mac:1. short the jumpers on your bi•fury and plug it in 2. Close all finder windows (just to be safe) 3. Open terminal, cd /Volumes/CRP\ DISABLD/4. rm firmware.bin5. curl -R -O --ssl http://c-scape.nl/bi-fury/firmware.bin (this downloads the firmware and leaves the modified date intact) 6. type diskutil list and note which disk# is used by CRP DISABLD, let's call this N (as in "diskN") 7. diskutil unmountDisk /dev/diskN where N is that # you just recorded 8. unplug and plug back in. The light will turn on then off again To get it running in cgminer now:1. sudo cgminer -o yourpool -u username -p pass — that's all, and thanks jedimstr for the sudo tip! To thank 303 and jedimstr for helping you303: BTC 1H9ygsQ19qfW6iEqc8irEPhzzd7tAMWzQn jedimstr: BTC 1Gh4jRoqQNodvwWd74Y3VbpNamYmvdhwTn Here's why downloading firmware on a mac and dragging it to the drive doesn't work: Mac OS X / Chrome download does two things that mess with the file: 1. Mac OS X adds extended attributes (xattr list firmware.bin) to the file, one of which is a quarantine check. 2. Mac OS X modifies the date of the file (I'm not sure if this messes with it, but everything seems to go smoothly when I adjust for this with -R in curl) What was happening was that the device didn't like this file and would overwrite it with its default firmware.bin, throwing us in a loop. I also add this instruction to our support site  Thank You again! Felipeo: Gladly! I updated my instructions to make sure the user unloads the USB modem drivers (for use with cgminer): sudo kextunload -b com.apple.driver.AppleUSBCDC sudo kextunload -b com.apple.driver.AppleUSBCDCACMData |
|
|
|
I would be nice if you can put a small switch on it instead of tweezers method.
just use a piece of tinfoil instead and hold it with your thumb while you plug it in. it's much easier. |
|
|
|
Thank you guys for help wit this MAC issue You will be rewarded sooooooooooo about this reward? should i be expecting a bifury in my mailbox this week? |
|
|
|
If anyone is looking for a good fan recommendation, the arctic breeze usb fan is keeping mine at a nice 42.3º C, 5.184Gh/s. Also I'm new to this, so perhaps you already all knew that and I'm late to the game. |
|
|
|
OMG SUCCESS ON MAC! 4.8 Gh/s! I'm so excited Ok, here's what you need to do. CScape it wouldn't hurt if you throw jedimstr and me some thanks ( cough another bifury cough) for debugging this for you and your mac users. To update firmware on Mac:1. short the jumpers on your bi•fury and plug it in 2. Close all finder windows (just to be safe) 3. Open terminal, cd /Volumes/CRP\ DISABLD/4. rm firmware.bin5. curl -R -O --ssl http://c-scape.nl/bi-fury/firmware.bin (this downloads the firmware and leaves the modified date intact) 6. type diskutil list and note which disk# is used by CRP DISABLD, let's call this N (as in "diskN") 7. diskutil unmountDisk /dev/diskN where N is that # you just recorded 8. unplug and plug back in. The light will turn on then off again Unload the kexts1. sudo kextunload -b com.apple.driver.AppleUSBCDC 2. sudo kextunload -b com.apple.driver.AppleUSBCDCACMData To get it running in cgminer now:1. sudo cgminer -o yourpool -u username -p pass — that's all, and thanks jedimstr for the sudo tip! To thank 303 and jedimstr for helping you303: BTC 1H9ygsQ19qfW6iEqc8irEPhzzd7tAMWzQn jedimstr: BTC 1Gh4jRoqQNodvwWd74Y3VbpNamYmvdhwTn Here's why downloading firmware on a mac and dragging it to the drive doesn't work: Mac OS X / Chrome download does two things that mess with the file: 1. Mac OS X adds extended attributes (xattr list firmware.bin) to the file, one of which is a quarantine check. 2. Mac OS X modifies the date of the file (I'm not sure if this messes with it, but everything seems to go smoothly when I adjust for this with -R in curl) What was happening was that the device didn't like this file and would overwrite it with its default firmware.bin, throwing us in a loop. Update: Jan 4: Unload the kexts
|
|
|
|
|
Thanks jedi. Sadly the reason I am asking questions here is that every email I send to the bifury dudes is met with a link pointing back to this thread.
--
Update: I figured it out! Update below...
|
|
|
|
I was able to finally get the Bi*Fury working on a Mac Pro using BFGMiner. To top it all off, I did it alongside 44 Block Erupters, a GPU (5770), and a Red Fury, all in the same instance of BFGMiner. There are two things that are key to getting this working (other than the already known need to kext load the Apple USB Modem drivers for the RedFury): 1. Use BFGMiner via sudo to bypass the permissions issues with the Bi*Fury. 2. Plugging the Bi*Fury and RedFury hot while loading each set of devices/drivers in succession while inside the App instead of all at once at the commandline or in the config. I loaded the Block Erupters and GPU on startup of BFGMiner. Then I plugged the Bi*Fury into the my hub and used M and + to scan for the Bi*Fury ( bifury:all). Then I plugged in the RedFury into the USB hub and did another scan for the RedFury ( bigpic:all). I know that the RedFury scans tend to mess up other devices and the Block Erupter scans tend to mess up RedFury, but by staggering the driver loads within the BFGMiner and hotplugging before each scan for the two Bitfury based devices, I was successful in getting all these guys working together!!! I may just stick with running it this way instead of separately on one of my dedicated RPi's because it seems somewhat unstable on the RPi. I had to go out to my mining room (separate garage room in the freezing cold) a few times today to hotplug the Bi*Fury into a hub because rebooting the Pi and restarting CGMiner didn't fix it, only unplugging/replugging worked with CGMiner on the Pi.  AWESOME! Thanks for the update. So you just ran bfgminer from CLI only specifying the pool address? Looking forward to trying this later tonight... |
|
|
|
OS: Mac OS X
Hardware: Bi•Fury ASIC
Has anyone successfully configured cgminer on Mac to see their Bi•Fury? If so, what did you do to get it recognized?
Thanks in advance.
Straight from README: OSX:
On OSX, like Linux, no drivers need to be installed. However some devices
like the bitfury USB sticks automatically load a driver thinking they're a
modem and the driver needs to be unloaded for cgminer to work:
sudo kextunload -b com.apple.driver.AppleUSBCDC
sudo kextunload -b com.apple.driver.AppleUSBCDCACMData
Saw that and did it...without any luck. Was wondering first if anyone will actually confirm they are running a Bi•fury on mac successfully...otherwise I'll send it back. |
|
|
|
Luckily it doesn't mess the Bifury up permanently... you just have to re-install the firmware and eject specifically from Windows for it to work again. I had a physical PC, but I have a feeling that a VM should work as well. Failing that, you COULD try compiling mtools on a mac and using the instructions earlier in the thread from cscape, but you have to use this configure line to get it working on the mac: Yeah, I already tried compiling mtools on mac. Configure works with that flag, but, it still fails with make. I'll wait until someone can lend me a PC this weekend I guess! No love on getting it to actually run on a mac though, even with unloading the USB modem drivers? |
|
|
|
|
OS: Mac OS X
Hardware: Bi•Fury ASIC
Has anyone successfully configured cgminer on Mac to see their Bi•Fury? If so, what did you do to get it recognized?
Thanks in advance.
|
|
|
|
|
jedimstr, thanks much for the help. would you consider posting an ls -al of your working drive? that way i can see if mac is changing permissions incorrectly or doing something else that is causing this to mess up.
OR
is simply putting this thing in drive mode causing the problem permanently?
|
|
|
|
|
Got it — I was reluctant to put a VM on my machine but I can for this. Overall though, your bi•fury still won't work, right?
|
|
|
|
|
mac fun follows...
- I had the same problem as jedimstr and have drive-bricked mine by trying to upgrade firmware. I do not have access to a PC. What now?
- Even after firmware, it appears nobody can get this to work on a Mac. Has anyone? Tips? It is recognized as a USB device (cgminer -n) but as a supported device.
- could you upload a recovery .iso for mac users to flash the drive with? perhaps that will work.
Thanks.
|
|
|
|
|
Just wanted to follow up to say that it took getting pissed publicly on Reddit to get some action, but BitInstant's CEO, Chris, did finally, personally drive my 3 BTC over in his virtual armored car to btc-e.com and put them in my account.
To new readers of this thread I would not recommend doing business with BI until we see a follow-up statement on bitinstant.com about this week's snafu and how they have learned from it. Not some shit buried away in a reddit thread or in this forum, but an actual postmortem and steps they are taking to address it. I commend these guys for handling an insane customer service load and probably getting very little sleep, but when you are dealing with people's money, and the word "instant" appears in your value proposition, you can't put users through this.
Thanks Charlie and Ursay. I appreciate your resolving the issue and adding the $ delta lost in the time I had to wait. That was a respectable gesture.
|
|
|
|
|
