Cairnsmore1 - Quad XC6SLX150 Board - page 35.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: ?? on ??

...
Maybe so, but as you say, not processing the complete range is a bug.

I can't be bothered to make a complete proof, but it's demonstrable that terminating after finding a share lowers overall utility.

If valid solutions are independent and have a uniform probability, failing to complete the range will miss clusters of valid shares. A nonce range will have an integer number of valid shares - 0, 1, 2, 3 etc. Binomial theorem would allow you to calculate the expected distribution of valid shares per range. In any range with 2 or higher solutions, terminating after the first one will lower the ultimate utility of the system and, effectively the 'luck' of the miner.

Actually the net effect would be distribution dependent. If % of nonce ranges with only 1 solution exceeds the % of ranges with 2-99 solutions, you are better off moving to the next range. (I chose 99 as an arbitrarily large number where the probability of having that many solutions in a range becomes vanishingly small)

No, sorry, it doesn't reduce U due to probability.
(and no it's not a bug)

It only reduces MH/s due to processing more work to do the same number of hashes
Having a slightly lower MH/s will of course also mean a slightly lower U - though the difference is very small.

The distance from one share to the next is random and independent of the work being done
i.e. you can look at it this the simple way: every hash done has an equal chance of being a share.
So it doesn't matter if you do 10% of each nonce range, or 90% of each nonce range, over time the average expected number of 1 difficulty shares will converge to 1 in each 2^32 hashes, no matter where they come from
(as long as they are not duplicates of course Tongue

)

toxicocean

newbie

Activity: 24

Merit: 0

Quote from: makomk on August 11, 2012, 02:19:08 PM

http://www.makomk.com/~aidan/shortfin-dcmwd4c-20120811.7z should have the higher potential hashrates and the DCM watchdog, with a bit of luck it should reach 200+ MHz on most boards.

Are these DCM bitstreams also suitable for pre #0050 boards? (I tested the shortfin_dcmwd2_test_200_overclock.bit some days ago and it didn't seem to be hashing very stable on my #0005 board)

Currently the best bitstream for my board seems to be the shortfin_icarus_cm1_test_190_overclock.bit, closely followed by shortfin_eb_test_210_overclock.bit, but that last one isn't stable (1 Icarus device stops performing work after some time)

makomk

hero member

Activity: 686

Merit: 564

Quote from: spiccioli on August 11, 2012, 01:14:01 PM

makomk,

are you going to build a version which has the dcm watchdog again or is the dcm watchdog a problem when trying to reach higher hashrates?

spiccioli

I am, it's just that was built with an older non-functional version of the DCM watchdog and I ran into a whole bunch of irritating technical issues when trying to merge the newer version in. http://www.makomk.com/~aidan/shortfin-dcmwd4c-20120811.7z should have the higher potential hashrates and the DCM watchdog, with a bit of luck it should reach 200+ MHz on most boards. I'm seeing some really weird behaviour from the 210 MHz bitstream though - it's consistently getting a lower U/m than it should on one half of my test board (about 5.3ish when it should be closer to 5.86).

Note that I'm trying out a new archive format with this set of bitstreams to reduce the download size. You may need to download 7-Zip to unpack them if you don't have any other unarchiving software installed that can open .7z files; it's of course free, open source and adware-free and all that good stuff. Linux users should install p7zip instead. (The new archive plus the 7-Zip installer still comes in at a quarter the download size of using ZIP, so it's a definite saving.) Try starting off with the 200 MHz bitstream.

Hope this works. Donations to 1CCorPPK8X6Px5iNxCBc5Eciw81iZPVBPh are welcome as always.

spiccioli

legendary

Activity: 1378

Merit: 1003

nec sine labore

Quote from: makomk on August 10, 2012, 06:06:51 PM

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.

makomk,

are you going to build a version which has the dcm watchdog again or is the dcm watchdog a problem when trying to reach higher hashrates?

spiccioli

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: makomk on August 11, 2012, 11:34:03 AM

