Bitcoin Forum
December 08, 2016, 06:28:12 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 [125] 126 127 128 129 »
  Print  
Author Topic: Cairnsmore1 - Quad XC6SLX150 Board  (Read 251294 times)
silverston
Sr. Member
****
Offline Offline

Activity: 312


View Profile
May 25, 2013, 05:10:59 PM
 #2481

Quote
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
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481178492
Hero Member
*
Offline Offline

Posts: 1481178492

View Profile Personal Message (Offline)

Ignore
1481178492
Reply with quote  #2

1481178492
Report to moderator
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
May 25, 2013, 05:19:14 PM
 #2482

Quote
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).

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
SnitraM
Jr. Member
*
Offline Offline

Activity: 40


View Profile
May 27, 2013, 02:40:53 PM
 #2483

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 Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
May 27, 2013, 02:50:23 PM
 #2484

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:
Code:
Bus 002 Device 008: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
and
Code:
.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.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
May 27, 2013, 03:14:26 PM
 #2485

Quote
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
Full Member
***
Offline Offline

Activity: 238



View Profile
May 27, 2013, 05:41:43 PM
 #2486

Quote
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
Sr. Member
****
Offline Offline

Activity: 476


View Profile
May 27, 2013, 05:45:57 PM
 #2487

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
Full Member
***
Offline Offline

Activity: 238



View Profile
May 27, 2013, 06:05:23 PM
 #2488

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
Hero Member
*****
Offline Offline

Activity: 896



View Profile
May 27, 2013, 07:36:34 PM
 #2489

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

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
jml
Full Member
***
Offline Offline

Activity: 238



View Profile
May 27, 2013, 07:54:53 PM
 #2490

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
Jr. Member
*
Offline Offline

Activity: 55


View Profile
May 28, 2013, 08:47:57 AM
 #2491

Is it possible to mine other sha256 coins with cm1 or does that mean a new bitstream?
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
May 28, 2013, 10:46:43 AM
 #2492

Quote
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
Sr. Member
****
Offline Offline

Activity: 448



View Profile
May 28, 2013, 11:20:14 AM
 #2493

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
Jr. Member
*
Offline Offline

Activity: 55


View Profile
June 01, 2013, 07:55:49 PM
 #2494

Is it possible to mine other sha256 coins with cm1 or does that mean a new bitstream?

anyone?
ocminer
Legendary
*
Offline Offline

Activity: 1582



View Profile WWW
June 01, 2013, 08:32:20 PM
 #2495

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
Jr. Member
*
Offline Offline

Activity: 55


View Profile
June 01, 2013, 10:08:58 PM
 #2496

thanks, i shall try
elchorizo
Full Member
***
Offline Offline

Activity: 182


View Profile
June 04, 2013, 12:22:54 AM
 #2497

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:
Code:
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...

Code:
[   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

Code:
sudo modprobe ftdi_sio vendor=0x0403 product=0x6001

Though I've also tried the following:

Code:
sudo modprobe ftdi_sio vendor=0x0403 product=0x8350

and sudo modprobe ftdi_sio product=0x8350 vendor=0x0403

BTC: 1Chorizo6WNabZxVfQyGtvF4JiRt7Hexxb
LTC: Lchorizoy8ck7Arbby8LDnw5wAmi8h6Hzb
elchorizo
Full Member
***
Offline Offline

Activity: 182


View Profile
June 04, 2013, 12:58:02 AM
 #2498

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:

Code:
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 Offline

Activity: 1162


https://gliph.me/hUF


View Profile
June 04, 2013, 09:01:07 AM
 #2499

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:

Code:
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
Code:
ls -l /dev/ttyUSB*
?

OTC rating | GPG keyid 1DC91318EE785FDE | Gliph: lightning bicycle tree music | Mycelium, a swift & secure Bitcoin client for Android | LocalBitcoins
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
June 04, 2013, 09:07:18 AM
 #2500

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

Pages: « 1 ... 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 [125] 126 127 128 129 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!