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

Minor bitstream revision: http://www.makomk.com/~aidan/shortfin-dcmwd-20120808.zip

If you're already running the previous one, there's probably no point upgrading. The only difference is that with this one you should be able to disable the array clock with switch 3, temp-upload a bitstream, and re-enable the array clock without having to mess around with flashing and power cycling the whole board. Once you've got a bitstream flashed and running it shouldn't make much difference.

what i do is plug only one of the cm1 (which i want to program) in a laptop .uninstall all usb filters ( in the laptop )and install it again for the new board. then that error dissapear

awesome, thanks for the lead

1. Do I need to do this w/ one board plugged in at a time?
2. If I don't, do all boards need to be idle?

I'm getting this error w/ 8 boards mining, 1 board idle.

Could not open FTDI device (using libftdi): unable to claim usb device. Make sur
e the default FTDI driver is not in use
FTD2XX/WIN: Can't set VID/PID to 0403:8350. Expect failure
Using FTD2XX,
JTAG loc.: 0    IDCODE: 0x3401d093      Desc:       XC6SLX150   Rev: C  IR lengt
h: 6
JTAG loc.: 1    IDCODE: 0x3401d093      Desc:       XC6SLX150   Rev: C  IR lengt
h: 6
JTAG loc.: 2    IDCODE: 0x3401d093      Desc:       XC6SLX150   Rev: C  IR lengt
h: 6
JTAG loc.: 3    IDCODE: 0x3401d093      Desc:       XC6SLX150   Rev: C  IR lengt
h: 6

Info can be dug out of this thread:
https://bitcointalksearch.org/topic/modular-python-bitcoin-miner-official-thread-62823

But mind you the thread starts out talking about setting it up with an editable config file but the current version *must* be configured by the web interface found at http://:8832/

Somewhere along the thread it switches over but I don't recall where. Probably around June 2012.

