Cairnsmore1 - Quad XC6SLX150 Board

[daemonic]

There is no bitstream that make more the 190Mh/s per pair, if you see more it's a sw problem. cgminer need --icarus-timing option to be set. the unit is giving the miner sw the wrong parameters. You only flashed 1 fpga per pair, the second is not working at the moment.

the miner thinks it have 2 icarus (380Mh/s per board), thats why it shows wrong 380mh/s per pair.

This board can only hash 380mh/s at moment (2x190) not more. Check with you pool stats.

But i will also try the SW6 on, if thats works for me in any way. Thanks!

Yeah i was aware of that, cgminer gets the information in the api to suggest 380 as well, so obviously the bitstream returns the info as if it was a pair, so even the calculated icarus-timing of 2.632=112 is wrong until the pair runs properly.

I guess at 57600 its only really 2x95MH/s so really, it may as well stay on the 2x100 standard bitstream for now

We're constantly learning with this hardware i guess

[sadpandatech]

I'm playing at the moment with different bitstreams.

I wonder why the icarus bitstream "190M_V4.bit" is the same as the "twin_test.bit" ?? I did a binary compare and it's the same 99,9%. Only the date and the directory from where it is compiled is different (comare the first bits in HEX).

@yohan: Is the "twin_test.bit" bitstream the same as the "190M_V4.bit" bitstream from icarus? I thought your team have make some changes to it to get it work?

If it is the same and i think so after the binary compare then read this:

190M for test.
in this bitsteam, the FPGA will continue working until nonce_to, even found a valid nonce.

Found at https://github.com/ngzhang/Icarus/blob/master/Downloads/bitsteam/V4/
Then it makes sense that the board is stop working after some time...


Never the less, i'm testing the 190M_V3.bit, it looks more stable at the moment (0% invalids with both fpga's so far), but know for sure in some hours.

 

[yohan]

I'm playing at the moment with different bitstreams.

I wonder why the icarus bitstream "190M_V4.bit" is the same as the "twin_test.bit" ?? I did a binary compare and it's the same 99,9%. Only the date and the directory from where it is compiled is different (comare the first bits in HEX).

@yohan: Is the "twin_test.bit" bitstream the same as the "190M_V4.bit" bitstream from icarus? I thought your team have make some changes to it to get it work?

If it is the same and i think so after the binary compare then read this:

190M for test.
in this bitsteam, the FPGA will continue working until nonce_to, even found a valid nonce.

Found at https://github.com/ngzhang/Icarus/blob/master/Downloads/bitsteam/V4/
Then it makes sense that the board is stop working after some time...


Never the less, i'm testing the 190M_V3.bit, it looks more stable at the moment (0% invalids with both fpga's so far), but know for sure in some hours.

The twin test is more or less a standard Icarus build. I think the ID and maybe the DCM settings were changed but that was about it.

[ebereon]

The twin test is more or less a standard Icarus build. I think the ID and maybe the DCM settings were changed but that was about it.

Ok, then it's based on the 190M_V4.bit. 190M_V3.bit and less is 100% different when i make a binary compare to the twin_test.bit.
But then that's the problem with twin_test.bit. It will stop working after some time. It is not droping it will complete stop working.

50 minutes so far on the 190M_V3.bit without invalids and pool stat is still rising the Mh/s. 386Mh/s/10 minutes so far.   (fingers crossed!)

[spiccioli]

The twin test is more or less a standard Icarus build. I think the ID and maybe the DCM settings were changed but that was about it.

Ok, then it's based on the 190M_V4.bit. 190M_V3.bit and less is 100% different when i make a binary compare to the twin_test.bit.
But then that's the problem with twin_test.bit. It will stop working after some time. It is not droping it will complete stop working.

50 minutes so far on the 190M_V3.bit without invalids and pool stat is still rising the Mh/s. 386Mh/s/10 minutes so far.   (fingers crossed!)

ebereon,

I stopped mpbm on my card this evening after it had been mining for more than two days without problems, but with low efficiency (dip 1 off, to go 115Kbaud).

The pool I'm mining on, ABC, reported hashing speeds between 180 and 250 MH/s during last two days and the yellow led on hashing FPGAs was on for several seconds every now and then.

So today I've compiled cgminer 2.4.1 (it is not the last one, I know) without OpenCL support, since my thin client has no ATI card inside, and with icarus support and I've started using it a couple of hours ago.

