Cairnsmore1 - Quad XC6SLX150 Board - page 38.

spiccioli

legendary

Activity: 1379

Merit: 1003

nec sine labore

Quote from: steamboat on August 06, 2012, 02:44:14 PM

are you using windows or linux? i can't get cgminer to load more than 8 pairs w/out freezing in windows

linux, steamboat.

It seem to me that on windows you have make the buffer of the cmd.exe window bigger, going into its properties and making it, for example, 80x50, so that the full list of your boards can be seen inside the window.

In other words, an 80x25 cmd.exe window can only show a few units, you need a bigger window if you have lots of units.

spiccioli.

EDIT: see this for example: https://bitcointalk.org/index.php?topic=28402.msg879120;topicseen#msg879120

steamboat

hero member

Activity: 648

Merit: 500

spiccioli

legendary

Activity: 1379

Merit: 1003

nec sine labore

Today, after looking at abcpool lagging I decided to test ozcoin as per ebereon message where he says that on ozcoin he had higher U: per boards.

These are my boards after 4 hours:

Code:

 cgminer version 2.6.1 - Started: [2012-08-06 17:06:34]
--------------------------------------------------------------------------------
 (5s):7112.6 (avg):7433.5 Mh/s | Q:7095  A:22829  R:95  HW:0  E:322%  U:94.0/m
 TQ: 22  ST: 22  SS: 69  DW: 831  NB: 20  LW: 35096  GF: 11  RF: 1
 Connected to http://eu.ozco.in with LP as user 
 Block: 000005cace1e77dd8a3dba11e7ceb0b8...  Started: [20:59:19]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA  0:                | 379.9/378.1Mh/s | A: 629 R: 2 HW: 2 U: 2.59/m
 ICA  1:                | 322.4/369.7Mh/s | A: 552 R: 6 HW:64 U: 2.27/m
 ICA  2:                | 379.7/365.3Mh/s | A:1233 R: 3 HW:76 U: 5.08/m
 ICA  3:                | 379.7/374.8Mh/s | A:1281 R: 3 HW:23 U: 5.28/m
 ICA  4:                | 370.3/362.5Mh/s | A:1153 R: 5 HW: 5 U: 4.75/m
 ICA  5:                | 363.2/362.7Mh/s | A:1144 R: 2 HW: 0 U: 4.71/m
 ICA  6:                | 379.9/377.7Mh/s | A:1315 R: 3 HW: 3 U: 5.42/m
 ICA  7:                | 379.6/376.7Mh/s | A:1335 R: 5 HW:15 U: 5.50/m
 ICA  8:                | 379.8/377.2Mh/s | A:1250 R: 7 HW: 6 U: 5.15/m
 ICA  9:                | 369.7/372.9Mh/s | A:1146 R: 7 HW:50 U: 4.72/m
 ICA 10:                | 379.7/377.1Mh/s | A:1220 R: 6 HW: 5 U: 5.03/m
 ICA 11:                | 379.8/378.0Mh/s | A:1306 R: 6 HW: 0 U: 5.38/m
 ICA 12:                | 355.8/355.9Mh/s | A:1090 R: 2 HW: 2 U: 4.49/m
 ICA 13:                | 351.4/355.5Mh/s | A:1153 R: 3 HW: 7 U: 4.75/m
 ICA 14:                | 379.8/377.5Mh/s | A:1268 R: 9 HW: 8 U: 5.22/m
 ICA 15:                | 379.8/377.8Mh/s | A:1313 R: 3 HW: 1 U: 5.41/m
 ICA 16:                | 379.7/362.2Mh/s | A:1207 R: 9 HW:87 U: 4.97/m
 ICA 17:                | 379.7/377.3Mh/s | A:1295 R:10 HW: 6 U: 5.33/m
 ICA 18:                | 379.9/378.4Mh/s | A: 629 R: 2 HW: 0 U: 2.59/m
 ICA 19:                | 379.8/378.1Mh/s | A:1313 R: 2 HW: 4 U: 5.41/m

Apart from a higher U: I've found that the number of hardware errors seems lower... today it's more cold here than every other day of the last week, but the HW: parameter is a lot lower.

