silverston
|
|
May 25, 2013, 05:10:59 PM |
|
if it's with a dynamic clocking firmware, I'd expect it would have downclocked a bit. I do not know what there the firmware. I bought it for second hand and I have no idea how and what to see
|
|
|
|
gyverlb
|
|
May 25, 2013, 05:19:14 PM |
|
if it's with a dynamic clocking firmware, I'd expect it would have downclocked a bit. I do not know what there the firmware. I bought it for second hand and I have no idea how and what to see You probably don't have dynamic clocking firmware. With it you would have one device per FPGA hashing around 200MH/s each. You have one per pair of FPGA hashing at ~400MH/s each. Your hardware errors are a bit on the high side (4% for the worst case) but is not really worrying. Using a slower firmware is nearly always advisable when you have more than 5% hardware errors. The best results are delivered with the dynamic clocking firmware as it can even adapt to changing conditions leading to less hardware errors (it can use faster clocks if the cooling improves and make some FPGAs more stable because a window was opened for example) but the difference might not be worth the downtime (IIRC you need quite some time flashing both the controller and each of your FPGAs). To make it short: unless you see less than 400MH/s on average per pair of FPGA over long periods of time or something isn't stable there isn't much of a reason to change firmwares (unless you like to hack around).
|
|
|
|
SnitraM
Newbie
Offline
Activity: 40
Merit: 0
|
|
May 27, 2013, 02:40:53 PM |
|
However, if your CMR is FT232H product=0x6014 (gingernuts is product=0x8350) it would be good to provide 2 things: usbmon (or direct access to it via /sys or /proc or /dev or wherever your Linux OS puts it - yes it must be Linux) output of plugging it in and also running the usbtest.py that comes with cgminer current git like: ./usbtest.py /dev/ttyUSB? icarus (whatever the USB? is) and make sure it gave the right answers (or rerun it) and lsusb -v of the device If it actually creates multiple /dev/ttyUSB? you'll need to run that whole process on each of them (from plug in to usbtest.py)
Is it important for your tests to have product=0x6014 or product=0x8350? I don't know which one I have but my Cairnsmores are early ones, from summer 2012.
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
May 27, 2013, 02:50:23 PM |
|
However, if your CMR is FT232H product=0x6014 (gingernuts is product=0x8350) it would be good to provide 2 things: usbmon (or direct access to it via /sys or /proc or /dev or wherever your Linux OS puts it - yes it must be Linux) output of plugging it in and also running the usbtest.py that comes with cgminer current git like: ./usbtest.py /dev/ttyUSB? icarus (whatever the USB? is) and make sure it gave the right answers (or rerun it) and lsusb -v of the device If it actually creates multiple /dev/ttyUSB? you'll need to run that whole process on each of them (from plug in to usbtest.py)
Is it important for your tests to have product=0x6014 or product=0x8350? I don't know which one I have but my Cairnsmores are early ones, from summer 2012. sudo lsusb will tell you. as will cgminer --usb-list-all -n (note that the parameter order there does matter) On linux the above two look like: Bus 002 Device 008: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC and .USB dev 0: Bus 2 Device 8 ID: 0403:6014 Manufacturer: 'Butterfly Labs' Product: 'BitFORCE SHA256 SC'
The ID numbers are what I'm referring to The 0x6014 is what I don't have the full details for yet for Cairnsmore1 but I presume it will be the same as BFL but with a different baud rate.
|
|
|
|
yohan (OP)
|
|
May 27, 2013, 03:14:26 PM |
|
if it's with a dynamic clocking firmware, I'd expect it would have downclocked a bit. I do not know what there the firmware. I bought it for second hand and I have no idea how and what to see The easy way to tell generically which of the 2 main bitstream options are loaded is the LEDs next to each FPGA. If the red LED continually flashes you probably have Hashvoodoo and dynamic clocking. Otherwise you probably have Makomk and fixed clocking.
|
|
|
|
jml
|
|
May 27, 2013, 05:41:43 PM |
|
if it's with a dynamic clocking firmware, I'd expect it would have downclocked a bit. I do not know what there the firmware. I bought it for second hand and I have no idea how and what to see The easy way to tell generically which of the 2 main bitstream options are loaded is the LEDs next to each FPGA. If the red LED continually flashes you probably have Hashvoodoo and dynamic clocking. Otherwise you probably have Makomk and fixed clocking. The red LED on my Cm1's flash continuously.
|
"Everything is a matter of degree"
|
|
|
LazyOtto
|
|
May 27, 2013, 05:45:57 PM |
|
The red LED on my Cm1's flash continuously.
Which tells us what? And, BTW, there are five red LED's on the board.
|
|
|
|
jml
|
|
May 27, 2013, 06:05:23 PM |
|
The red LED on my Cm1's flash continuously.
Which tells us what? And, BTW, there are five red LED's on the board. The only red LED that flashes when you plug in the USB cable - i.e not powered. According to Yohan, the bitstream is Hashvoodoo. Unless he means the ones where the amber lights are, which then it wouldn't be hashvoodoo.
|
"Everything is a matter of degree"
|
|
|
gyverlb
|
|
May 27, 2013, 07:36:34 PM |
|
The red LED on my Cm1's flash continuously.
Which tells us what? And, BTW, there are five red LED's on the board. The only red LED that flashes when you plug in the USB cable - i.e not powered. According to Yohan, the bitstream is Hashvoodoo. Unless he means the ones where the amber lights are, which then it wouldn't be hashvoodoo. He meant the ones where the amber lights are ("the LEDS next to each FPGA"). I can confirm this myself: I used both hashvoodo and makomk bitstreams and what you describe is the behavior of the makomk fixed-frequency bitstreams and is consistent with the speeds reported by bfgminer (which are twice what is achievable with one FPGA and matches the pairing done by the makomk bitstreams).
|
|
|
|
jml
|
|
May 27, 2013, 07:54:53 PM |
|
The red LED on my Cm1's flash continuously.
Which tells us what? And, BTW, there are five red LED's on the board. The only red LED that flashes when you plug in the USB cable - i.e not powered. According to Yohan, the bitstream is Hashvoodoo. Unless he means the ones where the amber lights are, which then it wouldn't be hashvoodoo. He meant the ones where the amber lights are ("the LEDS next to each FPGA"). I can confirm this myself: I used both hashvoodo and makomk bitstreams and what you describe is the behavior of the makomk fixed-frequency bitstreams and is consistent with the speeds reported by bfgminer (which are twice what is achievable with one FPGA and matches the pairing done by the makomk bitstreams). Right, then makomk it is! Is there any recommendation to change bitstream from makomk to hashvoodoo or will hashing average be the same? I have noticed one thing with the FPGA heat sinks where one array is hotter than the other array. I could see an oscillation in hashing with the pool mining graphs in 3 hour averages over 2 days. When I placed another 120mm fan blowing towards the bottom FPGA board, I can see less oscillations and averages tends to "plateu" more often than without a fan. Although i has been a day now, I will leave it for another day to check on results. Which thermal compound was used to attach these heat sinks?
|
"Everything is a matter of degree"
|
|
|
dodegkr
Newbie
Offline
Activity: 55
Merit: 0
|
|
May 28, 2013, 08:47:57 AM |
|
Is it possible to mine other sha256 coins with cm1 or does that mean a new bitstream?
|
|
|
|
yohan (OP)
|
|
May 28, 2013, 10:46:43 AM |
|
if it's with a dynamic clocking firmware, I'd expect it would have downclocked a bit. I do not know what there the firmware. I bought it for second hand and I have no idea how and what to see The easy way to tell generically which of the 2 main bitstream options are loaded is the LEDs next to each FPGA. If the red LED continually flashes you probably have Hashvoodoo and dynamic clocking. Otherwise you probably have Makomk and fixed clocking. It is the LEDs next to the main FPGAs (groups of 4 LEDs- red, green, ambar,blue) that I am refering to not the red LED next to the controller. The controller LED will always flash when clocks are running with controller V1.5.
|
|
|
|
yohan (OP)
|
|
May 28, 2013, 11:20:14 AM |
|
The red LED on my Cm1's flash continuously.
Which tells us what? And, BTW, there are five red LED's on the board. The only red LED that flashes when you plug in the USB cable - i.e not powered. According to Yohan, the bitstream is Hashvoodoo. Unless he means the ones where the amber lights are, which then it wouldn't be hashvoodoo. He meant the ones where the amber lights are ("the LEDS next to each FPGA"). I can confirm this myself: I used both hashvoodo and makomk bitstreams and what you describe is the behavior of the makomk fixed-frequency bitstreams and is consistent with the speeds reported by bfgminer (which are twice what is achievable with one FPGA and matches the pairing done by the makomk bitstreams). Right, then makomk it is! Is there any recommendation to change bitstream from makomk to hashvoodoo or will hashing average be the same? I have noticed one thing with the FPGA heat sinks where one array is hotter than the other array. I could see an oscillation in hashing with the pool mining graphs in 3 hour averages over 2 days. When I placed another 120mm fan blowing towards the bottom FPGA board, I can see less oscillations and averages tends to "plateu" more often than without a fan. Although i has been a day now, I will leave it for another day to check on results. Which thermal compound was used to attach these heat sinks? There is a spread of operational performance and as far we can tell from our data the -2C grade of silicon actually works as well as -3 that some competitors used. Ironically because of what actually happens -3 silicon can actually deliver less perfomance than -2 silicon. This is what we thought would happen in this design and I think about 1 year ago I might have given out some of the reasons for that. Anyway if you don't remember that have a go at figuring that one out. It's your technical challenge for today. Going back to the point on bitstreams it is a fact that some boards do better on Makomk and others do better on Hashvoodoo. Some boards it does not make any difference. Generally if you have a grade-b then Hashvoodoo is usually the one to be using. Grade-a there isn't such a clear choice. Believe it or not we actually planned air draw over the rear of the boards using our stacking arrangement and a reasonable amount of heat can be taken out of the boards this way. The boards were design to allow heat to be removed partially this way. Basically it can help a bit. Heatsink bonding is not a big factor in the themal solution. It is actually a phase change material and pretty good so don't mess with that. You may break the board trying as well to remove it. It has the properties of a very strong glue once we are done the phase change here in our burn-in process. What can be of benefit is keeping your room ambient temperature down. For most boards if the room is 40 DegC or less it doesn't make much of a difference immediately but there is the odd board that definately likes a little bit cooler. For the majority of customers they won't have any issues with that unless they live in a hot climate and don't have air conditioning. There probably are some very long term lifetime benefits of being in a cooler ambient given the Spartan-6 parts are running out of normal operational levels. Given most of last years delivery have been running ok for about 1 year I am probably talking the difference in somewhere between 5 and 50 years of operation so whether you care is something to decide. Over 40 DegC ambient we do see more boards error more often and if you can keep below this temperature that would give you better returns. Providing it is a dry environment you can run boards in a fairly cold place if happen to live in a cold country. I would say 0 DegC as a sensible minimum ambient but a bit lower is probably ok.
|
|
|
|
dodegkr
Newbie
Offline
Activity: 55
Merit: 0
|
|
June 01, 2013, 07:55:49 PM |
|
Is it possible to mine other sha256 coins with cm1 or does that mean a new bitstream?
anyone?
|
|
|
|
ocminer
Legendary
Offline
Activity: 2688
Merit: 1240
|
|
June 01, 2013, 08:32:20 PM |
|
Is it possible to mine other sha256 coins with cm1 or does that mean a new bitstream?
anyone? You can mine every sha256 coin with <insertyourbitcoinfpgahere> .. Just point the miner to the right pool...
|
suprnova pools - reliable mining pools - #suprnova on freenet https://www.suprnova.cc - FOLLOW us @ Twitter ! twitter.com/SuprnovaPools
|
|
|
dodegkr
Newbie
Offline
Activity: 55
Merit: 0
|
|
June 01, 2013, 10:08:58 PM |
|
thanks, i shall try
|
|
|
|
elchorizo
|
|
June 04, 2013, 12:22:54 AM |
|
I received my order but I am unable to get it to work properly. On cgminer 3.0.1 I am able to get 6 devices up and running (the number of Cairnsmore1's I have)... but they only has around 380 mh/s regardless of any timing settings I use. On 3.2.0 cgminer with the new USB rules, they do not detect at all. I've tried 3 or 4 different modprobe lines some which don't work at all and some which seem to half work... It seems like its only using half of the chips on the CM1's and I can't figure it out. Here is my startup script: sudo cgminer -o stratum+tcp://stratum.btcguild.com:3333 --icarus-timing short --api-listen `for i in /dev/ttyUSB*; do echo -en "-S $i "; done`
Here's some dmesg output and the cgminer output... [ 21.197250] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0xC1E1 [ 31.262836] Adding 102396k swap on /var/swap. Priority:-1 extents:1 across:102396k SS [ 85.604473] usbcore: registered new interface driver usbserial [ 85.604578] usbcore: registered new interface driver usbserial_generic [ 85.604661] USB Serial support registered for generic [ 85.604691] usbserial: USB Serial Driver core [ 85.616519] usbcore: registered new interface driver ftdi_sio [ 85.616672] USB Serial support registered for FTDI USB Serial Device [ 85.617247] ftdi_sio 1-1.2.4.2:1.0: FTDI USB Serial Device converter detected [ 85.617426] usb 1-1.2.4.2: Detected FT4232H [ 85.617447] usb 1-1.2.4.2: Number of endpoints 2 [ 85.617464] usb 1-1.2.4.2: Endpoint 1 MaxPacketSize 512 [ 85.617478] usb 1-1.2.4.2: Endpoint 2 MaxPacketSize 512 [ 85.617491] usb 1-1.2.4.2: Setting MaxPacketSize 512 [ 85.618217] usb 1-1.2.4.2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 85.618650] ftdi_sio 1-1.2.4.2:1.1: FTDI USB Serial Device converter detected [ 85.618810] usb 1-1.2.4.2: Detected FT4232H [ 85.618830] usb 1-1.2.4.2: Number of endpoints 2 [ 85.618847] usb 1-1.2.4.2: Endpoint 1 MaxPacketSize 512 [ 85.618862] usb 1-1.2.4.2: Endpoint 2 MaxPacketSize 512 [ 85.618875] usb 1-1.2.4.2: Setting MaxPacketSize 512 [ 85.619579] usb 1-1.2.4.2: FTDI USB Serial Device converter now attached to ttyUSB1 [ 85.620002] ftdi_sio 1-1.2.4.2:1.2: FTDI USB Serial Device converter detected [ 85.620169] usb 1-1.2.4.2: Detected FT4232H [ 85.620191] usb 1-1.2.4.2: Number of endpoints 2 [ 85.620205] usb 1-1.2.4.2: Endpoint 1 MaxPacketSize 512 [ 85.620220] usb 1-1.2.4.2: Endpoint 2 MaxPacketSize 512 [ 85.620233] usb 1-1.2.4.2: Setting MaxPacketSize 512 [ 85.620960] usb 1-1.2.4.2: FTDI USB Serial Device converter now attached to ttyUSB2 [ 85.621379] ftdi_sio 1-1.2.4.2:1.3: FTDI USB Serial Device converter detected [ 85.621544] usb 1-1.2.4.2: Detected FT4232H [ 85.621566] usb 1-1.2.4.2: Number of endpoints 2 [ 85.621581] usb 1-1.2.4.2: Endpoint 1 MaxPacketSize 512 [ 85.621596] usb 1-1.2.4.2: Endpoint 2 MaxPacketSize 512 [ 85.621609] usb 1-1.2.4.2: Setting MaxPacketSize 512 [ 85.622306] usb 1-1.2.4.2: FTDI USB Serial Device converter now attached to ttyUSB3 [ 85.622735] ftdi_sio 1-1.2.4.3:1.0: FTDI USB Serial Device converter detected [ 85.622906] usb 1-1.2.4.3: Detected FT4232H [ 85.622927] usb 1-1.2.4.3: Number of endpoints 2 [ 85.622942] usb 1-1.2.4.3: Endpoint 1 MaxPacketSize 512 [ 85.622955] usb 1-1.2.4.3: Endpoint 2 MaxPacketSize 512 [ 85.622969] usb 1-1.2.4.3: Setting MaxPacketSize 512 [ 85.623686] usb 1-1.2.4.3: FTDI USB Serial Device converter now attached to ttyUSB4 [ 85.628337] ftdi_sio 1-1.2.4.3:1.1: FTDI USB Serial Device converter detected [ 85.628548] usb 1-1.2.4.3: Detected FT4232H [ 85.628568] usb 1-1.2.4.3: Number of endpoints 2 [ 85.628583] usb 1-1.2.4.3: Endpoint 1 MaxPacketSize 512 [ 85.628598] usb 1-1.2.4.3: Endpoint 2 MaxPacketSize 512 [ 85.628611] usb 1-1.2.4.3: Setting MaxPacketSize 512 [ 85.629343] usb 1-1.2.4.3: FTDI USB Serial Device converter now attached to ttyUSB5 [ 85.629781] ftdi_sio 1-1.2.4.3:1.2: FTDI USB Serial Device converter detected cgminer version 3.0.1 - Started: [2013-06-03 19:17:16] -------------------------------------------------------------------------------- (5s):2.402G (avg):2.274Gh/s | A:4 R:0 HW:0 U:1.8/m WU:31.7/m ST: 2 SS: 0 NB: 1 LW: 186 GF: 0 RF: 0 -------------------------------------------------------------------------------- [P]ool management [S]ettings [D]isplay options [Q]uit ICA 0: | 396.8M/365.8Mh/s | A:2 R:0 HW:0 U:0.88/m ICA 1: | 398.6M/377.0Mh/s | A:0 R:0 HW:0 U:0.00/m ICA 2: | 395.0M/369.8Mh/s | A:0 R:0 HW:0 U:0.00/m ICA 3: | 384.6M/383.4Mh/s | A:2 R:0 HW:0 U:0.88/m ICA 4: | 398.3M/386.2Mh/s | A:0 R:0 HW:0 U:0.00/m ICA 5: | 398.7M/392.4Mh/s | A:0 R:0 HW:0 U:0.00/m --------------------------------------------------------------------------------
[2013-06-03 19:17:14] Started cgminer 3.0.1 [2013-06-03 19:17:14] Icarus Detect: Test failed at /dev/ttyUSB0: get 00000000, should: 000187a2 [2013-06-03 19:17:14] Icarus Detect: Test failed at /dev/ttyUSB1: get 00000000, should: 000187a2 [2013-06-03 19:17:14] Icarus Detect: Test failed at /dev/ttyUSB4: get 00000000, should: 000187a2 [2013-06-03 19:17:14] Icarus Detect: Test failed at /dev/ttyUSB5: get 00000000, should: 000187a2 [2013-06-03 19:17:15] Icarus Detect: Test failed at /dev/ttyUSB8: get 00000000, should: 000187a2 [2013-06-03 19:17:15] Icarus Detect: Test failed at /dev/ttyUSB9: get 00000000, should: 000187a2 [2013-06-03 19:17:15] Probing for an alive pool [2013-06-03 19:17:15] Network diff set to 12.2M [2013-06-03 19:17:15] Stratum from pool 0 detected new block [2013-06-03 19:17:21] API running in local read access mode on port 4028 (10) [2013-06-03 19:17:48] Accepted 02777ef0 Diff 103/32 ICA 0 [2013-06-03 19:18:18] Icarus 1 Re-estimate: Hs=2.499766e-09 W=6.525708e-03 read_count=106 fullnonce=10.743s [2013-06-03 19:18:20] Accepted 06d0ac6d Diff 37/32 ICA 0 [2013-06-03 19:18:22] Icarus 5 Re-estimate: Hs=2.500250e-09 W=5.992283e-03 read_count=106 fullnonce=10.744s [2013-06-03 19:18:30] Icarus 4 Re-estimate: Hs=2.499695e-09 W=6.582135e-03 read_count=106 fullnonce=10.743s [2013-06-03 19:18:38] Icarus 3 Re-estimate: Hs=2.499570e-09 W=6.308758e-03 read_count=106 fullnonce=10.742s [2013-06-03 19:18:38] Accepted 00635301 Diff 659/32 ICA 3 [2013-06-03 19:18:46] Icarus 0 Re-estimate: Hs=2.499796e-09 W=6.780376e-03 read_count=106 fullnonce=10.743s [2013-06-03 19:18:49] Icarus 2 Re-estimate: Hs=2.500204e-09 W=6.400342e-03 read_count=106 fullnonce=10.745s [2013-06-03 19:19:30] Accepted 0750f6cf Diff 34/32 ICA 3
and that is using the following modprobe sudo modprobe ftdi_sio vendor=0x0403 product=0x6001 Though I've also tried the following: sudo modprobe ftdi_sio vendor=0x0403 product=0x8350
and sudo modprobe ftdi_sio product=0x8350 vendor=0x0403
|
BTC: 1Chorizo6WNabZxVfQyGtvF4JiRt7Hexxb LTC: Lchorizoy8ck7Arbby8LDnw5wAmi8h6Hzb
|
|
|
elchorizo
|
|
June 04, 2013, 12:58:02 AM |
|
I received my order but I am unable to get it to work properly. On cgminer 3.0.1 I am able to get 6 devices up and running (the number of Cairnsmore1's I have)... but they only has around 380 mh/s regardless of any timing settings I use.
On 3.2.0 cgminer with the new USB rules, they do not detect at all.
I've tried 3 or 4 different modprobe lines some which don't work at all and some which seem to half work...
It seems like its only using half of the chips on the CM1's and I can't figure it out.
As an update to my own post, I am able to get 5 out of the 6 units to work properly using an old cgminer (new one still won't work with them) and using this modprobe line: modprobe ftdi-sio product=0x8350 vendor=0x0403 However, one unit fails to mine and has 2 orange LED's on while the others are mining. Before mining starts all the LED's on it match all the others. The dip switches match the others, so I can only assume something is wrong with this particular unit. I've swapped USB cables and ports and the problem stays with this CM1 unit. Ideas as to what to try?
|
BTC: 1Chorizo6WNabZxVfQyGtvF4JiRt7Hexxb LTC: Lchorizoy8ck7Arbby8LDnw5wAmi8h6Hzb
|
|
|
Newar
Legendary
Offline
Activity: 1358
Merit: 1001
https://gliph.me/hUF
|
|
June 04, 2013, 09:01:07 AM Last edit: June 04, 2013, 09:21:57 AM by Newar |
|
I received my order but I am unable to get it to work properly. On cgminer 3.0.1 I am able to get 6 devices up and running (the number of Cairnsmore1's I have)... but they only has around 380 mh/s regardless of any timing settings I use.
On 3.2.0 cgminer with the new USB rules, they do not detect at all.
I've tried 3 or 4 different modprobe lines some which don't work at all and some which seem to half work...
It seems like its only using half of the chips on the CM1's and I can't figure it out.
As an update to my own post, I am able to get 5 out of the 6 units to work properly using an old cgminer (new one still won't work with them) and using this modprobe line: modprobe ftdi-sio product=0x8350 vendor=0x0403 However, one unit fails to mine and has 2 orange LED's on while the others are mining. Before mining starts all the LED's on it match all the others. The dip switches match the others, so I can only assume something is wrong with this particular unit. I've swapped USB cables and ports and the problem stays with this CM1 unit. Ideas as to what to try? Just a few quick thoughts: Have you tried running cgminer as root? There is some sort of issue IIRC with USB as non-root. I use icarus timing long, but I don't think that's a problem here. I use modprobe ftdi_sio product=0x8350 vendor=0x0403 too so that can be ruled out. What happens if you _only_ connect that single one you think is faulty? Edit: Do you see them all with ?
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
June 04, 2013, 09:07:18 AM |
|
I received my order but I am unable to get it to work properly. On cgminer 3.0.1 I am able to get 6 devices up and running (the number of Cairnsmore1's I have)... but they only has around 380 mh/s regardless of any timing settings I use. Try BFGMiner with -S all
|
|
|
|
|