It works better, ABC reports speeds around 330-380 MH/s, I'm looking at it every few minutes, and the yellow led is nearly always off.

I'm starting to think that there are a few different problems:

- the controller FPGA update
- the use of an "old" cgminer (the one compiled for windows by enterpoint) with not so good icarus support
- mpbm and a pool like ABC which keeps closing longpoll connection every 60 seconds
- twin_test.bit not being fine tuned for cairnsmore card

Code:

ICA0                | (5s):353.4 (avg):357.8 Mh/s | A:249 R:0 HW:0 U:2.7/m
 [2012-06-25 23:30:37] Accepted 45811bfc.3ac16f7f ICA 1
ICA1                | (5s):349.7 (avg):357.4 Mh/s | A:239 R:0 HW:0 U:2.6/m
 [2012-06-25 23:31:10] Accepted bb507a3b.2188fe75 ICA 1
ICA1                | (5s):372.0 (avg):357.6 Mh/s | A:240 R:0 HW:0 U:2.5/m
 [2012-06-25 23:31:22] Accepted cfa0a52e.35c33b71 ICA 1
ICA1                | (5s):374.5 (avg):357.5 Mh/s | A:241 R:0 HW:0 U:2.6/m
 [2012-06-25 23:31:25] Accepted e6de1b1d.6e986e8c ICA 0
ICA0                | (5s):377.2 (avg):357.9 Mh/s | A:250 R:0 HW:0 U:2.6/m
 [2012-06-25 23:31:54] Accepted 52c7fe2d.f8bc1159 ICA 1
ICA1                | (5s):378.9 (avg):357.6 Mh/s | A:242 R:0 HW:0 U:2.5/m
 [2012-06-25 23:31:57] Accepted ecec238f.f9d04eba ICA 0
ICA0                | (5s):379.5 (avg):358.2 Mh/s | A:251 R:0 HW:0 U:2.6/m
 [2012-06-25 23:31:58] Accepted f4431cef.e0e9c274 ICA 0
(5s):889.2 (avg):715.5 Mh/s | Q:1680  A:494  R:0  HW:0  E:29%  U:5.1/m

spiccioli

ps. today I received the remaining cards, I've just unpacked one to see it, the board is of a different green, this one is of a "military" grade green... and with low profile heat spreaders. Serial nr. 62-0130, truly beatiful

[rjk]

I can haz pic for comparison pls?

[Gomeler]

So you've got an older Icarus build running at full speed on 1 FPGA of each pair on the boards?

[Keninishna]

So you've got an older Icarus build running at full speed on 1 FPGA of each pair on the boards?

Yup.

[spiccioli]

I can haz pic for comparison pls?

rjk,

this evening when I'm back at home I'll shot a couple of photos.

spiccioli

[daemonic]

50 minutes so far on the 190M_V3.bit without invalids and pool stat is still rising the Mh/s. 386Mh/s/10 minutes so far.   (fingers crossed!)

did you just flash 190M_V3.bit to -P0 and -P3 as per twin_test.bit ?

if so, any special dip settings, using just the normal setup as if it was twin_test.bit, i can only get one pair to connect (COM23) and the other pair (COM22) gives the got 00000000 expected 000187a2 error?

[zefir]

Yohan,

got my first batch of Cairnsmores delivered and would like to ask you for clarification on:

1) Patches for xc3sprog
I can't access the boards from VirtualBox. Since I am using Ubuntu as host system anyhow and xc3sprog is open source, I built the tools for my host system. With all prerequisites met

Code:

xc3sprog -c cm1 -j

claims that it can not find devices using libftdi. Could you please check whether you had to patch the source code for the binaries you delivered with your VirtualBox image - and if so please publish the patches (since it is GPLv2 anyway)?

2) Up/Down cable support
I have a 2x5 IDC ribbon cable at hand and connected two boards over the up/down interface with one board attached via USB to the host. It does not seem to work as I expected, i.e. neither I see 8 ttyUSB ports nor I get a higher hashing rate with the second board attached via up/down cable. Could you please confirm whether the up/down functionality is currently supported at all?

3) FTDI disconnects
One of the four boards I am testing has obvious problems with the FTDI chip. It causes the PC to become non responsive or freezes it completely until I plug the USB cable to the related unit. Tried with several USB hubs and swapped the cables, but it is always the one unit that causes problems. This is the syslog when things go bad:

Code:

