Bitcoin Forum
December 11, 2016, 02:31:15 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 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 ... 129 »
  Print  
Author Topic: Cairnsmore1 - Quad XC6SLX150 Board  (Read 251459 times)
norulezapply
Sr. Member
****
Offline Offline

Activity: 475


View Profile
July 13, 2012, 07:00:20 PM
 #1261

Can someone with multiple boards please give me some help with getting both of mine upto speed?

I have 2 and occassionally I get them up to a total of ~710Mh/s, but most of the time I'm only getting ~520Mh/s average total (so that's 260Mh/s per board).


I have both boards flashed with the twin_test bitstream and the rev 1.3 controller.

The boards are plugged into a USB hub with two separate USB cables.

I am using a RaspberryPi to run cgminer 2.4.3 and provide work to the boards.

I'm running a SINGLE instance of cgminer 2.4.3 for both boards.

Command line is something like "-S /dev/ttyUSB2 -S /dev/ttyUSB3 -S /dev/ttyUSB6 -S /dev/ttyUSB7". (i'm not using the icarus-timing option)

Dip switches are set to the defaults for the twin_test running mode bitstream.


Can someone please give me a hand to figure out why I'm not getting the full hashrate? I have Skype/MSN if someone would rather speak about it over that.

At first I was just going to wait until the stable bitstream is released, but I figured I may as well fix it now just incase.

Thank you in advance

If my post helped, I'll happily accept a few bitmills!   15rGg6A1JFZV3b7TTbtpAaiYGdUD1e1oAm
1481423475
Hero Member
*
Offline Offline

Posts: 1481423475

View Profile Personal Message (Offline)

Ignore
1481423475
Reply with quote  #2

1481423475
Report to moderator
1481423475
Hero Member
*
Offline Offline

Posts: 1481423475

View Profile Personal Message (Offline)

Ignore
1481423475
Reply with quote  #2

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

Activity: 1376

nec sine labore


View Profile
July 13, 2012, 07:16:18 PM
 #1262

Can someone with multiple boards please give me some help with getting both of mine upto speed?

I have 2 and occassionally I get them up to a total of ~710Mh/s, but most of the time I'm only getting ~520Mh/s average total (so that's 260Mh/s per board).


Hard to say (at least for me), norulezapply, since you're using a rather "uncommon" platform to mine (raspberry).

Anyway, in my experience, the only difference is in the controller FPGA firmware, 1.3 seems better in achieving an uniform U: across all boards (but you already have it).

Here are mine

Code:
cgminer version 2.4.3 - Started: [2012-07-13 07:26:50]
--------------------------------------------------------------------------------
 (5s):7513.4 (avg):7328.9 Mh/s | Q:114056  A:41757  R:40  HW:0  E:37%  U:50.9/m
 TQ: 20  ST: 22  SS: 2  DW: 2324  NB: 107  LW: 311  GF: 90  RF: 1
 Connected to http://pool.abcpool.co with LP as user  .......
 Block: 0000012b95cd60eeffec7427a809b285...  Started: [21:02:32]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 379.8/366.8Mh/s | A:2120 R:3 HW:0 U: 2.59/m
 ICA 1:                | 379.8/366.5Mh/s | A:1976 R:1 HW:0 U: 2.41/m
 ICA 2:                | 379.9/367.1Mh/s | A:2114 R:2 HW:0 U: 2.58/m
 ICA 3:                | 379.9/366.7Mh/s | A:2013 R:3 HW:0 U: 2.46/m
 ICA 4:                | 379.9/366.6Mh/s | A:2108 R:4 HW:0 U: 2.57/m
 ICA 5:                | 380.0/366.7Mh/s | A:2092 R:1 HW:0 U: 2.55/m
 ICA 6:                | 379.9/366.2Mh/s | A:2172 R:0 HW:0 U: 2.65/m
 ICA 7:                | 379.9/366.1Mh/s | A:2139 R:2 HW:0 U: 2.61/m
 ICA 8:                | 379.8/366.1Mh/s | A:2080 R:1 HW:0 U: 2.54/m
 ICA 9:                | 379.8/366.4Mh/s | A:1848 R:2 HW:0 U: 2.25/m
 ICA 10:                | 379.9/365.9Mh/s | A:2092 R:3 HW:0 U: 2.55/m
 ICA 11:                | 379.8/366.1Mh/s | A:2100 R:5 HW:0 U: 2.56/m
 ICA 12:                | 379.9/366.4Mh/s | A:2079 R:1 HW:0 U: 2.54/m
 ICA 13:                | 379.9/366.2Mh/s | A:2192 R:3 HW:0 U: 2.67/m
 ICA 14:                | 379.7/366.0Mh/s | A:2016 R:3 HW:0 U: 2.46/m
 ICA 15:                | 379.9/366.8Mh/s | A:2109 R:0 HW:0 U: 2.57/m
 ICA 16:                | 379.8/366.4Mh/s | A:2141 R:1 HW:0 U: 2.61/m
 ICA 17:                | 379.8/367.4Mh/s | A:2128 R:0 HW:0 U: 2.60/m
 ICA 18:                | 379.9/366.2Mh/s | A:2149 R:3 HW:0 U: 2.62/m
 ICA 19:                | 379.9/366.9Mh/s | A:2090 R:2 HW:0 U: 2.55/m
