Sorry but that photo deserves to be shown again. It's truly beautiful. I can't wait to see it fully populated. (man that sounds dirty  ) Whose design work is that? is that you? or chipgeek? or both?? Also, are you planning to have the airflow moving from the chips towards the vrms? or the other way around? I'm curious to see which need more cooling, seeing as the hashrate seems to go up wrt voltage almost linearly, whereas it seems like you haven't even explored changing the clockrate, but now I'm babbling. Very exciting project. MrTeal did all of the schematic and board layout. I helped with MCU selection (different than BFL's MCU) and the general concept of what we wanted in the hardware. MrTeal did 100% of the voltage regulator selection and design. I wrote all of the firmware and I'm still making some major improvements over the next few days. (Details are expected to be announced next week.) We have experimented extensively with clock settings and changing voltage. We have a very good understanding of how that works. The VRM does generate quite a bit of heat. These newest boards have heavier copper layers to assist in cooling but some airflow will likely be a good idea. BTW - That photo is for 2 boards in a "panel". The assembly house prefers to make two boards at once. Then, after all components are mounted, the boards are snapped apart. |
|
|
|
|
I am also having problems with the worker charts since the new web site changes. When I click on a worker name, I get a blank graph. No points or curve plotted for "Income in BTC" and no points or curve for "Pool Hahsrate".
|
|
|
|
I recently moved my BFL FPGA from its own RPi over to the same RPi that I'm running my BFL ASIC (Jalapeno) on. I just noticed this message: cgminer version 3.3.1 - Started: [2013-08-02 13:40:59]
--------------------------------------------------------------------------------
(5s):8.193G (avg):8.459Gh/s | A:342 R:4 HW:1 WU:126.3/m
ST: 2 SS: 0 NB: 2 LW: 418 GF: 0 RF: 0
Connected to us1.eclipsemc.com diff 4 with stratum as user <user>
Block: 004d593153a097d8... Diff:31.3M Started: [13:43:03] Best share: 902
--------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
BAJ 0: max 34C 3.91V | 7.779G/7.754Gh/s | A:305 R:4 HW:1 WU:116.1/m
BFL 0: 52.6C | 874.9M/802.2Mh/s | A: 41 R:0 HW:0 WU: 11.5/m
--------------------------------------------------------------------------------
[2013-08-02 13:42:22] Accepted 198e49ab Diff 10/4 BAJ 0 pool 0
[2013-08-02 13:42:22] Accepted 0147e043 Diff 199/4 BAJ 0 pool 0
[2013-08-02 13:42:23] BFL0: took 20136ms - longer than 7000ms
[2013-08-02 13:42:23] Accepted 0455b72a Diff 59/4 BAJ 0 pool 0
[2013-08-02 13:42:26] Accepted 2d2ea71e Diff 5/4 BAJ 0 pool 0
Do I need to do anything about this? Is it really taking 20 seconds to do a work unit? Am I getting credit for these work units? Should I just put the FPGA back on its own RPi? (I know - "Stop mining with an FPGA" and I will when I need to ship it back for my SC Single - hopefully this month.) |
|
|
|
I would expect something like "-I /usr/include/libusb-1.0" in the compile command. Maybe you need to re-run ./configure?
Thank you. ./configure was the last bit of magic required. I finally got what I was looking for in the first place: [GetInfo] => DEVICE: BitFORCE SC 0x0a
FIRMWARE: 1.0.0 0x0a
MINIG SPEED: 7.85 GH/s 0x0a
PROCESSOR 3: 15 engines @ 259 MHz 0x0a
PROCESSOR 7: 15 engines @ 270 MHz 0x0a
ENGINES: 30 0x0a
FREQUENCY: 266 MHz 0x0a
XLINK MODE: MASTER 0x0a
CRITICAL TEMPERATURE: 0 0x0a
XLINK PRESENT: NO 0x0a
OK 0x0a 0x00
|
|
|
|
On debian-derived systems you can install the apt-file packages to allow search for packages that provide specific files. Your error message is about missing libusb.h. I'm not on a pi, but on my machine: $ apt-file search libusb.h
apcupsd-doc: /usr/share/doc/apcupsd/examples/libusb.h
libusb-1.0-0-dev: /usr/include/libusb-1.0/libusb.h
Thank you for your help, but I'm still stuck. (Full detail included here to help other noobs reading this.) pi@raspberrypi /usr/src/cgminer $ sudo apt-get install apt-file
[... lots of lines deleted here ...]
pi@raspberrypi /usr/src/cgminer $ apt-file search libusb.h
E: The cache is empty. You need to run 'apt-file update' first.
pi@raspberrypi /usr/src/cgminer $ apt-file update
apt-file is now using the user's cache directory.
If you want to switch back to the system-wide cache directory, run 'apt-file purge'
[... lots of lines deleted here ...]
pi@raspberrypi /usr/src/cgminer $ apt-file search libusb.h
apcupsd-doc: /usr/share/doc/apcupsd/examples/libusb.h
libusb-1.0-0-dev: /usr/include/libusb-1.0/libusb.h
pi@raspberrypi /usr/src/cgminer $ sudo apt-get install libusb-1.0-0-dev
Reading package lists... Done
[... lots of lines deleted here ...]
pi@raspberrypi /usr/src/cgminer $ gcc api-example.c -I compat/jansson -o cgminer-api
In file included from api-example.c:26:0:
miner.h:121:22: fatal error: libusb.h: No such file or directory
compilation terminated.
|
|
|
|
I'm running Raspbian on my RPi and got this error when trying to compile the api-example.c. pi@raspberrypi /usr/src/cgminer $ gcc api-example.c -I compat/jansson -o cgminer-api
In file included from api-example.c:26:0:
miner.h:121:22: fatal error: libusb.h: No such file or directory
compilation terminated.
pi@raspberrypi /usr/src/cgminer $ I had previously done: pi@raspberrypi /usr/src/cgminer $ sudo apt-get install build-essential git dh-autoreconf libcurl4-gnutls-dev libusb-1.0-0-dev libusb-dev libncurses-dev libudev-dev yasm screen
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'libncurses5-dev' instead of 'libncurses-dev'
build-essential is already the newest version.
dh-autoreconf is already the newest version.
git is already the newest version.
libcurl4-gnutls-dev is already the newest version.
libncurses5-dev is already the newest version.
libudev-dev is already the newest version.
libusb-1.0-0-dev is already the newest version.
libusb-dev is already the newest version.
screen is already the newest version.
yasm is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 31 not upgraded.
If anyone could help this linux noob, I'd appreciate it. BTW - I suspect the answer is: sudo apt-get install <something> but I have no idea what the something is. |
|
|
|
|
I had 2 machines on us1 and although they appeared to be hashing correctly, EMC web site reported that they were not hashing. Manually switching to us2 and us3 resolved the issue.
Does us1 have a problem?
|
|
|
|
I think it is a big, big mistake to:
use a big die
OR
use a big package
OR
use a multi-die package
How do I/we talk some sense into them?!??
I agree. @Bitcoinorama, (or anyone else) is there a way we can get more details on the die size, packaging method[1], type[2] and size? [1] - multi-chip vs. single, flipchip vs. wirebond, [2] - BGA, LGA, or board to board |
|
|
|
Run the 3.1.1 one above like you already are but add --usb BAS:0 so it will ignore the BFL SC's - the Jalapeno
Just curious, should that be "BAJ:0" instead of "BAS:0" or does "BA<any letter>" disable all BFL ASICs? Edit: Of course, where I said <any letter> I really meant the valid choices for BFL ASICs: [J | L | S | M ]. (Is it "M" for minirig?) |
|
|
|
|
Windows 64 bit version of bfgminer 3.1.0 never starts for me at all - it crashes back to command line immediately.
BFL's Easyminer (running bfgminer) seems to work fine.
|
|
|
|
Marcus: The die size will be...very large.
That sounds like trouble waiting to happen. I agree. This plus the lack of chip testing before mounting to the boards are the two things that concern me the most. Here's why: yield. There are two primary sources of yield loss (bad chips). 1) Process problems. Ex: Too much etching of metal (opens), not enough etching of metal (shorts), and similar issues with other layers (transistors and layer interconnects). These are usually noticed and/or fixed by the fab because they add test structures in between the chips in the scribe lanes and/or in unused areas of the chips. During each step of the wafer production, they test these test structures to make sure that that particular step was done right. If done wrong, the wafers are scrapped or sometimes the error can be corrected. However, there can be a uniformity issue where the die on one part of the wafer are good, while all the die in another area are bad. 2) Random defects - figuratively (sometimes literally) "specks of dust" on the wafers. Think of these this way. Imagine putting a piece of graph paper on the wall (representing the wafer and the small squares are the individual die) and throwing darts at it randomly. Lets say you throw 50 darts and the hole left by each dart represents a random defect. If the graph paper has small squares (1000 per sheet of paper), then you have 50 bad die, 950 good die for 95% yield of good die. Now imagine the squares (die) are 10x bigger so there are only 100 die per wafer. Now 50 defects gives 50 bad die and 50 good ones for 50% yield. Thus, larger die size impacts yield negatively. Realize the numbers here were chosen for simplicity but the effect is VERY real. Small die --> high yields --> no chip testing --> probably good. Large die --> low yields --> no chip testing --> not a good idea in my opinion. ORSoC is relying on the concept of using a large number of cores per chip and turning off the bad ones. The idea is that you can turn a bad die back into a good one. This is generally an acceptable strategy and one that BFL is successfully using. Depending on ORSoc's actual die size, the process yields, and the specific method of disabling cores, they might pull it off. However as someone else mentioned in this thread, there are sometimes chips that are COMPLETELY dead - just a shorted blob of metal and completely worthless unless you want something to blow up power supplies.  Those really should be screened out at a minimum. And if you're doing that, you might as well do a full chip test with binning. Note: I'm not condemning the strategy that ORSoc is using. It might work. I would be a whole lot more comfortable if they were doing chip testing. Disclaimer: I am a BFL customer. I have not ordered any KnC product yet but I am seriously considering it. If I had the cash on hand I might have already ordered. Perhaps BTC I mine with my BFL hardware will go to KnC. |
|
|
|
Under Windows 7 I've used zadig to replace the FTDI driver with the WinUSB driver. When I start cgminer, I get this:
snip
Yes it's a known about problem with slower USB/timeouts on some of the devices. There is a fix for this in the master git development tree, but no official release with it yet unfortunately. Hopefully soon... So is it the same issue in linux on my RPi or is the above a Windows only thing? If Windows only could you please look back a few replies? In the short term, I guess I'll try BFL's Easyminer. |
|
|
|
Under Windows 7 I've used zadig to replace the FTDI driver with the WinUSB driver. When I start cgminer, I get this: cgminer version 3.1.1 - Started: [2013-06-13 18:19:39]
--------------------------------------------------------------------------------
(5s):55.66M (avg):58.84Mh/s | A:0 R:0 HW:0 U:0.0/m WU:0.0/m
ST: 2 SS: 0 NB: 1 LW: 7 GF: 0 RF: 0
Connected to us1.eclipsemc.com diff 1 with stratum as user [username]
Block: 00f6d64abcfaeb79... Diff:15.6M Started: [18:19:39] Best share: 0
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: | 58.54M/61.84Mh/s | A:0 R:0 HW:0 U:0.00/m I: 3
--------------------------------------------------------------------------------
[2013-06-13 18:19:38] Started cgminer 3.1.1
[2013-06-13 18:19:38] BitForceSC detect (1:10) get details returned nothing (0:0)
[2013-06-13 18:19:38] Probing for an alive pool
[2013-06-13 18:19:39] Disabling extra threads due to dynamic mode.
[2013-06-13 18:19:39] Tune dynamic intensity with --gpu-dyninterval
[2013-06-13 18:19:39] Network diff set to 15.6M
[2013-06-13 18:19:40] Thread 1 being disabled
[2013-06-13 18:19:45] BitForceSC detect (1:10) get details return invalid/timed out (0:-7)
[2013-06-13 18:19:51] BitForceSC detect (1:10) get details return invalid/timed out (0:-7)
[2013-06-13 18:19:56] BitForceSC detect (1:10) get details return invalid/timed out (0:-7) |
|
|
|
Well since you tried with sudo, means its not the udev things. sudo has access to everything.
0403:6014 is the BFL ... so it is being seen by the system all right. Probably something with cgminer... I dont have a BFL so cant help beyond this...
Thank you. I'm going to try on Windows next - just to make sure the hardware is working. Of course I've now hit the USB thing that I need zadig for. Off to read more ASIC-README and do what it says... |
|
|
|
you need to restart udev after u added the rules for it to see it. hell just restart the pi for good measure.
does lsusb see the asic?
anything funky in dmesg|tail ?
first see if cgminer sees the new device with sudo . if sudo also doesnt work, then its not permission issue, something different.
Sorry - linux noob here. Thanks for your help. I did restart the pi - twice. My cgminer command line starts with: sudo /usr/src/cgminer/cgminer -o http://... pi@raspberrypi ~ $ lsusb
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 005: ID 0d3d:0001 Tangtop Technology Co., Ltd HID Keyboard
pi@raspberrypi ~ $ dmesg | tail
[ 11.224838] bcm2835 ALSA chip created!
[ 11.242032] bcm2835 ALSA chip created!
[ 11.258035] bcm2835 ALSA chip created!
[ 11.272962] bcm2835 ALSA chip created!
[ 11.288352] bcm2835 ALSA chip created!
[ 11.304921] bcm2835 ALSA chip created!
[ 15.854575] mmc0: missed completion of cmd 18 DMA (512/512 [1]/[1]) - ignoring it
[ 15.869959] mmc0: DMA IRQ 6 ignored - results were reset
[ 19.843212] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
[ 24.073821] Adding 102396k swap on /var/swap. Priority:-1 extents:1 across:102396k SS
pi@raspberrypi ~ $ |
|
|
|
Would it be; "All your Bitcoin are belong to us", or "All your Bitcoins are belong to us"?
It would be the singular, right? As 'base' was never plural...
Bitcoin. Edit: But possibly could be too nerdy for some. If they don't know about the "base belong to" thing, they might be paranoid that KnC will steal (some of) their coins. Or maybe not. Thank you for your effort and trip report. It was great to see the answers to my questions. I look forward to the rest. |
|
|
|
I'm cannot get my new BFL ASIC running on my RPi using cgminer 3.1.1. It has been hashing fine with my BFL FPGA up to now (and it still works if I plug back it in). I tried these commands from the ASIC-README. The second command was not required (it said the group already existed). sudo usermod -G plugdev -a `whoami`
sudo groupadd plugdev
sudo cp /usr/src/cgminer/01-cgminer.rules /etc/udev/rules.d/
[2013-06-13 16:52:30] Started cgminer 3.1.1
[2013-06-13 16:52:30] No devices detected!
[2013-06-13 16:52:30] Waiting for USB hotplug devices or press q to quit
[2013-06-13 16:52:30] Probing for an alive pool
I'm running in the default "pi" account. Can someone please give me some guidance where to look or what to do next? Thanks. |
|
|
|
|
I'm another happy customer of John's escrow service. Everything went perfectly smoothly and quickly.
Thank you John! I'll certainly use your service again in the future.
|
|
|
|
|
Bump. What happened to helveticoin?
An update would be nice. Even if it's only "all deals fell through, there will be no product".
|
|
|
|
STOP WITH SECTION 75. YOU ARE NOT COVERED.
Section 75 of the Consumer Credit Act 1974
KNCMINER binds you as a BUSINESS, NOT a consumer.
It doesn't work that way. The seller does not define who the buyer is. If you are a non-professional, a consumer, buying an item for personal use, you are covered as such. If you buy as a registered business, ie. "KS coins Inc", you are not. But KnC's terms & conditions force you to state you are not a consumer but are rather a business. What does that do to the law? (I really don't know so I'm asking, not trolling.) I was very pro-KnC in the beginning but I am becoming less so as the days go forward. What they did yesterday was a new low. 1) It appears that the Mars would cost more to produce than they were asking for it AND/OR the FGPA lead time was longer than the expected life of the product. This should have been apparent to ORSoC from the beginning. Project planning FAIL. 2) At the very least, they should allow customers to put $2800 "down" towards a Jupiter for each Mars that was ordered then pay the full amount when a working Jupiter is demonstrated. This is nearly what what was promised from the start minus Mars hardware delivered. (I'm looking at the risk to buyers perspective.) 3) The whole "lottery" thing of forcing people to pay full amount up front BEFORE the demo day is ...umm... BAD to out it politely. KnC's only plus is that the FPGA hardware does indeed look real. I'm am looking forward to the reports from the open house visitors. Before KnC gets any of my money (BTC or fiat), they need to restore some of their reputation by making it more clear how they will deliver working 28nm ASICs by September. |
|
|
|
|
Show Posts
