Bitcoin Forum
December 09, 2016, 07:40:23 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 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 251364 times)
spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
August 09, 2012, 10:27:13 AM
 #1861

I've built cgminer 2.6.4 for linux 32bit with zefir patch and icarus support only.

http://p2pool.soon.it/cgminer/cgminer-2.6.4-zefir

spiccioli
1481312423
Hero Member
*
Offline Offline

Posts: 1481312423

View Profile Personal Message (Offline)

Ignore
1481312423
Reply with quote  #2

1481312423
Report to moderator
1481312423
Hero Member
*
Offline Offline

Posts: 1481312423

View Profile Personal Message (Offline)

Ignore
1481312423
Reply with quote  #2

1481312423
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Glasswalker
Sr. Member
****
Offline Offline

Activity: 350



View Profile WWW
August 09, 2012, 01:09:24 PM
 #1862

Ok, quick update. Unfortunately my last build once again (sigh...) had a bug in the new LVDS clocking. (literally oversight on my part, I put a FALSE where it should have been TRUE for LVDS signal termination... DOH!) anyway, that resulted in continuing stability issues, and caused my latest week long marathon build to be a waste of time... Grumble...

Anyway, this has prompted me to apply another round of code fixes. And I think this one should wrap it up. I've fixed the couple minor bugs that existed, so those problems should be solved. AND I've applied several new fixes as well. Including backporting ALL (that I could find) of makomk's shortfin fixes into the HashVoodoo core now. (With the exception of the DCM watchdog, because it was just to fix the failing DCM, but with the LVDS clock signalling there actually is no DCM at all, so nothing to slap a watchdog on lol).