I think that ozcoin lets the miner roll the time, see E: at 322%, so I've come to the conclusion that a good deal of HW: errors come from FPGAs hashing during the time that the miner is sending new work and so hashing mostly invalid data (trash in trash out

)

This could be a reason for not having HW: increased by FPGAs since that number is not a real indicator of hardware problems when used with a FPGA.

On the other hand, while do FPGAs keep hashing when a new getwork is sent to them?

And, even more important, of the 87 errors of ICA16, how many of them are real errors and not errors due to hashing of a new, incomplete, getwork?

spiccioli.

gyverlb

hero member

Activity: 896

Merit: 1000

Quote from: steamboat on August 06, 2012, 12:08:40 PM

Quote from: makomk on August 04, 2012, 01:35:16 PM

Speaking of resetting boards, these bitstreams should hopefully detect one of the common causes of FPGAs freezing (the DCM losing lock and not outputting a clock anymore) and automatically recover from it: http://www.makomk.com/~aidan/shortfin-dcmwd-20120803.zip Initial signs are looking good, touch wood.

Has anyone tested these yet?

Currently running with the 190MHz bitstream on 2 boards with cgminer 2.5.0. The FPGA1 is regularly idle : orange light on and utility is low for one of the FPGA pairs :

Code:

ICA 0:                | 379.8/373.8Mh/s | A:1912 R:19 HW:0 U: 5.10/m
ICA 1:                | 380.5/377.0Mh/s | A:1078 R:10 HW:0 U: 2.88/m
ICA 2:                | 379.8/374.6Mh/s | A:1945 R:21 HW:0 U: 5.19/m
ICA 3:                | 379.9/375.2Mh/s | A:1629 R:19 HW:0 U: 4.35/m

0 and 2 seem fine, 1 and 3 are lagging behind and the ICA1 board clearly idles most of the time on FPGA 1.

ebereon

sr. member

Activity: 397

Merit: 500

Quote from: steamboat on August 06, 2012, 12:08:40 PM

Quote from: makomk on August 04, 2012, 01:35:16 PM

Speaking of resetting boards, these bitstreams should hopefully detect one of the common causes of FPGAs freezing (the DCM losing lock and not outputting a clock anymore) and automatically recover from it: http://www.makomk.com/~aidan/shortfin-dcmwd-20120803.zip Initial signs are looking good, touch wood.

Has anyone tested these yet?

Yes, that's the latest bitstreams and i use them, works very good.

ebereon

sr. member

Activity: 397

Merit: 500

Quote from: ShadesOfMarble on August 06, 2012, 11:53:49 AM

Which --icarus-timing option do I have to use with cgminer and the shortfin_icarus_cm1_test_150 bitstream to get a correct MH/s readout?

I think no one use this bitstream, but if you want to know the timing, just use short or long and read it yourself. Note it and then use it.

I would deffinitively use the latest bitstreams like "shortfin_dcmwd2_test_150.bit".

eb

steamboat

hero member

Activity: 648

Merit: 500

Quote from: makomk on August 04, 2012, 01:35:16 PM

Speaking of resetting boards, these bitstreams should hopefully detect one of the common causes of FPGAs freezing (the DCM losing lock and not outputting a clock anymore) and automatically recover from it: http://www.makomk.com/~aidan/shortfin-dcmwd-20120803.zip Initial signs are looking good, touch wood.

Has anyone tested these yet?

steamboat

hero member

Activity: 648

Merit: 500

Quote from: ShadesOfMarble on August 06, 2012, 11:53:49 AM

Which --icarus-timing option do I have to use with cgminer and the shortfin_icarus_cm1_test_150 bitstream to get a correct MH/s readout?

I don't use any timing options w/ the latest iteration of cgminer, and as long as none of the chips fail it's pretty accurate

ShadesOfMarble

donator

Activity: 543

Merit: 500

Which --icarus-timing option do I have to use with cgminer and the shortfin_icarus_cm1_test_150 bitstream to get a correct MH/s readout?

steamboat

hero member

Activity: 648

Merit: 500

Quote from: testconpastas2 on August 06, 2012, 12:33:03 AM

To open cgminer with ports of an already running board.
for instance my ports 20 ,21 are hashing OK and i open a new cmd window and type cgminer blah blah -S 20 and 21 again.

