 Show Posts
|
|
Pages: [1] 2 3 »
|
|
I made a major mistake and withdrew bitcoins from my deepbit to the wrong address. I have contacted the person who received the coins. When they return them will they go back to deepbit? Is the send address on my deepbit account unique so it's obvious whose account they came from?
|
|
|
|
|
The video cards were run underclocked/undervolted. The CM1s and the BFL singles are in perfect condition and were run at stock. Obviously btc payment, or paypal if you are in the USA lower 48.
Cairnsmore1 $500
5970 $250
5870 $120
|
|
|
|
Payments of initial deposits should be distributed as an even percentage to everyone as they arrive. No account should receive an amount greater than (total deposits - total withdrawals) before everyone's initial deposit is returned.
That's not possible. Some accounts have already withdrawn more than the total principal deposited. Yes, that person would have to wait for everyone's initial deposits to be returned before receiving any other payout. |
|
|
|
... withdraw requests from before pirate closed could be filled first >.>
Yes, but only of initial deposits. Otherwise you are essentially taking money from the other depositors. |
|
|
|
|
They will run cooler. The cases make them look nice but they trap in the heat.
|
|
|
|
ok...after 18 hours of testing, well short of the 48 hours I hoped for, here is my 190 bit stream findings;
System - Win 7 64bit, cgminer 2.6.1 + phatk, cm1 #62-0432 & #63-0433
Average hash rate per cm1 = ~725MHs at pool & via cgminer Note: neither board is reaching the bounty threshold of 750MHs
Average U = 17.5~17.8/m
HW & R are very low. HW = 0 & R <5
Maximum run time between failures (resulting in need for system reset to recover e.g BSD or non-responsive) - 14 hours
Minimum run time between failures (resulting in need for system reset to recover e.g BSD or non-responsive) - 0.5 hours
Average restarts of cgminer before both boards detect successfully - 3
Identified conflicts - use of 2nd 6770 GPU for mining causes system to BSD on start up of cgiminer or intedpendent start of of phoenix miner when cgminer is FPGA only. Note: Can mine on 1st 6770 GPU though.
I hope this helps developers...
Tweakers, any idea on how to tweak to get up to 750MHs and improve stability?
What are your per worker U values? U=17.5 on 2 boards looks like 1 fpga isn't hashing which is a common issue with that bitstream. |
|
|
|
I tried the 190 OC and it seems to be working on 2 of my FPGAs. 2 COM ports are detected (22,23 for me). The weird thing is see the LEDS light up on 4 of the FPGAs as work is found, but MPBM is only reporting work from 2 of the FPGAs.  Guess it's the same issue I have regardless of which bitstream I'm using. I'm only getting work from 2/4 of the FPGAs. Any help would be greatly appreciated. Thanks! You will only get work on 2 comms per board. The only way to analyze whether it's working is to look at the accepted jobs, U/m and what your pool reports. |
|
|
|
I tried on a different board with the same results. 140 makomk bitsteam works on fpga 0,3 just like twin_test. It
does not work on fpga 1,2. I double checked the comms. I can only think I'm making a procedure error.
For programming:
SW6 1 off, all else on
SW1 3 off, all else on
SW2,5 all on
SW3,4 2 off, all else on
For mining:
SW1 all on
no other changes
I think you need to program all 4, but only address 2 COM ports as it drives them as a pair in this mode. Am I wrong? I couldn't get this bitstream to work better than twin_test either. It either failed Icarus detect in CGminer or hashed too slow, or not at all. Yes, that's how it should work. You should get 280 mh/s per comm. 2 comms per board. The screenshot of the person I was quoting is a little misleading as it looks like he was trying to open 4 comms per board. I guess I don't know which fpga is actually doing the work of each pair, but it looks like the same situation as before as far as only 1 active fpga per comm channel. My 280 mh/s is composed of 140/140 as opposed to 280/0. It should be 280/280. |
|
|
|
|
I tried on a different board with the same results. 140 makomk bitsteam works on fpga 0,3 just like twin_test. It
does not work on fpga 1,2. I double checked the comms. I can only think I'm making a procedure error.
For programming:
SW6 1 off, all else on
SW1 3 off, all else on
SW2,5 all on
SW3,4 2 off, all else on
For mining:
SW1 all on
no other changes
|
|
|
|
Finally got MPBM working, using the Makomk's 140 Bitstream. Followed the settings, SW1 & 6 per the Twin Build Running settings. SW2-5 on low performance mode. Only 2 of my chips are mining right now. https://i.imgur.com/df6ne.jpgAny idea? The two that are hashing, don't have any issues. Board#171 This is my experience also. All 4 fpga positions produce the occasional green flash. Sometimes the 2 fpga positions next to each other produce a simultaneous very quick red flash. I've tried different setting for sw 2-5. None seem to make a difference to anything. |
|
|
|
|
You can also rename the files to x.bit and t.bit to save on repetitive typing.
|
|
|
|
I'm trying to get mpbm working on windows using windows-runtime-v0.1.0beta.zip and I get an error when trying to run mpbm.exe from the command line. I've never used mpbm before so I'm probably making a basic error.
Hey "this time", Please make sure you can type "python -h" as a command line. If yes you have to type "python run-mpbm.py" to start MPBM. If not you have to put the installation directory of python in the %PATH% variable and start a new command line window and try again. I have installed: - python 2.7.x - pyserial win32 (additional package) - pyusb win32 (additional package) - latest git mpbm (not 0.1.0beta!) If you need more help just PM me and I can help you also via skype in german  eb Thanks for the offer. I don't speak german, the german file reference was just part of the error. I've now got my boards going on mpbm. I couldn't figure what was causing that error and I wound up installing python 2.6 and the standard version of mpbm from github. |
|
|
|
I'm trying to get mpbm working on windows using windows-runtime-v0.1.0beta.zip and I get an error when trying to run mpbm.exe from the command line. I've never used mpbm before so I'm probably making a basic error.  |
|
|
|
Maybe he realized that there is no way to compete with BFL and wants to get a job there, by showing how 'smart' he is. Otherwise, he'd just make something better himself  As for Spartan solution - it is already fastest, and if yohan's prices for board combined with my bitstream price per Mh/s would be $0.53 / Mh/s for FPGA (1200 Mh/s for $640). This already beats BFL prices. If my licensing per-spartan would be applicable ($25 per chip) - then it would be 1200 Mh/s for $740 - $0.616 - again beats BFL. But - yohan prefers 840 Mh/s :-) While our capabilities do not allow to deploy quickly and cheap solutions. If you can do this, why not use the tricone model? Publish a bitstream for cairnsmore that extracts a commission and go straight to the end user. Every single person would use it. You could direct 200mh/s? to yourself and make your goal of $25/chip in no time. There are hundreds of these ready to go. |
|
|
|
I can't answer that and nether can you with exact to the right numbers and dates. Thus your guess or generaliztion is inaccurate. What I do know is enough orders have been filled to satisfy me.
I will agree that preordering from such a small company is a big risk.
My generalization is inaccurate? Tell that to the list of people that haven't received their orders yet. I know that isn't everyone, but how likely is it that everyone but the people that have listed their order info on the list have received their hardware? I think its far more likely that things just aren't shipping. Presumably, the money is being saved up to start the asic process which will have to be spent in one large chunk. After that hurdle, new money for orders will go towards filling the old orders. |
|
|
|
yeah, even more for those out of the US... i'd never in my life purchase a single from a reseller at this point in the US, and even more so if I was located outside the US...
It's often a much better deal for those outside the US. All but one of the few singles I've sold have gone abroad because the actual shipping is lower than bfl's charge and there is no VAT. |
|
|
|
|
Which board? Assuming each quad is spartan based at 40w, you can run 6 off each pcie. Just make an adapter, or chop and solder.
|
|
|
|
|
If anyone is actually considering cancelling, I will take your place in line.
|
|
|
|
I had similar issues with cgminer. Try version 2.3.6. |
|
|
|
|