--------------------------------------------------------------------------------

As you can see I've got a U: around 2.30-2.60, I'm using cgminer 2.4.3 as well on an ubuntu low power pc.

Note that I have a FPGA which is underperforming the others (it is ICA 9 here) and which has always underperformed no matter what controller revision I was using.

I'm starting cgminer like this

Code:
./cgminer -S /dev/ttyUSB2 -S /dev/ttyUSB3 -S /dev/ttyUSB6 -S /dev/ttyUSB7 -S /dev/ttyUSB10 -S /dev/ttyUSB11 -S /dev/ttyUSB14 -S /dev/ttyUSB15 -S /dev/ttyUSB18 -S /dev/ttyUSB19 -S /dev/ttyUSB22 -S /dev/ttyUSB23 -S /dev/ttyUSB26 -S /dev/ttyUSB27 -S /dev/ttyUSB30 -S /dev/ttyUSB31 -S /dev/ttyUSB34 -S /dev/ttyUSB35 -S /dev/ttyUSB38 -S /dev/ttyUSB39 -o http://pool.abcpool.co -O ......  -o http://p2pool.soon.it:9332 -O ..... -Q 20 --failover-only

spiccioli.


edit:
is your usb hub powered or unpowered?
norulezapply
Sr. Member
****
Offline Offline

Activity: 475


View Profile
July 13, 2012, 07:21:45 PM
 #1263

Can someone with multiple boards please give me some help with getting both of mine upto speed?

I have 2 and occassionally I get them up to a total of ~710Mh/s, but most of the time I'm only getting ~520Mh/s average total (so that's 260Mh/s per board).


Hard to say (at least for me), norulezapply, since you're using a rather "uncommon" platform to mine (raspberry).

Anyway, in my experience, the only difference is in the controller FPGA firmware, 1.3 seems better in achieving an uniform U: across all boards (but you already have it).

Here are mine

-snip-

As you can see I've got a U: around 2.30-2.60, I'm using cgminer 2.4.3 as well on an ubuntu low power pc.

Note that I have a FPGA which is underperforming the others (it is ICA 9 here) and which has always underperformed no matter what controller revision I was using.

I'm starting cgminer like this

-snip-

spiccioli.

Thank you for the info Smiley

Seems like your setup is quite similar to mine though (I don't think using the Raspberry Pi should affect anything, but maybe I'm wrong).

I'll try using a few different USB cables tomorrow or something.

EDIT: I am using a powered USB hub - specifically this one : http://www.7dayshop.com/catalog/product_info.php?cPath=777_5&products_id=113169

If my post helped, I'll happily accept a few bitmills!   15rGg6A1JFZV3b7TTbtpAaiYGdUD1e1oAm
spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
July 13, 2012, 07:25:18 PM
 #1264


Thank you for the info Smiley

Seems like your setup is quite similar to mine though (I don't think using the Raspberry Pi should affect anything, but maybe I'm wrong).

I'll try using a few different USB cables tomorrow or something.

Norulezapply,

what is your U: number after a few hours on mining?

If your usb hub is not powered I'd try a powered one first.

spiccioli
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
July 13, 2012, 07:29:33 PM
 #1265

I only have bare details but one bug we appeared to see today on CGminer, running on Win7, was that if the dos box didn't have enough lines defined for the numbers of CM1 s running it caused a problem on the ones that could be fitted in on the bos box. So make sure you have eniough lines in the dos box if you are running a large rig.
norulezapply
Sr. Member
****
Offline Offline

Activity: 475


View Profile
July 13, 2012, 07:35:51 PM
 #1266


Thank you for the info Smiley

Seems like your setup is quite similar to mine though (I don't think using the Raspberry Pi should affect anything, but maybe I'm wrong).