Jun 25 19:43:08 d620 kernel: [15947.382768] ftdi_sio 1-4.1:1.2: FTDI USB Serial Device converter detected
Jun 25 19:43:08 d620 kernel: [15947.382833] usb 1-4.1: Detected FT4232H
Jun 25 19:43:08 d620 kernel: [15947.382838] usb 1-4.1: Number of endpoints 2
Jun 25 19:43:08 d620 kernel: [15947.382843] usb 1-4.1: Endpoint 1 MaxPacketSize 512
Jun 25 19:43:08 d620 kernel: [15947.382849] usb 1-4.1: Endpoint 2 MaxPacketSize 512
Jun 25 19:43:08 d620 kernel: [15947.382854] usb 1-4.1: Setting MaxPacketSize 512
Jun 25 19:43:08 d620 kernel: [15947.383210] usb 1-4.1: FTDI USB Serial Device converter now attached to ttyUSB2
Jun 25 19:43:08 d620 kernel: [15947.384871] ftdi_sio 1-4.1:1.3: FTDI USB Serial Device converter detected
Jun 25 19:43:08 d620 kernel: [15947.384942] usb 1-4.1: Detected FT4232H
Jun 25 19:43:08 d620 kernel: [15947.384947] usb 1-4.1: Number of endpoints 2
Jun 25 19:43:08 d620 kernel: [15947.384952] usb 1-4.1: Endpoint 1 MaxPacketSize 512
Jun 25 19:43:08 d620 kernel: [15947.384958] usb 1-4.1: Endpoint 2 MaxPacketSize 512
Jun 25 19:43:08 d620 kernel: [15947.384963] usb 1-4.1: Setting MaxPacketSize 512
Jun 25 19:43:08 d620 kernel: [15947.385366] usb 1-4.1: FTDI USB Serial Device converter now attached to ttyUSB3
Jun 25 19:43:08 d620 kernel: [15947.460411] usb 1-4.2: new high speed USB device using ehci_hcd and address 101
Jun 25 19:43:08 d620 kernel: [15947.544437] usb 1-4.2: device descriptor read/64, error -71
Jun 25 19:43:08 d620 kernel: [15947.732438] usb 1-4.2: device descriptor read/64, error -71
Jun 25 19:43:09 d620 kernel: [15947.908443] usb 1-4.2: new high speed USB device using ehci_hcd and address 102
Jun 25 19:43:09 d620 kernel: [15947.992441] usb 1-4.2: device descriptor read/64, error -71
Jun 25 19:43:09 d620 kernel: [15948.180403] usb 1-4.2: device descriptor read/64, error -71
Jun 25 19:43:09 d620 kernel: [15948.356446] usb 1-4.2: new high speed USB device using ehci_hcd and address 103
Jun 25 19:43:10 d620 kernel: [15948.772066] usb 1-4.2: device not accepting address 103, error -71
Jun 25 19:43:10 d620 kernel: [15948.844451] usb 1-4.2: new high speed USB device using ehci_hcd and address 104
Jun 25 19:43:10 d620 kernel: [15949.260132] usb 1-4.2: device not accepting address 104, error -71
Jun 25 19:43:10 d620 kernel: [15949.260486] hub 1-4:1.0: unable to enumerate USB device on port 2

Are you aware of such problems and is there anything I can do SW wise to bypass it (aside of the udev rules I am already using)?


I considered sending this support request to the support email address you gave, but think that it might be interesting for other users and/or it could already be solved by someone.


Thanks.

[rjk]

I think the VirtualBox versions after 4.0 require an expansion pack to use USB passthrough. Versions prior to 4.0 had USB passthrough only available on the non-OSE (non-open source) editions.

Reference: https://www.virtualbox.org/wiki/Editions

[spiccioli]

Yohan,

got my first batch of Cairnsmores delivered and would like to ask you for clarification on:

1) Patches for xc3sprog
I can't access the boards from VirtualBox. Since I am using Ubuntu as host system anyhow and xc3sprog is open source, I built the tools for my host system. With all prerequisites met

Code:

xc3sprog -c cm1 -j

claims that it can not find devices using libftdi. Could you please check whether you had to patch the source code for the binaries you delivered with your VirtualBox image - and if so please publish the patches (since it is GPLv2 anyway)?

zefir,