I thought that's what you meant. Why would you ever want to do this?

testconpastas2

full member

Activity: 199

Merit: 100

To open cgminer with ports of an already running board.
for instance my ports 20 ,21 are hashing OK and i open a new cmd window and type cgminer blah blah -S 20 and 21 again.

steamboat

hero member

Activity: 648

Merit: 500

Quote from: testconpastas2 on August 05, 2012, 08:51:15 PM

boards which i had thought it was buggy after a power cycle and plug out plug in usb cycle ( and plugin first "buggy" boards) it started to work again .
I ordered new hub switches and new fans but they dont be received till wed/thu , so i will have to wait to test new things.

I'm using w7 64bits and the admin privileges issue ahows up randomly no matter if I'was or not in admin mode , and when it appears allways the board is in "my frozen mode" COM's OK ,orange led...

you get the same error if you try to run a second instance of cgminer over a running board but in "my" case it show up slowly as it was checking something on the board.

Edit: not the same in "my case" before the admin privileges line it shows up the lines
[2012-08-04 21:39:32] Icarus Detect: Test failed at \\.\COM20: get 00000000, should: 000187a2
[2012-08-04 21:39:32] Icarus Detect: Test failed at \\.\COM21: get 00000000, should: 000187a2

what do you mean a second instance of cgminer over a board?

testconpastas2

full member

Activity: 199

Merit: 100

boards which i had thought it was buggy after a power cycle and plug out plug in usb cycle ( and plugin first "buggy" boards) it started to work again .
I ordered new hub switches and new fans but they dont be received till wed/thu , so i will have to wait to test new things.

I'm using w7 64bits and the admin privileges issue ahows up randomly no matter if I'was or not in admin mode , and when it appears allways the board is in "my frozen mode" COM's OK ,orange led...

you get the same error if you try to run a second instance of cgminer over a running board but in "my" case it show up slowly as it was checking something on the board.

Edit: not the same in "my case" before the admin privileges line it shows up the lines
[2012-08-04 21:39:32] Icarus Detect: Test failed at \\.\COM20: get 00000000, should: 000187a2
[2012-08-04 21:39:32] Icarus Detect: Test failed at \\.\COM21: get 00000000, should: 000187a2

steamboat

hero member

Activity: 648

Merit: 500

Quote from: testconpastas2 on August 05, 2012, 03:53:44 AM

Quote from: steamboat on August 04, 2012, 07:43:52 PM

[2012-08-04 21:39:32] Started cgminer 2.6.2a
[2012-08-04 21:39:32] Icarus Detect: Test failed at \\.\COM20: get 00000000, should: 000187a2
[2012-08-04 21:39:32] Icarus Detect: Test failed at \\.\COM21: get 00000000, should: 000187a2

Steamboat

I think your error is mine . I run one board in one cgminer . Could you check if after error lines you posted ,do show up other for a little time telling you something about user privileges Huh

Try to unplug usb from all your boards( better in ubs hub) , then power off PSU, wait a couple of minutes (cold?¿? your board) and then power on PSU and first plug usb of your problematic board. windows should detect it.

Im almost sure in my case is a temp or usb hub issue. because sometimes when board is frozen ( amber leds) it start to work again but other different fails suddenly.

NOTE: frozen for me is when you have your COMS ok and cgminer is not showing OFF state. but lots of LONGPOLL's and amber leds in the fpgas you have programmed.

Please tell me if it works for you.

Next week I'm going to buy some extra fans and i'll post if they fix my problems.

I run cgminer in administrator mode, so user privileges doesn't pop up.

the board doesn't have a chance to freeze. device manager recognizes it, all the drivers are installed correctly, but I get the detect error in cgminer.

I have tried all those steps multiple times Tongue

Quote from: ebereon on August 05, 2012, 06:41:50 AM

Quote from: steamboat on August 04, 2012, 07:43:52 PM

ebereon,

how many boards do you have running per instance of cgminer?

EDIT: I've gotten 8 boards running fine in 2 instances of cgminer (any more than 4 per instance crashes it for some reason???) but I can't seem to get my 9th to get detected.