I'll try using a few different USB cables tomorrow or something.

Norulezapply,

what is your U: number after a few hours on mining?

If your usb hub is not powered I'd try a powered one first.

spiccioli

I have a powered USB hub.

Here's a "screenshot" from my rig after ~20 hours:

Code:
cgminer version 2.4.3 - Started: [2012-07-13 00:43:11]
--------------------------------------------------------------------------------
 (5s):1676.7 (avg):1491.3 Mh/s | Q:6826  A:7881  R:1  HW:0  E:115%  U:6.6/m
 TQ: 4  ST: 5  SS: 0  DW: 1037  NB: 143  LW: 30811  GF: 0  RF: 0
 Connected to ozco.in with LP as user snip
 Block: 000007ce5cd122fcfd0163d16d5c742d...  Started: [20:21:18]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 379.9/373.0Mh/s | A:1383 R:0 HW:0 U: 1.16/m
 ICA 1:                | 379.9/372.6Mh/s | A:1252 R:0 HW:0 U: 1.05/m
 ICA 2:                | 380.0/373.0Mh/s | A:2624 R:0 HW:0 U: 2.21/m
 ICA 3:                | 379.8/372.8Mh/s | A:2622 R:1 HW:0 U: 2.21/m
--------------------------------------------------------------------------------

 [2012-07-13 20:30:27] Accepted fadb8f39.9ae9fafc ICA 3
 [2012-07-13 20:30:28] Accepted d9c24b95.8e05a5fe ICA 1
 [2012-07-13 20:30:29] Accepted cd961974.b4c4ca52 ICA 3
 [2012-07-13 20:30:47] Accepted b8a4f7f6.46f1c8a1 ICA 3
 [2012-07-13 20:30:48] Accepted 63c28bba.b8d6352f ICA 2
 [2012-07-13 20:31:05] Accepted 526d5521.fd5beeb7 ICA 0
 [2012-07-13 20:31:24] Accepted 28843c4c.7492b005 ICA 3
 [2012-07-13 20:31:33] Accepted e1658fd4.fffd4e2d ICA 3
 [2012-07-13 20:31:37] Accepted d2409553.dee9a890 ICA 1
 [2012-07-13 20:32:04] Accepted 3a072287.dcd450a3 ICA 3

As you can see, ICA 0/1 is running approximately half the speed of ICA2/3.

The lights on the suspect board are orange for a large majority of the time, where as the other board is rarely ever orange.

At first I thought it could help if I ran two separate instances of cgminer but I haven't tried this yet.

Regards

If my post helped, I'll happily accept a few bitmills!   15rGg6A1JFZV3b7TTbtpAaiYGdUD1e1oAm
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
July 13, 2012, 07:50:55 PM
 #1267


Thank you for the info Smiley

Seems like your setup is quite similar to mine though (I don't think using the Raspberry Pi should affect anything, but maybe I'm wrong).

I'll try using a few different USB cables tomorrow or something.

Norulezapply,

what is your U: number after a few hours on mining?

If your usb hub is not powered I'd try a powered one first.

spiccioli

We have started modelling a mid size mining rig so that we can firstly test boards exactly the way Bitcoiners use them but also so we can see some of the system level problems that some of you get. This is an additional test to our normal testing and we aiming put all line boards through that test. At the moment it's windows based but we will probably run a second rig on LInux as well. We have a few observations about using USB which may help you all get running.

First observation is that powering the 12V first befor plugging in USB is good way to do it.

Our second observation was using a cheap 13 way USB hub we bought to test http://www.ebuyer.com/279682-xenta-13-port-usb2-0-hub-mains-powered-n-uh1301 if we switch off using the switch on the hub until the 12V is up and settled gave good results.

Third observation is that our 20-30 unit test rig took 10-20 minutes to enumerate the USB structure and if you try tio do anything before that is complete one or more boards will get screwed up and you can not do anything to get it back short of doing the entire start up sequence again.

Out of what we saw today we have a couple of ideas to add to the Controller that may help stability with the twin bitstream and we will try those over the next couple of days. If they are of benefit a release of Controller will follow.

spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
July 13, 2012, 07:56:36 PM
 #1268


Thank you for the info Smiley

Seems like your setup is quite similar to mine though (I don't think using the Raspberry Pi should affect anything, but maybe I'm wrong).

I'll try using a few different USB cables tomorrow or something.

Norulezapply,

what is your U: number after a few hours on mining?

If your usb hub is not powered I'd try a powered one first.

spiccioli