First, set up some "Work sources". There is an example 'work source group' with a few 'work sources' created on first run. (Or, you can leave these be until you have a proven "Worker" setup and you'll just donate a few shares to the author. This would probably be best - start with a 'known working' configuration for the sources until you know your hardware is configured / working.)

Second, create a "Worker" for each 'hash producer' / unit of hardware. E.g., one for a BFL, one for an icarus, apparently two for a CM1.

Explore the menu items and drop down lists.

Easiest to use under Linux, probably (isn't everything ); I have it running on OS X 10.7 where I had to patch two lines for the BFL worker to function under Python 3.

I succeeded to revert controller firmware from glasswalker to v1.3 after numerous tries. Strangely, it never worked with switch3=off & switch6=off. So I turned switch3=off and switch6=on, and voilà .. immediate success. I must have misunderstood the dip switch settings tables.

Then I flashed latest makomk 140 bitstream, but my board #62-0017 has still low or unstable hash rates.
The best bitstream for me was still twin_test, it hashed at its full speed at least for some hours per day, but in the rest of the day it showed very unstable hash rates.

I hope my board can be fixed soon, I already wrote to support on sunday night/monday morning.

I have no idea where to begin w/ configuring MPBM. haven't been able to find any documentation

I am very pleased to report that the bitminter-mining client would now seem to support and work with carinsmore1's solong as they have an icarus compatible bitstream in them.
I can report hashing, valid shares and the mining speed being about what it should be with makomk's 200 and 180mhs shortfin icarus bitstreams.

This is a java-based, extremeley easy to use miner that is tied to a specific pool (bitminter). I mine at this pool and consider it the best one out there. Infact the only non-awesome thing about the client is that it is not open sourced, for obvious reasons.
You can find the beta-client that supports icarus at:

 http://bitminter.com/beta/beta.jnlp

The pools website is:

https://bitminter.com/
It's a mid-sized rapidly growing pool. That is hop-proof, pays tx-fees, merged mining.

To try it out you'll need to:
1. register an account.
2. dl and run the client.
3. select devices->probe all ports for fgpas.
4. wait for ~20sec per fgpa for the client to figure out timings (yes automatic!)
5. feel your ass grow as the coins roll in.

See you on the leaderboards.

[edit]
Looks like there might be some issues to work out, but I cant submit 100% accurate reports for drharibo (pool op and developer of the client) because I dont have a 100% working hub/cable setup (hub#3, cable #13 in try now).
If someone with a rock-solid setup tests this, please drop drharibo a line or two. He can be found here on the forums and on irc at freenode.

No, I did not try different bistreams on this board.

I was using the old twin_test.bit until yesterday evening.

I hope that the dcmwd ones can run higher on pre-50 boards, but I have not tried them yet.

spiccioli

@spiccioli have you only tried the 140 mhz bitstream yet? Did you try the non-dcmwd bitstreams before?
I'm running the non-dcmwd 150 mhz without problems on my #26 but I'm wondering if the dcmwd-bitstreams allow clocks higher than 150 mhz on pre-50 boards.

Shades,

board #0008, 12 hours, ozco.in, makomk dcmwd2 (the one which tries to workaround cairnsmore issues with clocks) 140 MH/s bitstream.


I think there is something wrong in the HW: counter for ICA 0, it seems too much for just 12 hours.

spiccioli.

Any experiences with pre-S/N-50 boards yet? I cannot test any other bitstream atm because I cannot flip over the dip switch remotely

my biggest bet is on the usb hub  because the suspicious cable works when i unpluged all the others usb cables from the usb and make a power cycle. but your suggestion will be consider . Thank you.

Try a diff usb cable, I would get this error with bad usb cables.

no no i dont wanna do that. it was only a way of "replicate" an error similar to what i get sometimes ( of course doing normal things . and to see if anyone could see any clue in why i'm getting an administrative rights error.

maybe when my fpga is frozen doesnt free any resource and cgminer thinks it is still  busy and show me that error.  it seems weird to me that no body has my error it was all.

Regards.  

it isn't an issue of them working and just not being able to see em, cgminer gives an unexpected error and windows closes it.

Thanks. I'm running with icarus-timing=long now. Now MHS av and U are pretty close, even after just 15 minutes.

Which of the values "Hs", "W" and "fullnonce" do I have to pass to icarus-timing to get an accurate reading from the beginning? Found it.

As I mentioned before

If the device really does hash at the same speed as an Icarus Rev3, it will show correctly.
If it doesn't, then you need to know the timing value for the device (which you can work out with 'long' or 'short') or always run in 'long' or 'short' mode, to get it to show correctly.

The number of shares per piece of work is random, including possibly 0
When a piece of work has no shares, cgminer has to decide when to stop working on it before it finishes so it doesn't end up idle
The Icarus bitstream doesn't send back a message when it finishes, it just goes idle
So the timing determines how long that is and thus how long to wait for an answer and then give up and overwrite it with a new piece of work

How many hashes it did up to the point when it aborted the work is thus estimated based on how fast the device hashes.
So if the timing value is wrong, it will report the MH/s incorrectly

Also, if the timing says it is slower than it really is, it only takes it to be incorrect by ~1% and it will be idle at the end each time a piece of work has no shares - and thus this will reduce the performance and the number of shares it finds

However, if the device hashes slower than an Icarus Rev3, then it wont ever be idle, it will just report the MH/s higher than it really is but with no negative affect on the shares
Though, if it really is aborting work too early, it will have a small negative affect, but usually less than the screen display accuracy ...

FYI: all mining programs that mine on a device with the current Icarus bitstream must perform this 'estimate hash calculation'

For me it's not... Reported hashrate is 700 MH/s whereas U clearly indicated that the "real" performance is only 600 MH/s. Which is what one would expect from the 150 Mhz bitstream.

I'm currently unable to test any other bitstreams because the board is running in a remote location and I don't want to install VirtualBox risking to kill my network connection.

With BFGMiner, you could just scroll the unit list with the Up/Down arrow keys...