Anyway, this one has several new fixes, and all of makomk's improvements. Plus I've fixed the nonce range problem (which will cause wrong hashrate to report, and wierd U numbers and such) the chips *should* (provided I didn't bork something up again) hash a full nonce range per chip.

So anyway, just posting this up, these changes are already committed, and pushed up to the github, so they are there for everyone to see Smiley And I'm doing a first round build on it now.

Also, I should have a new controller coming very soon (as in within the next day or two) to match this build, which will provide the following improvements/fixes:
- Should solve jtag instability and usb flashing capabilities, meaning people without jtag cables *should* be able to install it (but need to confirm this first for safety)
- It now supports dynamic clocking, it will be crude at this point, but it will allow 2 dip switches to be used to select from 4 different hashing clock rates (while leaving the communications clocks alone to keep stable baud rate)
- 180Mhz
- 190Mhz
- 200Mhz
- 210Mhz

This way with a given board, you can tune it within that range to find the optimal hashing rate without having to reflash various bitstreams (easy overclocking) Smiley I'm building the bitstreams to close timing to 180Mhz now, so that lowest one will be the "100% in spec", but typically the chips can easily reach a bit beyond their spec (much like CPUs, they are graded in batches based on quality, and some chips may overclock better than others). In some cases I get lucky and exceed timing. So for example, if I'm shooting for 180Mhz, and manages to close timing, that means that no path within the FPGA will exceed a delay of 5.555ns, but if I manage to close timing with 0.55ns of slack, that means that it's actually only got 5ns of delay, which means it's technically fully "in-spec" for 200Mhz clock. And if I exceed timing by a full 1ns, then we're super lucky, and that means it's in-spec for a 219Mhz clock. Now that doesn't take into account power draw of all the components in the chip, noise at those frequencies, and thermal stability. But it means the more "in-spec" we are, the more "universally stable" it should be at a given clock. So the new overclocking options (however crude for now) should help people dial in what's "best" for their given board.

Down the road this will become an auto-tuned thing in software based on invalid rates to find the optimal share yield per second per chip. (yes technically we can tune each chip independently)

Anyway, just a quick update. I'll post more once I've been able to test it.

Oh and also my new board arrived, so I now have both my #0001 serial number board, and a newer #04xx (can't remember exact number) board, so this lets me test and validate on "both sides of the coin".

Just trying to make Bitcoin a Success... One crazy project at a time. (13rwPKskyATcAq3PpnCikfFG8989DQ8M3c)
HashVoodoo Open Source FPGA Mining Bitstream: https://github.com/pmumby/hashvoodoo-fpga-bitcoin-miner
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
August 09, 2012, 01:40:58 PM
 #1863

Ok, quick update. Unfortunately my last build once again (sigh...) had a bug in the new LVDS clocking. (literally oversight on my part, I put a FALSE where it should have been TRUE for LVDS signal termination... DOH!) anyway, that resulted in continuing stability issues, and caused my latest week long marathon build to be a waste of time... Grumble...
Hmmm. You should've been able to fix that up post-build in FPGA Editor... oh well. Also, you might've been able to get away with using the .ncd from that run as a SmartGuide guide file (or not, I've been having some annoying routing issues with SmartGuide even with totally unchanged designs).

Anyway, this one has several new fixes, and all of makomk's improvements. Plus I've fixed the nonce range problem (which will cause wrong hashrate to report, and wierd U numbers and such) the chips *should* (provided I didn't bork something up again) hash a full nonce range per chip.
Bear in mind this will still require changes to mining software to avoid weird problems with hash rate reporting. (I had a cunning idea to try and work around this, but it turned out that the Xilinx mapping tool really didn't like it so it's probably best to just change the software, heh.)

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
Glasswalker
Sr. Member
****
Offline Offline

Activity: 350



View Profile WWW
August 09, 2012, 02:17:11 PM
 #1864

Yeah I could have done it in fpgaeditor, but I had several other changes that needed doing too, so I used that as a base. I'll try the fpgaeditor option as well, while I'm waiting on this build to run through smartxplorer. I've found even minor changes to the design, tend to bork up the tools even if I'm using smartguide from a previous successful run. But maybe that was just an isolated experience.

And yeah I'm still aware of the software issues. TheSeven mentioned it to me on IRC. I've got a fork of MPBM which has a cairnsmore module in it, and I'll be fixing the hash reporting in that eventually.

Thanks!

Just trying to make Bitcoin a Success... One crazy project at a time. (13rwPKskyATcAq3PpnCikfFG8989DQ8M3c)
HashVoodoo Open Source FPGA Mining Bitstream: https://github.com/pmumby/hashvoodoo-fpga-bitcoin-miner
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
August 09, 2012, 02:31:21 PM
 #1865

...

Down the road this will become an auto-tuned thing in software based on invalid rates to find the optimal share yield per second per chip. (yes technically we can tune each chip independently)

Anyway, just a quick update. I'll post more once I've been able to test it.
...
Hopefully by this you mean that like with a ztex, the miner software can tell it to increase and decrease the MHz clock on the fly
So it is up to software control (and HW: error counts) to decide the optimal MHz

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

Activity: 350



View Profile WWW
August 09, 2012, 02:44:55 PM
 #1866

Hopefully by this you mean that like with a ztex, the miner software can tell it to increase and decrease the MHz clock on the fly
So it is up to software control (and HW: error counts) to decide the optimal MHz

That's correct, I intend to expose a more advanced serial protocol which will allow the mining software to (among other things) adjust the clock rate for the hashing clock. That's a ways off for now though, so initially we're working with the more crude "dip switch coarse clock settings" option...

Just trying to make Bitcoin a Success... One crazy project at a time. (13rwPKskyATcAq3PpnCikfFG8989DQ8M3c)
HashVoodoo Open Source FPGA Mining Bitstream: https://github.com/pmumby/hashvoodoo-fpga-bitcoin-miner
Hpman
Full Member
***
Offline Offline

Activity: 176



View Profile
August 10, 2012, 07:08:28 AM
 #1867

Short feedback from me side,  old shortfin_190 and dcmwd2_200 running great without any problems on my board. Waiting for 2xx versions Smiley. Unfortunaly at the moment I'm still using original cgminer 2.6.1/2.6.1 without zefirs patch, but 'll compile new binary next days. Great work guys, hopefully bounty will shared to all who spend a lot of spare time for that project. Still missing somethings news from enterpoint itself ...

Hpman
ShadesOfMarble
Donator
Hero Member
*
Offline Offline

Activity: 543



View Profile
August 10, 2012, 10:16:05 AM
 #1868

@Hpman I guess you have a board with S/N >50?

Review of the Spondoolies-Tech SP10 „Dawson“ Bitcoin miner (1.4 TH/s)

[22:35] <Vinnie_win> Did anyone get paid yet? | [22:36] <Isokivi> pirate did!
Hpman
Full Member
***
Offline Offline

Activity: 176



View Profile
August 10, 2012, 11:20:14 AM
 #1869

@Hpman I guess you have a board with S/N >50?

Happily yes. Its > #150.
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
August 10, 2012, 01:20:25 PM
 #1870

July Order Close Out

A few of you, on a July delivery promise, have not responded to emails saying boards are available. In order that we can delivery ASAP to customers waiting for boards we are about to close down the July order list. We will wipe anything remaining that we have the July list on Monday so you will lose that order place unless we have heard from you either to reschedule the order or to pay for it. So if you think you have been missed do check your spam box and/or contact us if you still want your order.
hm
Member
**
Offline Offline

Activity: 106


View Profile
August 10, 2012, 04:04:57 PM
 #1871

still using twin_test @ 62-0017 ... I'm lucky at the moment as hash rate seems to be OK for the last half of test period:



I'm waiting impatiently for a mature bitstream for cm1 boards <50, and I'm confident once again that something (that's not just usable but also produces stable hash rates) will be released within next two or three weeks, after my disappointment in the last days.
I know I shouldn't be disappointed because of the project still being in development phase rather than being production ready, but I still couldn't help it.

Now I'll test again a makomk shortfin_dcmwd2_test bitstream, although this will probably interrupt my period of luck regarding above hash rates with twin_test...
spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
August 10, 2012, 05:18:03 PM
 #1872

Right now, on linux, at every reboot of the host pc the order in which serveral boards map themselves to the various ttyUSB ports is mostly random.

There is though, in this early stage, the need to know which board ended up on each ttyUSB port.

I've found that, on my ubuntu 12.04 server, there are symlinks inside /dev/serial/by-id/ which map every board/port using their serial number to their respective ttyUSBnn port.

So, having several boards, all that is needed is plug them one by one and issue a

Code:
sudo lsusb -v | grep iSerial

to know the serial number of each one.

Knowing, for example, that board 62-0134 has serial number FTVJ59WC, a simple

Code:
ls -l /dev/serial/by-id/

should show something like

Code:
lrwxrwxrwx 1 root root 13 Aug  9 21:50 usb-FTDI_Cairnsmore1_FTVJ59WC-if00-port0 -> ../../ttyUSB4
lrwxrwxrwx 1 root root 13 Aug  9 21:50 usb-FTDI_Cairnsmore1_FTVJ59WC-if01-port0 -> ../../ttyUSB5
lrwxrwxrwx 1 root root 13 Aug  9 21:50 usb-FTDI_Cairnsmore1_FTVJ59WC-if02-port0 -> ../../ttyUSB6
lrwxrwxrwx 1 root root 13 Aug  9 21:50 usb-FTDI_Cairnsmore1_FTVJ59WC-if03-port0 -> ../../ttyUSB7

From which we know that board FTVJ59WC if02/if03 are the serial ports ttyUSB6/7.

Cgminer names the various ICA nn using the same order in which they are listed using the -S parameters, so if I have a command line like

Code:
./cgminer -S ... -S ... -S /dev/ttyUSB6 -S /dev/ttyUSB7 ...

I'm now able to say that my ICA 2 and ICA 3 are my board with serial number 134 written ontop.

Maybe this was clear to everybody here but me Smiley

Anyway, this is just half of what we can do.

On ubuntu there is a rule inside /lib/udev/rules.d which is named 60-persistent-serial.rules which is the rule set creating those symlinks inside /dev/serial/by-id/.

I've copied it inside /etc/udev/rules.d as 99-cairnsmore-links.rules and I've modified it to create more meaningful links inside /dev

Code:
ACTION=="remove", GOTO="persistent_serial_end"
SUBSYSTEM!="tty", GOTO="persistent_serial_end"
KERNEL!="ttyUSB[0-9]*|ttyACM[0-9]*", GOTO="persistent_serial_end"

SUBSYSTEMS=="usb-serial", ENV{.ID_PORT}="$attr{port_number}"

IMPORT{builtin}="usb_id"
ENV{ID_SERIAL}=="", GOTO="persistent_serial_end"

SUBSYSTEMS=="usb", ENV{ID_USB_INTERFACE_NUM}="$attr{bInterfaceNumber}"
ENV{ID_USB_INTERFACE_NUM}=="", GOTO="persistent_serial_end"

ATTRS{serial}=="FTVJ59WC", SYMLINK+="cm-62-0134-if$env{ID_USB_INTERFACE_NUM}"
ATTRS{serial}=="FTVJ5AGN", SYMLINK+="cm-62-0135-if$env{ID_USB_INTERFACE_NUM}"
ATTRS{serial}=="FTVJ88QX", SYMLINK+="cm-62-0136-if$env{ID_USB_INTERFACE_NUM}"
ATTRS{serial}=="FTVJ88VS", SYMLINK+="cm-62-0137-if$env{ID_USB_INTERFACE_NUM}"
# ... and so on for every board ...

LABEL="persistent_serial_end"

With these rules I have now

Code:
$ ls -l /dev/cm*

lrwxrwxrwx 1 root root 7 Aug  9 21:50 /dev/cm-62-0134-if00 -> ttyUSB4
lrwxrwxrwx 1 root root 7 Aug  9 21:50 /dev/cm-62-0134-if01 -> ttyUSB5
lrwxrwxrwx 1 root root 7 Aug  9 21:50 /dev/cm-62-0134-if02 -> ttyUSB6
lrwxrwxrwx 1 root root 7 Aug  9 21:50 /dev/cm-62-0134-if03 -> ttyUSB7
lrwxrwxrwx 1 root root 8 Aug  8 21:51 /dev/cm-62-0136-if00 -> ttyUSB24
lrwxrwxrwx 1 root root 8 Aug  8 21:51 /dev/cm-62-0136-if01 -> ttyUSB25
lrwxrwxrwx 1 root root 8 Aug  8 21:51 /dev/cm-62-0136-if02 -> ttyUSB26
lrwxrwxrwx 1 root root 8 Aug  8 21:51 /dev/cm-62-0136-if03 -> ttyUSB27
lrwxrwxrwx 1 root root 8 Aug  8 22:11 /dev/cm-62-0137-if00 -> ttyUSB28
lrwxrwxrwx 1 root root 8 Aug  8 22:11 /dev/cm-62-0137-if01 -> ttyUSB29
lrwxrwxrwx 1 root root 8 Aug  8 22:11 /dev/cm-62-0137-if02 -> ttyUSB30
lrwxrwxrwx 1 root root 8 Aug  8 22:11 /dev/cm-62-0137-if03 -> ttyUSB31

Which are valid links that I can use when I start cgminer instead of the ever changing ttyUSBnn ports.

Code:
cgminer -S /dev/cm-62-0134-if02 -S /dev/cm-62-0134-if03 -S ...

Calling cgminer like this gives me the assurance that ICA 0 will always be port 2 of board 62-0134 and ICA 1 port 3.

ICA names/numbers do not depend anymore on the order in which my host PC sees the boards and/or the usb port to which I plug them.

I hope this helps Smiley

spiccioli
hm
Member
**
Offline Offline

Activity: 106


View Profile
August 10, 2012, 07:20:39 PM
 #1873

I flashed shortfin_dcmwd2_test_200_overclock.bit @ 62-0017:

  • board was off and disconnected and had twin_test flashed
  • set DIP switches according to new bitstream + flashing procedure: SW1-3 off, SW6-1 off, SW3-2 and SW5-2 off, the rest to ON position
  • started up VM, logged in as root
  • waited more than 5 minutes
  • connected usb cable (disabled 5v power line to prevent the controller from switching the power source)
  • waited more than 5 minutes
  • xc3sprog -c cm1 -j => OK
  • xc3sprog -c cm1 -p0 -Ixc6lx150.bit shortfin_dcmwd2_test_200_overclock.bit
    xc3sprog -c cm1 -p1 -Ixc6lx150.bit shortfin_dcmwd2_test_200_overclock.bit
    xc3sprog -c cm1 -p2 -Ixc6lx150.bit shortfin_dcmwd2_test_200_overclock.bit
    xc3sprog -c cm1 -p3 -Ixc6lx150.bit shortfin_dcmwd2_test_200_overclock.bit
    all OK
  • powered off and disconnected usb
  • set SW1-3 to ON, others not changed
  • powered up the board
  • reboot PC
  • fpga LEDs orange, then waited more than 10 minutes
  • connected USB and checked device manager
  • successfully started cgminer with first try: cgminer.exe -G -S "\\.\COM22" -S "\\.\COM23" --icarus-timing long -c eligius.conf

=> some red flashes, some green flashes, not always "Accepted" messages when green flashes occur



..let's wait some hours for better stats...
Lethos
Sr. Member
****
Offline Offline

Activity: 476


Keep it Simple. Every Bit Matters.


View Profile WWW
August 10, 2012, 08:30:35 PM
 #1874

One my boards is currently happy on the shortfin200 and the other can only cope with the shortfin190.
Not sure why, can't get both to run without a lame duck effect occurring. It is good progress and I'm happy with the results.

Lethos Designs | UK BTC Seller -  Local Bitcoins | BTC OTC Rating | 1EFhXfX9uXsbXBF3LC69GiVfS3SHCsyMR1
FPGA: 2x Quad XC6SLX150 Boards
zefir
Donator
Hero Member
*
Offline Offline

Activity: 917



View Profile
August 10, 2012, 08:55:58 PM
 #1875

To all 20+ CM1 boards operators: I went bananas with cascading my 4- and 7-port USB hubs and searching for the one unstable cable in the mess over the past weeks now.

Ordered this


35-port hub (powered with a 5A brick) here (there are other sources, but I found that to be the cheapest one) and got the package delivered to Switzerland after 5 days.

Confirming that it is working with 26 CM1 boards flawlessly for 48h+ so far.

Lethos
Sr. Member
****
Offline Offline

Activity: 476


Keep it Simple. Every Bit Matters.


View Profile WWW
August 10, 2012, 09:36:29 PM
 #1876

Have to say that is a very pretty usb hub.

Lethos Designs | UK BTC Seller -  Local Bitcoins | BTC OTC Rating | 1EFhXfX9uXsbXBF3LC69GiVfS3SHCsyMR1
FPGA: 2x Quad XC6SLX150 Boards
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
August 10, 2012, 10:06:51 PM
 #1877

OK, with a bit of help from ebereon running lots of SmartXplorer runs, the following should apparently hit 200 MHz on the pairs that couldn't manage it before: http://www.makomk.com/~aidan/shortfin-eb-20120809.zip Unfortunately, it doesn't have a functioning DCM watchdog, so you have to watch out for pairs falling over. Apparently ebereon has managed to get all of his FPGAs running reasonably stably at 200 MHz by combining this with the dcmwd2 ones. A good starting guess would probably be 200 MHz http://www.makomk.com/~aidan/shortfin-dcmwd-20120808.zip on FPGA0/1, 200MHz shortfin-eb on 2/3, switch to shortfin-eb if you have too many invalids on 0/1, switch to dcmwd if the U/m of 2/3 drops off spectacularly after a few hours (should be 5+, if it's 2 to low 4s something's up), fall back to 190MHz dcmwd if either of those still doesn't work reliably.

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
August 10, 2012, 10:24:37 PM
 #1878

Right now, on linux, at every reboot of the host pc the order in which serveral boards map themselves to the various ttyUSB ports is mostly random.

...

Calling cgminer like this gives me the assurance that ICA 0 will always be port 2 of board 62-0134 and ICA 1 port 3.

ICA names/numbers do not depend anymore on the order in which my host PC sees the boards and/or the usb port to which I plug them.

I hope this helps Smiley

spiccioli
To help with viewing the configuration:
Though you probably know, there is also the API devdetails that will tell you the ICAn -> /dev/ttyUSBn mapping
(or in your case the ICAn -> /dev/cm-* mapping)

In linux:
Code:
echo -n 'devdetails' | nc 127.0.0.1 4028 ; echo

or linux and windows:
Code:
java API devdetails

However .......

If you use the latest github miner.php to view your boards you can easily add a custom summary button to show the mapping.

In miner.php, the default $customsummarypages is:
Code:
$mobilepage = array(
 'DATE' => null,
 'RIGS' => null,
 'SUMMARY' => array('Elapsed', 'MHS av', 'Found Blocks=Blks', 'Accepted', 'Rejected=Rej', 'Utility'),
 'DEVS+NOTIFY' => array('DEVS.Name=Name', 'DEVS.ID=ID', 'DEVS.Status=Status', 'DEVS.Temperature=Temp',
                        'DEVS.MHS av=MHS av', 'DEVS.Accepted=Accept', 'DEVS.Rejected=Rej',
                        'DEVS.Utility=Utility', 'NOTIFY.Last Not Well=Not Well'),
 'POOL' => array('POOL', 'Status', 'Accepted', 'Rejected=Rej', 'Last Share Time'));
$mobilesum = array(
 'SUMMARY' => array('MHS av', 'Found Blocks', 'Accepted', 'Rejected', 'Utility'),
 'DEVS+NOTIFY' => array('DEVS.MHS av', 'DEVS.Accepted', 'DEVS.Rejected', 'DEVS.Utility'),
 'POOL' => array('Accepted', 'Rejected'));
#
# customsummarypages is an array of these Custom Summary Pages
$customsummarypages = array('Mobile' => array($mobilepage, $mobilesum));

But to add one that shows the /dev/tty*:
Add this:
Code:
$devdetpage = array(
 'DATE' => null,
 'RIGS' => null,
 'DEVS+DEVDETAILS' => array('DEVS.Name=Name', 'DEVS.ID=ID',
                        'DEVS.Temperature=Temp', 'DEVS.MHS av=MHS av',
                        'DEVS.Accepted=Accepted', 'DEVS.Rejected=Rej',
                        'DEVDETAILS.Device Path=Device'));
$devdetsum = array(
 'DEVS+DEVDETAILS' => array('DEVS.MHS av', 'DEVS.Accepted', 'DEVS.Rejected'));

and change this:
Code:
$customsummarypages = array('Mobile' => array($mobilepage, $mobilesum),
'DevDet' => array($devdetpage, $devdetsum));

Then the DevDet button will show each device in a brief single line summary with the "Device Path" value (/dev/tty* or /dev/cm-* or ...)

... and of course if you have them on multiple cgminer's you just edit $rigs to point to each of them and have it all on one page Smiley

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

Activity: 327


View Profile
August 11, 2012, 03:32:00 AM
 #1879

Right now, on linux, at every reboot of the host pc the order in which serveral boards map themselves to the various ttyUSB ports is mostly random.

...

Calling cgminer like this gives me the assurance that ICA 0 will always be port 2 of board 62-0134 and ICA 1 port 3.

ICA names/numbers do not depend anymore on the order in which my host PC sees the boards and/or the usb port to which I plug them.

I hope this helps Smiley

spiccioli
To help with viewing the configuration:
Though you probably know, there is also the API devdetails that will tell you the ICAn -> /dev/ttyUSBn mapping
(or in your case the ICAn -> /dev/cm-* mapping)

In linux:
Code:
echo -n 'devdetails' | nc 127.0.0.1 4028 ; echo

or linux and windows:
Code:
java API devdetails

However .......

If you use the latest github miner.php to view your boards you can easily add a custom summary button to show the mapping.

In miner.php, the default $customsummarypages is:
Code:
$mobilepage = array(
 'DATE' => null,
 'RIGS' => null,
 'SUMMARY' => array('Elapsed', 'MHS av', 'Found Blocks=Blks', 'Accepted', 'Rejected=Rej', 'Utility'),
 'DEVS+NOTIFY' => array('DEVS.Name=Name', 'DEVS.ID=ID', 'DEVS.Status=Status', 'DEVS.Temperature=Temp',
                        'DEVS.MHS av=MHS av', 'DEVS.Accepted=Accept', 'DEVS.Rejected=Rej',
                        'DEVS.Utility=Utility', 'NOTIFY.Last Not Well=Not Well'),
 'POOL' => array('POOL', 'Status', 'Accepted', 'Rejected=Rej', 'Last Share Time'));
$mobilesum = array(
 'SUMMARY' => array('MHS av', 'Found Blocks', 'Accepted', 'Rejected', 'Utility'),
 'DEVS+NOTIFY' => array('DEVS.MHS av', 'DEVS.Accepted', 'DEVS.Rejected', 'DEVS.Utility'),
 'POOL' => array('Accepted', 'Rejected'));
#
# customsummarypages is an array of these Custom Summary Pages
$customsummarypages = array('Mobile' => array($mobilepage, $mobilesum));

But to add one that shows the /dev/tty*:
Add this:
Code:
$devdetpage = array(
 'DATE' => null,
 'RIGS' => null,
 'DEVS+DEVDETAILS' => array('DEVS.Name=Name', 'DEVS.ID=ID',
                        'DEVS.Temperature=Temp', 'DEVS.MHS av=MHS av',
                        'DEVS.Accepted=Accepted', 'DEVS.Rejected=Rej',
                        'DEVDETAILS.Device Path=Device'));
$devdetsum = array(
 'DEVS+DEVDETAILS' => array('DEVS.MHS av', 'DEVS.Accepted', 'DEVS.Rejected'));

and change this:
Code:
$customsummarypages = array('Mobile' => array($mobilepage, $mobilesum),
'DevDet' => array($devdetpage, $devdetsum));

Then the DevDet button will show each device in a brief single line summary with the "Device Path" value (/dev/tty* or /dev/cm-* or ...)

... and of course if you have them on multiple cgminer's you just edit $rigs to point to each of them and have it all on one page Smiley


I tried to test this out but I'm obviously doing something wrong because I just get a blank page. I have 2.6.4 from git is that also the latest miner.php? Also where within miner.php do I need to paste this code? or do I need to replace something with it? I have rigs currently working with 2.6.4 version.

Thanks for the help.

Doff












spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
August 11, 2012, 07:29:08 AM
 #1880

Right now, on linux, at every reboot of the host pc the order in which serveral boards map themselves to the various ttyUSB ports is mostly random.

...

Calling cgminer like this gives me the assurance that ICA 0 will always be port 2 of board 62-0134 and ICA 1 port 3.

ICA names/numbers do not depend anymore on the order in which my host PC sees the boards and/or the usb port to which I plug them.

I hope this helps Smiley

spiccioli

kano,

I've never used the API, so thanks for the example with it and miner.php.

To help with viewing the configuration:
Though you probably know, there is also the API devdetails that will tell you the ICAn -> /dev/ttyUSBn mapping
(or in your case the ICAn -> /dev/cm-* mapping)

In linux:
Code:
echo -n 'devdetails' | nc 127.0.0.1 4028 ; echo

my biggest 'problem' was not mapping ICAn to ttyUSBn, but ttyUSBn to the 'correct' board (I have ten of them) so that, for example, I can flash a slower bitstream to the pair with too many errors.

spiccioli
Pages: « 1 ... 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 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!