I have a powered USB hub.

Here's a "screenshot" from my rig after ~20 hours:

Code:
cgminer version 2.4.3 - Started: [2012-07-13 00:43:11]
--------------------------------------------------------------------------------
 (5s):1676.7 (avg):1491.3 Mh/s | Q:6826  A:7881  R:1  HW:0  E:115%  U:6.6/m
 TQ: 4  ST: 5  SS: 0  DW: 1037  NB: 143  LW: 30811  GF: 0  RF: 0
 Connected to ozco.in with LP as user snip
 Block: 000007ce5cd122fcfd0163d16d5c742d...  Started: [20:21:18]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 379.9/373.0Mh/s | A:1383 R:0 HW:0 U: 1.16/m
 ICA 1:                | 379.9/372.6Mh/s | A:1252 R:0 HW:0 U: 1.05/m
 ICA 2:                | 380.0/373.0Mh/s | A:2624 R:0 HW:0 U: 2.21/m
 ICA 3:                | 379.8/372.8Mh/s | A:2622 R:1 HW:0 U: 2.21/m
--------------------------------------------------------------------------------

 [2012-07-13 20:30:27] Accepted fadb8f39.9ae9fafc ICA 3
 [2012-07-13 20:30:28] Accepted d9c24b95.8e05a5fe ICA 1
 [2012-07-13 20:30:29] Accepted cd961974.b4c4ca52 ICA 3
 [2012-07-13 20:30:47] Accepted b8a4f7f6.46f1c8a1 ICA 3
 [2012-07-13 20:30:48] Accepted 63c28bba.b8d6352f ICA 2
 [2012-07-13 20:31:05] Accepted 526d5521.fd5beeb7 ICA 0
 [2012-07-13 20:31:24] Accepted 28843c4c.7492b005 ICA 3
 [2012-07-13 20:31:33] Accepted e1658fd4.fffd4e2d ICA 3
 [2012-07-13 20:31:37] Accepted d2409553.dee9a890 ICA 1
 [2012-07-13 20:32:04] Accepted 3a072287.dcd450a3 ICA 3

As you can see, ICA 0/1 is running approximately half the speed of ICA2/3.

The lights on the suspect board are orange for a large majority of the time, where as the other board is rarely ever orange.

At first I thought it could help if I ran two separate instances of cgminer but I haven't tried this yet.

Regards

Norulez,

I don't think running two instances of cgminer will give you more speed, the fact that the orange led is mostly ON means that FPGAs aren't hashing (when you power them you should have FPGA0/3 yellow/orange led on and FPGA1/2 yellow and red leds on).

Are you sure that board hosting ICA 0/1 has SW6/1 off? (115Kbaud virtual com port speed).

See http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html image labeled "TWIN BUILD (ICARUS) RUNNING DIP SETTINGS"

Did you try to reflash twin_test on it?

spiccioli
spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
July 13, 2012, 08:03:13 PM
 #1269

We have started modelling a mid size mining rig so that we can firstly test boards exactly the way Bitcoiners use them but also so we can see some of the system level problems that some of you get. This is an additional test to our normal testing and we aiming put all line boards through that test. At the moment it's windows based but we will probably run a second rig on LInux as well. We have a few observations about using USB which may help you all get running.

First observation is that powering the 12V first befor plugging in USB is good way to do it.

Our second observation was using a cheap 13 way USB hub we bought to test http://www.ebuyer.com/279682-xenta-13-port-usb2-0-hub-mains-powered-n-uh1301 if we switch off using the switch on the hub until the 12V is up and settled gave good results.

Third observation is that our 20-30 unit test rig took 10-20 minutes to enumerate the USB structure and if you try tio do anything before that is complete one or more boards will get screwed up and you can not do anything to get it back short of doing the entire start up sequence again.

Out of what we saw today we have a couple of ideas to add to the Controller that may help stability with the twin bitstream and we will try those over the next couple of days. If they are of benefit a release of Controller will follow.

Yohan,

given that  boards can be switched on without any usb cable attached is it possible to have the controller FPGA  not require/take power from usb cable?

spiccioli
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
July 13, 2012, 08:58:49 PM
 #1270

We have started modelling a mid size mining rig so that we can firstly test boards exactly the way Bitcoiners use them but also so we can see some of the system level problems that some of you get. This is an additional test to our normal testing and we aiming put all line boards through that test. At the moment it's windows based but we will probably run a second rig on LInux as well. We have a few observations about using USB which may help you all get running.

First observation is that powering the 12V first befor plugging in USB is good way to do it.