you can scp xc3sprog from virtualbox to your ubuntu host and it works right away (maybe adding ia32-libs if you're on a 64 bit ubuntu host system).

You might need to be root to access the boards, see /dev/ttyUSB* access rights.

hope this helps.

spiccioli.

[yohan]

Yohan,

got my first batch of Cairnsmores delivered and would like to ask you for clarification on:

1) Patches for xc3sprog
I can't access the boards from VirtualBox. Since I am using Ubuntu as host system anyhow and xc3sprog is open source, I built the tools for my host system. With all prerequisites met

Code:

xc3sprog -c cm1 -j

claims that it can not find devices using libftdi. Could you please check whether you had to patch the source code for the binaries you delivered with your VirtualBox image - and if so please publish the patches (since it is GPLv2 anyway)?

2) Up/Down cable support
I have a 2x5 IDC ribbon cable at hand and connected two boards over the up/down interface with one board attached via USB to the host. It does not seem to work as I expected, i.e. neither I see 8 ttyUSB ports nor I get a higher hashing rate with the second board attached via up/down cable. Could you please confirm whether the up/down functionality is currently supported at all?

3) FTDI disconnects
One of the four boards I am testing has obvious problems with the FTDI chip. It causes the PC to become non responsive or freezes it completely until I plug the USB cable to the related unit. Tried with several USB hubs and swapped the cables, but it is always the one unit that causes problems. This is the syslog when things go bad:

Code:

Jun 25 19:43:08 d620 kernel: [15947.382768] ftdi_sio 1-4.1:1.2: FTDI USB Serial Device converter detected
Jun 25 19:43:08 d620 kernel: [15947.382833] usb 1-4.1: Detected FT4232H
Jun 25 19:43:08 d620 kernel: [15947.382838] usb 1-4.1: Number of endpoints 2
Jun 25 19:43:08 d620 kernel: [15947.382843] usb 1-4.1: Endpoint 1 MaxPacketSize 512
Jun 25 19:43:08 d620 kernel: [15947.382849] usb 1-4.1: Endpoint 2 MaxPacketSize 512
Jun 25 19:43:08 d620 kernel: [15947.382854] usb 1-4.1: Setting MaxPacketSize 512
Jun 25 19:43:08 d620 kernel: [15947.383210] usb 1-4.1: FTDI USB Serial Device converter now attached to ttyUSB2
Jun 25 19:43:08 d620 kernel: [15947.384871] ftdi_sio 1-4.1:1.3: FTDI USB Serial Device converter detected
Jun 25 19:43:08 d620 kernel: [15947.384942] usb 1-4.1: Detected FT4232H
Jun 25 19:43:08 d620 kernel: [15947.384947] usb 1-4.1: Number of endpoints 2
Jun 25 19:43:08 d620 kernel: [15947.384952] usb 1-4.1: Endpoint 1 MaxPacketSize 512
Jun 25 19:43:08 d620 kernel: [15947.384958] usb 1-4.1: Endpoint 2 MaxPacketSize 512
Jun 25 19:43:08 d620 kernel: [15947.384963] usb 1-4.1: Setting MaxPacketSize 512
Jun 25 19:43:08 d620 kernel: [15947.385366] usb 1-4.1: FTDI USB Serial Device converter now attached to ttyUSB3
Jun 25 19:43:08 d620 kernel: [15947.460411] usb 1-4.2: new high speed USB device using ehci_hcd and address 101
Jun 25 19:43:08 d620 kernel: [15947.544437] usb 1-4.2: device descriptor read/64, error -71
Jun 25 19:43:08 d620 kernel: [15947.732438] usb 1-4.2: device descriptor read/64, error -71
Jun 25 19:43:09 d620 kernel: [15947.908443] usb 1-4.2: new high speed USB device using ehci_hcd and address 102
Jun 25 19:43:09 d620 kernel: [15947.992441] usb 1-4.2: device descriptor read/64, error -71
Jun 25 19:43:09 d620 kernel: [15948.180403] usb 1-4.2: device descriptor read/64, error -71
Jun 25 19:43:09 d620 kernel: [15948.356446] usb 1-4.2: new high speed USB device using ehci_hcd and address 103
Jun 25 19:43:10 d620 kernel: [15948.772066] usb 1-4.2: device not accepting address 103, error -71
Jun 25 19:43:10 d620 kernel: [15948.844451] usb 1-4.2: new high speed USB device using ehci_hcd and address 104
Jun 25 19:43:10 d620 kernel: [15949.260132] usb 1-4.2: device not accepting address 104, error -71
Jun 25 19:43:10 d620 kernel: [15949.260486] hub 1-4:1.0: unable to enumerate USB device on port 2