as per Ebereons instructions, I've identified the boards usb's. I've uninstalled w/ and w/out deleting the drivers, and w/ and w/out uninstalling the com's ports associated w/ the board. Each time, the board re-installs to the same coms, which gives me

[2012-08-04 21:39:32] Started cgminer 2.6.2a
[2012-08-04 21:39:32] Icarus Detect: Test failed at \\.\COM20: get 00000000, should: 000187a2
[2012-08-04 21:39:32] Icarus Detect: Test failed at \\.\COM21: get 00000000, should: 000187a2

every time. No clue where to begin figuring out this issue, any help would be greatly appreciated.

Thanks,

Steamboat

I don't use cgminer yet, just tested it after mpbm was working without problems. Make sure all boards accept the 190Mh bitstream, best joice is mpbm and check 1 day the invalids. If you have invalids >3% on some pair, use a slower bitstream. If now all works in mpbm with <3% invalids, then i'm sure all boards will be working with cgminer too.

eb

This is what i have so far after 22 hours.

If I'm reading that correctly, they're all working normally but pairs 2,6, and 7, are underperforming judging by the low u?

also, i understand readings from the pool can be off from actual but the pool's reporting an avg of 5.3gh/s as opposed to the (EDIT:) 5.8gh/s cgminer is reporting combined.

EDIT: UPDATE:

After randomly deciding to reset and run the 5th board today it magically decided to work again. I think the problem may be a buggy USB cable, but i'm going to have to wait to get the shipment of spares in to test.

Now i'm jonesin for the parallel flash control so I don't have to spend 6 hours per bitstream flash to min/max

norulezapply

hero member

Activity: 481

Merit: 502

Quote from: toxicocean on August 05, 2012, 02:56:50 PM

funny, I got it hashing on my Raspberry Pi by connecting it through a cheap unpowered usb-hub instead of connecting it directly to the Raspberry...

Yeah the Cairnsmore1 boards don't work when you plug them directly into the RPi, but they do through certain powered hubs.

zefir

donator

Activity: 919

Merit: 1000

Quote from: spiccioli on August 05, 2012, 03:28:10 PM

Zefir,

same here (ubuntu server 12.04 64bit), I need to issue it manually or else I don't see any ttyUSB* ports.

spiccioli.

That's strange, works here flawlessly. But I admit I'm still with 11.04 (rushed back from 11.10 when I tried Unity for half a day). Maybe udev processing changed between versions.

Anyhow, to automate it, just add to your /etc/modules the module parameters, i.e. append

Code:

ftdi_sio vendor=0x0403 product=0x8350

I am using this on a different machine that runs my BFLS (with other parameters of course), but again, this might have changed for 12.04

spiccioli

legendary

Activity: 1379

Merit: 1003

nec sine labore

Quote from: zefir on August 05, 2012, 02:02:17 PM

Quote from: norulezapply on August 05, 2012, 01:43:48 PM

You need to do a modprobe.

Plug them in then issue this command:

Code:

modprobe ftdi_sio vendor=0x0403 product=0x8350

FYI, this is not required if you added the udev rules posted by yohan at the CM1 support pages.

Zefir,

same here (ubuntu server 12.04 64bit), I need to issue it manually or else I don't see any ttyUSB* ports.

spiccioli.

BR0KK

hero member

Activity: 784

Merit: 500

Raspberry pi is quite picky when it comes to usb hubs ..... or USB Devices .... for me its useless since every time use it, it only recognizes half of my board s (speaking of Ztex singles and quads) Sad

toxicocean

newbie

Activity: 24

Merit: 0

funny, I got it hashing on my Raspberry Pi by connecting it through a cheap unpowered usb-hub instead of connecting it directly to the Raspberry...

toxicocean

newbie

Activity: 24

Merit: 0

Quote from: norulezapply on August 05, 2012, 01:43:48 PM

I don't get them showing up either.
You need to do a modprobe.
Plug them in then issue this command:

Code:

modprobe ftdi_sio vendor=0x0403 product=0x8350

Then you should see the ttyUSB0/1/2/3 etc. for your Cairnsmore1's

Hope this helps!

tried already since I noticed the udev rules don't seem to apply on Raspberry Pi (Raspbian)
I'll try the powered USB-hub as Doff mentions

Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 38. (Read 286370 times)