Quote from: ?? on ??

What on the board knows to turn the yellow LED on when the FPGA is waiting on work? And if it knows to turn that on, why can't it send a request for more work?

It could do, but none of the existing mining software would understand the request. In theory you could (for instance) have the miner send a nonce of zero, which is never returned by the Icarus miner as a genuine nonce, when it reaches the end of the current work and then modify mining software to understand this.

The current software adds minor complexity to handle the fact that the Icarus bitstream DOESN'T send a completion reply.
It must decide when to abort the work before it is idle, but making it ~99% means fewer requests for work
Sending a completion reply would of course be easier to handle.

There are, however, 2 estimates for the Icarus bitstream:
1) When to abort work (and thus how much work was done if it doesn't find a share before that)
2) How much work was done when the work is aborted due to an LP

Adding a completion message removes the estimate for 1) but not 2)

A reply to an abort saying how much work was done at the time of the abort would also be required to perfect the MH/s calculation (though the estimate is highly accurate now anyway for a normal Icarus and can be made accurate with --icarus-timing for any other Icarus bitstream FPGA)

Interestingly enough, the way that Icarus returns a share and stops is actually the current best method of mining.

The only way to improve it would be for the Icarus to also continue working on the rest of the nonce range - thus the code would keep requesting a reply and keep getting nonce's until it got a 'finished' reply.

Nonce-range processing is good if you have to wait for the processing to complete, but the Icarus method is better.

makomk

hero member

Activity: 686

Merit: 564

Quote from: ?? on ??

What on the board knows to turn the yellow LED on when the FPGA is waiting on work? And if it knows to turn that on, why can't it send a request for more work?

It could do, but none of the existing mining software would understand the request. In theory you could (for instance) have the miner send a nonce of zero, which is never returned by the Icarus miner as a genuine nonce, when it reaches the end of the current work and then modify mining software to understand this.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: spiccioli on August 11, 2012, 03:29:08 AM

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

Yep, I was just adding the extra bit on the end after that in case anyone wanted to know

The mapping (ICAn -> /dev/...) is simple - since cgminer knows it and you can ask it.
Also note that if any /dev/... fails to be detected properly, the ICAn number will not increment past it i.e. there won't be a gap
So the ICAn numbers can change if there are any detection problems

Lethos

sr. member

Activity: 476

Merit: 250

Keep it Simple. Every Bit Matters.

I've only got 2 boards, so don't expect 10 to react the same, but ubuntu and windows do react abit differently to a boards and their tty/com ports.
In ubuntu the order they are plugged in usually chooses their number, lowest first. In windows generally it remembers the one that board had last time.

So the first plugged in will always get 0/1/2/3 and the second always 4/5/6/7.

spiccioli

legendary

Activity: 1378

Merit: 1003

nec sine labore

Quote from: kano on August 10, 2012, 06:24:37 PM

Quote from: spiccioli on August 10, 2012, 01:18:03 PM

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

spiccioli

kano,

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

Quote from: kano on August 10, 2012, 06:24:37 PM

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

Doff

sr. member

Activity: 327

Merit: 250

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: spiccioli on August 10, 2012, 01:18:03 PM

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

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

makomk

hero member

Activity: 686

Merit: 564

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.

Lethos

sr. member

Activity: 476

Merit: 250

Keep it Simple. Every Bit Matters.

Have to say that is a very pretty usb hub.

zefir

donator

Activity: 919

Merit: 1000

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

Activity: 476

Merit: 250

Keep it Simple. Every Bit Matters.

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.

hm

member

Activity: 107

Merit: 10

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

spiccioli

legendary

Activity: 1378

Merit: 1003

nec sine labore

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

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

spiccioli

hm

member

Activity: 107

Merit: 10

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

yohan

sr. member

Activity: 462

Merit: 251

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.

Hpman

full member

Activity: 176

Merit: 100

Quote from: ShadesOfMarble on August 10, 2012, 06:16:05 AM

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

Happily yes. Its > #150.

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