Are you aware of such problems and is there anything I can do SW wise to bypass it (aside of the udev rules I am already using)?


I considered sending this support request to the support email address you gave, but think that it might be interesting for other users and/or it could already be solved by someone.


Thanks.

Ok I am told we didn't do any patches for the xc3sprog so it is as the original.

Up/Down is not working yet. That will come after our first original bitstream. That will need another controller update.

Are the USB hubs you are using powered with a brick supply or bus powered? You might get this issue on un-powered hubs and it just one board is marginally more power hungary.

Do send this stuff to the emial support.bitcoin at enterpoint.co.uk. Response won't be terribly fast as we are balancing getting on with the new stuff with supporting the temporary things.

On a different point on CGminer we will probably have put a second build  for Windows up on the website shortly. It's specifically for the twin build. Basically the one that is currently was up there is for the 50MHz build and we should have made that a little clearer. The twin build version is more or less the same as Icarus. I think there are a couple of minor switch settings changed but that's all. Both windows versions are now on support page in a single zip download.

When we bring in our own original build bitstream I expect to have quite a lot of changes including a new step of CGminer and new revision of the Controller. The up/down function may, or not, make the first of these versions but if it doesn't it should not be far behind. When we have that it will take a lot of the historical problems of large numbers of USB trying to run on one machine and will start to look much more like our planned long term structure of network nodes. That's a key in to what is coming in Cairnsmore2 where we will extend that idea somewhat more.

[spiccioli]

yohan,

I've just attached a second board to my pc, this is board serial nr 62-104, it has the fast blinking red led on the controller FPGA.

After I've attached it I ran

Code:

# ./xc3sprog -c cm1 -j

on my ubuntu 12.04 pc and it found this second board, but not the first one (62-0008) which was happily hashing in a screen session.

Now, is it that only a single board can be connected and configured at a time (and I was lucky that it found the right one) or is there some other command to issue to be able to see both (or more than one) boards?

I then programmed the twin_test.bit into it and added it to a cgminer 2.4.3 that I've compiled today for this pc without OpenCL/ADL support and with only icarus support enabled.

It is working ok.

Code:

 cgminer version 2.4.3 - Started: [2012-06-26 19:47:44]
--------------------------------------------------------------------------------
 (5s):2212.2 (avg):1453.1 Mh/s | Q:2419  A:872  R:3  HW:0  E:36%  U:10.0/m
 TQ: 3  ST: 7  SS: 3  DW: 24  NB: 7  LW: 0  GF: 26  RF: 5
 Connected to http://pool.abcpool.co with LP as user xxxxxxx
 Block: 0000053e595c7936994e1cea5b0894f8...  Started: [21:12:58]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 329.1/369.9Mh/s | A:242 R:2 HW:0 U:2.76/m
 ICA 1:                | 320.0/360.9Mh/s | A:199 R:0 HW:0 U:2.27/m
 ICA 2:                | 322.6/362.1Mh/s | A:214 R:1 HW:0 U:2.44/m
 ICA 3:                | 339.0/360.1Mh/s | A:217 R:0 HW:0 U:2.48/m
--------------------------------------------------------------------------------

Speed is wrong, but adding

Code:

--icarus-timing short

does not make any difference, it recalibrates itself a few times and then keeps hashing at double speed.

My pools tells me I'm mining at 817 MH/s right now

spiccioli.

[zefir]

Thanks rjk and spicioli, helped me to find the problem with the xc3sprog host build.

Ok I am told we didn't do any patches for the xc3sprog so it is as the original.

Yet, you did

U. Bonnes added support for the cm1 cable to the SVN repository two weeks ago and swapped two digits in the product-id entry: 0x8530 instead of 0x8350

In the cablelist.txt file in the VirtualBox image you fixed that typo, but did not update in the repository.

Since I have no write access to the xc3sprog SVN repo and assume Mr. Bonnes is an Enterpoint fellow, you maybe want to forward him the required patch to fix the issue:

Code:

Index: cablelist.txt
===================================================================
--- cablelist.txt	(revision 679)
+++ cablelist.txt	(working copy)
@@ -9,7 +9,7 @@
 ftdi          ftdi    1500000 0x0403:0x6010:                                       
 ft232h        ftdi    1500000 0x0403:0x6014:                                      
 ft4232h       ftdi    1500000 0x0403:0x6011:
-cm1           ftdi    1500000 0x0403:0x8530:
+cm1           ftdi    1500000 0x0403:0x8350:
 bbv2          ftdi    1500000 0x0403:0x6010::1:0x00:0x10:0x00:0x0                  
 bbv2_2        ftdi    1500000 0x0403:0x6010::2                                     
 dlp2232h      ftdi    1500000 0x0403:0x6010:DLP-2232H:1:0x00:0x10:0x00:0x0

To the Linux folks: forget the VirtualBox fuss and just compile the xc3sprog sources from SVN with the above patch and program your board natively.

Up/Down is not working yet. That will come after our first original bitstream. That will need another controller update.

Are the USB hubs you are using powered with a brick supply or bus powered? You might get this issue on un-powered hubs and it just one board is marginally more power hungary.

Ah, really? That might be the reason, since all tested hubs were passive. Isn't the FTDI powered by the main board power supply? If not, does this imply that powered USB hubs must be used if using more than 3 boards?

Do send this stuff to the emial support.bitcoin at enterpoint.co.uk. Response won't be terribly fast as we are balancing getting on with the new stuff with supporting the temporary things.

Will do. But will also post a copy in this thread, since evidently the community is of great help.

On a different point on CGminer we will probably put a second build  for Windows up on the website shortly. It's specifically for the twin build. Basically the one that is currently up there is for the 50MHz build and we should have made that a little clearer. The twin build version is more or less the same as Icarus. I think there are a couple of minor switch settings changed but that's all.

As long as there are no functional differences to Icarus (i.e. if you could use baud-rate of 115.2k), I'd suggest to leave it as is and just take the Icarus cgminer. Right now I can use it as is with the one DIP switch correctly set and it does not make sense for your SW team to follow the Icarus development all the time when the only difference is the baud-rate.

When we bring in our own original build bitstream I expect to have quite a lot of changes including a new step of CGminer and new revision of the Controller. The up/down function may, or not, make the first of these versions but if it doesn't it should not be far behind. When we have that it will take a lot of the historical problems of large numbers of USB trying to run on one machine and will start to look much more like our planned long term structure of network nodes. That's a key in to what is coming in Cairnsmore2 where we will extend that idea somewhat more.

I understand that, alas that puts me personally in an odd situation: to have the boards running now I need to buy a dozen USB hubs - and dump them only two weeks later when the up/down functionality is supported


Anyhow, your boards are great - you folks know what you are doing and how to satisfy your customers.


Thanks, zefir

[ebereon]

I got an reply from John to my email that I sent to support.

It looks like a stability problem to me, frequency is not stable?...

Yes some of this is frequency stability or more like noise. We think we should be able to work around this with our own bitstream.

So that's the problem we have after flashing a bitstream and cgminer wont work or even only 1 fpga will work. I found that out when i was playing with different icarus bitstreams. Sometimes it worked the first attempt, sometimes i had to power off and reflash the board multible times until it worked again.

So if you don't get it working just unpower and flash again until it works. Yesterday I had to  do this for 3 hours until it worked again...

And yes, i use now the icarus bitstream 190M_V3.bit and it is stable over night (when you get the board working  ).  I let it run now for unlimit time, hopefully i get no powerlose... until enterpoint have a new controller firmware and bitstream. For me the twin_test.bit (same as icarus 190M_V4.bit) is only work for some hours and then stop completly.

With mpbm I had to change the jobinterval to 11.34 on my p2pool! Then the orange led will only flash once for <1 second and the fpga get new work (red flashing led means new work for the fpga). that should maximice the Mh/s.      ....(this is the same as for cgminer with the parameter --icarus-timing short, it will correct the jobinterval)

[ebereon]

190M_V3.bit is running @ 401Mh/s  (1 hour average) on p2pool stats, so far so good.

I will post an update tomorrow.

[Entropy-uc]

I understand that, alas that puts me personally in an odd situation: to have the boards running now I need to buy a dozen USB hubs - and dump them only two weeks later when the up/down functionality is supported

Thanks, zefir

If you are in the US amazon had 10 port hubs for $8 that work just fine for this application.

[TheHarbinger]

28 port powered USB hub.




http://www.amazon.com/exec/obidos/ASIN/B0074024XU/downandoutint-20