Our second observation was using a cheap 13 way USB hub we bought to test http://www.ebuyer.com/279682-xenta-13-port-usb2-0-hub-mains-powered-n-uh1301 if we switch off using the switch on the hub until the 12V is up and settled gave good results.

Third observation is that our 20-30 unit test rig took 10-20 minutes to enumerate the USB structure and if you try tio do anything before that is complete one or more boards will get screwed up and you can not do anything to get it back short of doing the entire start up sequence again.

Out of what we saw today we have a couple of ideas to add to the Controller that may help stability with the twin bitstream and we will try those over the next couple of days. If they are of benefit a release of Controller will follow.

Yohan,

given that  boards can be switched on without any usb cable attached is it possible to have the controller FPGA  not require/take power from usb cable?

spiccioli

The board has a common "5V" rail which can be fed from either USB 5V or 5V generated from the 12V. The 2 alternative sources use in-line diodes to avoid back feeding to the other side. Which one supplies the current actually depends on which is the highest voltage. Notionally they are the same voltage but there will nearly always be a difference. Often the USB will often be lower because of cabling loss so the 12V will supply often or even share the load. However this is not guaranteed. If your hub power sits at a slightly higher voltage of course it will try to supply all or some of the current. Actually that might be an interesting thing to try. Running a hub from a bench supply at say 4.8V might allow the onboard 5V derived from 12V to always dominate.

Another way is to modify a USB cable so that 5V isn't supplied (cut the right wire maybe in a USB cable) or is regulated down to say 4.8V by an in line regulator or even a simple diode in-line to provide an extra voltage drop. Knobbling the hub supply voltage down to 4.8V might be somewhat simplier.

At the board level changing the USB side diode to one with a bigger drop would work as well.

There is another USB issue directly related to the Twin (Icarus) build. This design appears lock up if it receives a slightly corrupted message. You might get this if CGminer started sending messages before a FPGA was fully powered and one of the things we are going to try is to block messages in the Controller until we think the FPGA is fully powered and configured. This is why CGminer should not be started too early at the moment but might explain a range of things that people have observed. This won't be a problem in ur own bitstream where messages will be checked by the design before any operating action is taken.

ebereon
Sr. Member
****
Offline Offline

Activity: 407


View Profile
July 13, 2012, 11:24:54 PM
 #1271

I want to share my experiences of the last two days with my new CM1 boards.

First of all they are working great @ 3900Mh/s. Not as my early board (SN# 15), witch was a pain!

TML Bitstream: Is not working at the moment. I get the same results as I already posted in Ellentyrell's thread.

I'm working unter Win7 32bit.
I started with cgminer, but after 5 hours one board disappeared and some where realy slow U 1.9 and 2.1 and so on. I tried ep cgminer and cgminer 2.4.3.
I see a problem using cgminer with the CM1 board at this stage. It's more incompatible or have an bug or somthing. Also you don't see Invalid Shares witch is bad, you don't know why your FPGA is slow etc.

So I started again with MPBM. Here I can see Invalid Shares, I can Flash the CM1 boards in VM and after I reconnect them to windows, MPBM start hashing on it rigth away without a restart or something.

Then I was trying to get the most out of my Boards. MPBM was running with under 1% Invalid Shares in one hour with the Twin_test.bit Bitstream. I started the VM and flashed ALL Boards to the 200M_beta.bit Icarus Bitstream. Realy nice, after each board was flashed, MPBM started hashing with them without anything to do.

I was waiting again 1 hour to check the Invalid Shares and flashed the FPGAs that had more then 1% back to twin_test.bit.

Here my results:


as you can see only 2 FPGAs with 200M_beta.bit (200Mh/s) have <1% Invalid Shares, the others have the twin_test.bit (190Mh/s).

From 20 FPGAs have 15 200M_beta.bit and only 5 twin_test.bit


I have made also some modifications the my cairnsmore worker for MPBM. I change some settings to meet the CM1 board at this stage. It restarts the worker earlyer when the FPGA have no share summitted in an spezified timeframe. Some wait times have been shorten to make sure an disconnected CM1 board get faster reconnected and so on.

You can download the modified cairnsmore worker here.


One more problem I had was, when I was "searching" the right Com ports for the FPGAs the boards become unresponsive. I think when I started the miner on a Com port related to the Jtag or SPI port, the FTDI chip scrwed up until complette power down. In windows this is a pain with 40 USB devices automaticly creates a Com port XX, so you don't know what it is and you need to test it if it's a FPGA or not. We need here something changed in the driver or what ever.

I hope this helps someone to get the most out of the CM1 board.

Happy mining!
eb


EDIT:
Set the Jobinterval as follows:
twin_test.bit (190Mh/s) = 11.33
200M_beta.bit (200Mh/s) = 10.6

The orange LED's should only "flash" <1 second betwen the jobs!
this time
Jr. Member
*
Offline Offline

Activity: 55


View Profile
July 14, 2012, 03:37:12 AM
 #1272

I'm trying to get mpbm working on windows using windows-runtime-v0.1.0beta.zip and I get an error when trying to run mpbm.exe from the command line. I've never used mpbm before so I'm probably making a basic error.




zefir
Donator
Hero Member
*
Offline Offline

Activity: 917



View Profile
July 14, 2012, 08:01:08 AM
 #1273


The board has a common "5V" rail which can be fed from either USB 5V or 5V generated from the 12V. The 2 alternative sources use in-line diodes to avoid back feeding to the other side. Which one supplies the current actuall depends on which is the highest voltage. Notionall they are the same voltage but there will nearly always be a difference. Often the USB will often be lower because of cabling loss so the 12V will supply often or even share the load. However this is not guaranteed. If your hub power sits at a slightly higher voltage of course it will try to supply all or some of the current. Actually that might be an interesting thing to try. Running a hub from a bench supply at say 4.8V might allow the onboard 5V derived from 12V to always dominate.

Another way is to modify a USB cable so that 5V isn't supplied (cut the right wire maybe in a USB cable) or is regulated down to say 4.8V by an in line regulator or even a simple diode in-line to provide an extra voltage drop. Knobbling the hub supply voltage down to 4.8V might be somewhat simplier.

At the board level changing the USB side diode to one with a bigger drop would work as well.

Yohan, I asked bitcoin.support already about a related issue. Are you saying that cutting the 5V line in the USB cable connecting to the PC and using non-powered USB hubs should then work flawlessly? Currently my biggest problem is that one of the powered USB hubs disconnects in the middle of the night and stopps the whole array from mining, which from the Linux syslog seems to be caused by over-current prevention. You earlier said that as soon as the PSU is powered on, the FTDI is not fed by the USB bus power, AFAIR.

yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
July 14, 2012, 09:14:56 AM
 #1274


The board has a common "5V" rail which can be fed from either USB 5V or 5V generated from the 12V. The 2 alternative sources use in-line diodes to avoid back feeding to the other side. Which one supplies the current actuall depends on which is the highest voltage. Notionall they are the same voltage but there will nearly always be a difference. Often the USB will often be lower because of cabling loss so the 12V will supply often or even share the load. However this is not guaranteed. If your hub power sits at a slightly higher voltage of course it will try to supply all or some of the current. Actually that might be an interesting thing to try. Running a hub from a bench supply at say 4.8V might allow the onboard 5V derived from 12V to always dominate.

Another way is to modify a USB cable so that 5V isn't supplied (cut the right wire maybe in a USB cable) or is regulated down to say 4.8V by an in line regulator or even a simple diode in-line to provide an extra voltage drop. Knobbling the hub supply voltage down to 4.8V might be somewhat simplier.

At the board level changing the USB side diode to one with a bigger drop would work as well.

Yohan, I asked bitcoin.support already about a related issue. Are you saying that cutting the 5V line in the USB cable connecting to the PC and using non-powered USB hubs should then work flawlessly? Currently my biggest problem is that one of the powered USB hubs disconnects in the middle of the night and stopps the whole array from mining, which from the Linux syslog seems to be caused by over-current prevention. You earlier said that as soon as the PSU is powered on, the FTDI is not fed by the USB bus power, AFAIR.

To be honest we have not tried cutting the USB 5V power line yet. or going back to un-powered hubs. Un-powered hubs could still have an issue if the power sequence is done wrongly i.e. before 12V is up and supplying controller power. It would certainly be worth trying with the proviso of powering the 12V first. Yesterday we happened to fit the USB hubs that have a switch and didn't turn on hub is up and stable. 10 more of those hubs arrived this morning and we will build a bigger system as we get more boards off the line to test.

We really started to get some more ideas yesterday as we were starting to get our larger model system together and we did some more sytem level thinking and testing. We had build a 10 boards system about a week ago the boards from that then went to ebereon as tested working boards. his was an additional test over what we did previously but we are now adopting that as standard. That was the previously biggest system we had to play with to see some of these sorts of issues. We think that there are a number of the issues in larger setups that are mainly a mixture of USB and CGminer issues. Like the window size problem we saw yesterday. I wouldn't have thought of that one unless I seen it with my own eyes.

The fact that CGminer isn't capable of coping with losing one processing element is basically crap. We do want to look at that but it's a trade between making forward progress on bitstream and associated items and doing this support work. We only had 1 day in reality this week on the bitstream side so it hasn't gone far this week.We do now have have a rig test that may form a basis for something better and we will probably make that test available to you and other big rig owners for system diagnostics and on-site test.

We going to see if we can also make things better in the controller for power-up and overnight lockups. One of the major issues with the twin bitstream is that if gets any charactors sent to it down the com line it will react. if that is a non-real message or a message is corrupted that usually causes a lockup/non responder. We know this can be an issue if CGminer starts sending coms before the system is ready. Harder to sort is overnight issues and that depends on whether that is the actual problem. It could be a mains power dip upsetting the USB or a coms issue. If it is a coms issue then we almost need to check messages in the controller before passing on to the array and also the other way. One other unlikely possibility and a weakness in the Icarus setup is that the coms of the second chip can interfere with those of the first chip. We don't think that should happen if you have dip switches set right and second FPGA is in reset. Here there is a possibility of simply clearing the config SPI flash of the 2 non-working FPGAs so there is nothing to interfere. Actually that gives me a thought of whether we can remove power from these 2 devices. You do need power for JTAG to work but otherwise it might work. A line parking build might do the same. I'll look at that as an option as it can be done quiclkly.




Often in bus powered systems the drop on the cabling and hubs would make the 12V derived fed win. However a powered hub might make this different. It's good and bad. First because
ebereon
Sr. Member
****
Offline Offline

Activity: 407


View Profile
July 14, 2012, 10:36:33 AM
 #1275

I'm trying to get mpbm working on windows using windows-runtime-v0.1.0beta.zip and I get an error when trying to run mpbm.exe from the command line. I've never used mpbm before so I'm probably making a basic error.
Hey "this time",

Please make sure you can type "python -h" as a command line. If yes you have to type "python run-mpbm.py" to start MPBM. If not you have to put the installation directory of python in the %PATH% variable and start a new command line window and try again.

I have installed:
- python 2.7.x
- pyserial win32 (additional package)
- pyusb win32 (additional package)
- latest git mpbm (not 0.1.0beta!)

If you need more help just PM me and I can help you also via skype in german Wink

eb
Entropy-uc
Hero Member
*****
Offline Offline

Activity: 560


View Profile
July 14, 2012, 12:19:16 PM
 #1276


The board has a common "5V" rail which can be fed from either USB 5V or 5V generated from the 12V. The 2 alternative sources use in-line diodes to avoid back feeding to the other side. Which one supplies the current actuall depends on which is the highest voltage. Notionall they are the same voltage but there will nearly always be a difference. Often the USB will often be lower because of cabling loss so the 12V will supply often or even share the load. However this is not guaranteed. If your hub power sits at a slightly higher voltage of course it will try to supply all or some of the current. Actually that might be an interesting thing to try. Running a hub from a bench supply at say 4.8V might allow the onboard 5V derived from 12V to always dominate.

Another way is to modify a USB cable so that 5V isn't supplied (cut the right wire maybe in a USB cable) or is regulated down to say 4.8V by an in line regulator or even a simple diode in-line to provide an extra voltage drop. Knobbling the hub supply voltage down to 4.8V might be somewhat simplier.

 Here there is a possibility of simply clearing the config SPI flash of the 2 non-working FPGAs so there is nothing to interfere. Actually that gives me a thought of whether we can remove power from these 2 devices. You do need power for JTAG to work but otherwise it might work. A line parking build might do the same. I'll look at that as an option as it can be done quiclkly.

Often in bus powered systems the drop on the cabling and hubs would make the 12V derived fed win. However a powered hub might make this different. It's good and bad. First because

Cutting current draw from the USB when the 12V line is live would definitely be a good thing.  Right now, bad things happen when you exceed the current capacity of the the USB input hubs.  My best guess is that you need >150 mA per port to be safe.  I am supplying my system with 250 mA / port to be safe.

Presently I'm dealing with a very strange issue.  After adding a few boards several of the boards already on the chain seem to have reverted to the ship test bitstream.  In idle and in operation some boards have blue LEDs live 100% of the time, which I have only seen with ship_test.  All boards had the flash programmed to twin_test before being connected.  I have recovered some by reprogramming twin_test again.  But a few board won't take the programming and throw USB errors.

The programming is being done with an independent Win7 x64 system, and I have been able to program other boards without problems.
ebereon
Sr. Member
****
Offline Offline

Activity: 407


View Profile
July 14, 2012, 12:29:29 PM
 #1277

Are you using the identical dip settings for mpbm as specified for cgminer?
SW1/SW6 = yes
SW2/SW3/SW4/SW5 = shipping bitstream (I don't know why, but they came with that from enterpoint, I leaved it)

Why switch back for a 1% invalid rate?  Your net hashes would still be higher on the 200M bitstream wouldn't they?
After one hour the ones I switched back had 5%-8% invalids. All others with <1% still have 200M_beta.bit.

Do you have a link for the 200M bitstream?
Please take a look in the Icarus thread.  Wink

What controller version are you running?
Allways the latest, 1.3.

Very interesting results.  I'm going to try switching over to mpbm this weekend.
I hope you will get also nice results!  Cheesy

eb
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
July 14, 2012, 12:40:13 PM
 #1278


The board has a common "5V" rail which can be fed from either USB 5V or 5V generated from the 12V. The 2 alternative sources use in-line diodes to avoid back feeding to the other side. Which one supplies the current actuall depends on which is the highest voltage. Notionall they are the same voltage but there will nearly always be a difference. Often the USB will often be lower because of cabling loss so the 12V will supply often or even share the load. However this is not guaranteed. If your hub power sits at a slightly higher voltage of course it will try to supply all or some of the current. Actually that might be an interesting thing to try. Running a hub from a bench supply at say 4.8V might allow the onboard 5V derived from 12V to always dominate.

Another way is to modify a USB cable so that 5V isn't supplied (cut the right wire maybe in a USB cable) or is regulated down to say 4.8V by an in line regulator or even a simple diode in-line to provide an extra voltage drop. Knobbling the hub supply voltage down to 4.8V might be somewhat simplier.

 Here there is a possibility of simply clearing the config SPI flash of the 2 non-working FPGAs so there is nothing to interfere. Actually that gives me a thought of whether we can remove power from these 2 devices. You do need power for JTAG to work but otherwise it might work. A line parking build might do the same. I'll look at that as an option as it can be done quiclkly.

Often in bus powered systems the drop on the cabling and hubs would make the 12V derived fed win. However a powered hub might make this different. It's good and bad. First because

Cutting current draw from the USB when the 12V line is live would definitely be a good thing.  Right now, bad things happen when you exceed the current capacity of the the USB input hubs.  My best guess is that you need >150 mA per port to be safe.  I am supplying my system with 250 mA / port to be safe.

Presently I'm dealing with a very strange issue.  After adding a few boards several of the boards already on the chain seem to have reverted to the ship test bitstream.  In idle and in operation some boards have blue LEDs live 100% of the time, which I have only seen with ship_test.  All boards had the flash programmed to twin_test before being connected.  I have recovered some by reprogramming twin_test again.  But a few board won't take the programming and throw USB errors.

The programming is being done with an independent Win7 x64 system, and I have been able to program other boards without problems.


The only way you could revert was if the SPI Flash had not been programmed and you had live loaded the FPGA directly. What is more likely is that they have gone into the lockup mode I have described elsewhere. Once FPGAs are in that lockup mode we think the only ways back are to either power cycle or do a live configuration. I am hoping to do some work on Rev 1.4 controller today that might partially solve the lockup issue but this unlikely to be a total answer. The proper place to fix this is in the array FPGA design and of course the twin isn't our original design and very hard to fix properly and rebuild. We do have something that is much more robust in our own design and cross fingers once that is available you won't have the issue. Meanwhile I will do my best to provide an improvement on the temporary solution in the Controller design.

On the USB hubs I would either try a switched type like I listed earlier today or go for one with an even higher port current capability i.e. more like 500mA. Also be careful of some hubs that have 1 or 2 permanently powered ports for charging Ipods etc.. These hubs generally are ok but I would avoid the ports on them that don't power down.
Xenland
Legendary
*
Offline Offline

Activity: 980


I'm not just any shaman, I'm a Sha256man


View Profile
July 14, 2012, 12:45:18 PM
 #1279

Are their any models that are in teh $150-$200 range?

Also I'm confused about the power supplies? Does it require more then one supplies? Can it run on just USB power supply? How about regular power cords in USA?
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
July 14, 2012, 01:31:21 PM
 #1280

Rev 1.3 Controller DIP SWitch Usage


Pages: « 1 ... 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 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 ... 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!