hm
Member
 Offline
Activity: 107
Merit: 10
|
 |
September 13, 2012, 04:48:41 PM
Last edit: September 13, 2012, 06:21:01 PM by hm |
|
Stats are OK:  #0017 is being flashed right now (hashvoodoo_release_08_16_2012). I've got a bunch of old serial ports with flat cables and 10pin-connectors laying around. I would like to use them to build some daisy-chaining cables for my rig. Possible problem is, they only have 9 lines instead of 10. Can I still use them? Is there a pinout description available for J12, J13? ps. Another thing... I just had all my four boards connected to power, the USB cables were connected to the boards but not to the computer. When I touched at least two of the USB connectors repeatedly, I got electric shocks every time. When touching one USB connector alone, I didn't get shocked. Also, I have an unpowered USB hub with LED for each port. When I had all the boards connected, I disconnected the hub from the PC and the LEDs where still on, though not as bright as when connected to the PC. Is this normal? This is the hub, half of the boards couldn't start mining using this cheap chinese product, I recommend not to use this:  pps. board #0017 is running.. not good but better than before. there are mpbm log messages like this: 2012-09-13 20:18:25.216 [250] 0017-p1 hv-175: 50btc accepted share 88297200 (difficulty 1.01576)
2012-09-13 20:18:25.275 [200] 0017-p3 hv-175: Got H-not-zero share 7416e19f
2012-09-13 20:18:28.091 [200] 0017-p2 hv-175: Got H-not-zero share fca2654d
2012-09-13 20:18:28.091 [200] 0017-p2 hv-175: Detected overload condition!
2012-09-13 20:18:29.963 [200] 0017-p3 hv-175: Got H-not-zero share a58ccc30
2012-09-13 20:18:29.964 [200] 0017-p3 hv-175: Detected overload condition! |
|
|
|
|
|
|
|
|
|
Even in the event that an attacker gains more than 50% of the network's
computational power, only transactions sent by the attacker could be
reversed or double-spent. The network would not be destroyed.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
|
|
|
|
|
salty
|
|
September 13, 2012, 09:48:05 PM
Last edit: September 14, 2012, 09:56:44 AM by salty |
|
I'm referring to the section for upgrading the bitstream though, not updating the controller, is the SPI switch still relevant at this point in the procedure? And is SW6-1 baud rate? because I'm getting better results with that set to 'off' or 115200 for mining.The guide is excellent btw  |
|
|
|
|
|
Lethos
|
|
September 13, 2012, 10:04:25 PM |
|
... I've just find it odd, what could of caused it to just start happening.
...
'Maybe' a small increase in ambient temperature? Are you using the makomk bitstream and are any of your CM1 FPGAs generating over 0.5% Invalids? For me, USB related problems went away when I stopped connecting a USB cable to a board which is generating 2.25% invalids. (By daisy chaining the boards and making the one with about 0.2% invalids the Master.) With this approach I've been operating four days continuously whereas before the reconfiguration I had two failures within 24 hrs. Not using the makomk bitstream, I've used hashvoodoo one. Not sure it even makes a difference, before I put things in place to prevent power being a problem, it never mine. For reference I get approximately 0.01% invalids on his bitstream, it's pretty rare.
Must of missed that (or don't remember), I've just find it odd, what could of caused it to just start happening.
At least I know why now, I don't even know for sure if a new powered hub will help.
Lethos, I don't think a powered hub can help you here since it is an OS/driver problem as far as I know. spiccioli I'm back to using ubuntu to prove it wasn't a software problem, using the same method I used in Debian. I've always been cheap when it came to hubs, never seen their be much of a difference to them. Quiet different to how I am with PSU's ( always high end). So this time I'm getting a really good one, doesn't bother me even if I'm wrong I've not got a good 7 port usb hub, so even if it ends up not fixing it permanently it will find a use. |
|
|
|
steveme
Newbie
Offline
Activity: 37
Merit: 0
|
|
September 13, 2012, 10:55:38 PM |
|
I'm referring to the section for upgrading the bitstream though, not updating the controller, is the SPI switch still relevant at this point in the procedure? And is SW6-1 baud rate? because I'm getting better results with that set to 'off' or 115200 for mining. The guide is excellent btw Yes, you're right. I got those transposed somehow. I've corrected them to leave SW6-1 off (115200 baud) all the time (there's no reason to change it when flashing) For controller programming, setting SW1-3 & SW6-2 off is only necessary when reflashing the controller post 1.3 so that's a good catch-all I've corrected the FPGA programming settings as per Lethos's diagram Well spotted, cheers for that - I'm not in a position to do a full dummy run of this as I've got a single board happily hashing away and don't want to interrupt it.... |
|
|
|
|
kano
Legendary
Offline
Activity: 4466
Merit: 1800
Linux since 1997 RedHat 4
|
|
September 13, 2012, 11:47:20 PM |
|
...
2012-09-13 20:18:25.275 [200] 0017-p3 hv-175: Got H-not-zero share 7416e19f
...
If you were wondering about that message, That usually means a HW error share. I'm not sure about mpbm and what it does with HW error shares, but any device that gets a HW error it's simply detected by H being non-zero H is the first 32 bits in the block hash (in the order you normally see it) and as you normally see it - it is always all zeros. As soon as it is non-zero for any given share (nonce) found by the device, then you know the device got it wrong and it's a hardware error - usually due to overheating or other such issues. |
|
|
|
|
salty
|
|
September 14, 2012, 12:11:33 AM |
|
I'm referring to the section for upgrading the bitstream though, not updating the controller, is the SPI switch still relevant at this point in the procedure? And is SW6-1 baud rate? because I'm getting better results with that set to 'off' or 115200 for mining. The guide is excellent btw Yes, you're right. I got those transposed somehow. I've corrected them to leave SW6-1 off (115200 baud) all the time (there's no reason to change it when flashing) For controller programming, setting SW1-3 & SW6-2 off is only necessary when reflashing the controller post 1.3 so that's a good catch-all I've corrected the FPGA programming settings as per Lethos's diagram Well spotted, cheers for that - I'm not in a position to do a full dummy run of this as I've got a single board happily hashing away and don't want to interrupt it.... Well I was kind-of right..... if you consider being wrong as right that is.... thought I'd better check the info..... Switch SW6-1(also referred to as 'switch 5') is the board array clock rate not baud rate (heh) and it sets the array clock speed between 50mhz and 100mhz on enterpoint's controllers and 25/50mhz on Glasswalker's. I got confused while setting the baud rate flag in Cgminer probably. |
|
|
|
|
hm
Member
Offline
Activity: 107
Merit: 10
|
|
September 14, 2012, 01:27:46 AM
Last edit: September 14, 2012, 01:53:40 AM by hm |
|
Trying to set up my boards following steveme's Guide, I've run into a following problem on Windows.
For one of my boards, Windows detected 3 of the COM ports, but one is still missing. That is, driver installation just hang up, and now COM24, COM25, COM27 are present but COM26 is missing. Unplugging and repowering board does not help, Windows does not recognize the port and there are also no unknown devices in the Device Manager.
Has anyone seen a similar issue, is there any fix for this?
I've had this problem with a friend's board. Having the board connected, I uninstalled the concerning port and all the other devices of the board in device manager. If you don't see the devices, you have to show devices that are not connected. Then I disconnected the board, rebooted PC and repeated installation. After successfull installation, there were still problems detecting the board in windows when reconnecting, they went away when switching usb cable. I use this USB Hub and can recommend it over cheap chinese products: Hama USB 2.0 Hub 1:4, black/silver, with power supply, packed in blister Perhaps it's still made in China, but QC checked by Hama, Germany. My other USB Hub is a cheap one from China (see some posts above). Effectively, the power jack's 5V, the uplink USB's 5V, and each port's 5V lines are interconnected without resistor or diodes between them. I think this could be dangerous if powered USB devices send power up the USB cable through the hub into the PC, but I am no expert in electronics at all, so I could be wrong. I assume the Cairnsmore1 boards can send power up the usb cables, since I got electro-shocked when touching two usb cables that where connected to CM1s but disconnected from PC. -- my stats:  I still hope that the next hashvoodoo will fix issues with 0017-p3. In the meantime, I'll delete the corresponding worker in mpbm until the next power cycle. |
|
|
|
|
|
salty
|
|
September 14, 2012, 09:52:47 AM |
|
Just some notes on Mac installation on a Macbook Pro 2,1. I tried to set it up yesterday but the USB system is very picky - The cairnsmore didn't show up in the System profiler, and there was nothing showing in /dev/ , iosnoop or ioreg. My speculation is that as I connected the USB before connecting the 12v power (I know, I know..) there was too much draw on the USB port and the mac USB hardware blocked the cairnsmore board somehow. There are mac drivers for the FTDI USB com chip here: http://www.ftdichip.com/Drivers/VCP.htm , and the linux version of Cgminer is able to compile using macports. I think it is possible to get the Cairnsmore 1 hashing on mac, but I will not be trying any further, I switched my efforts to an old PC from the attic and got hashing at 843mh/s within 1 hour. |
|
|
|
|
steveme
Newbie
Offline
Activity: 37
Merit: 0
|
|
September 15, 2012, 11:08:57 PM |
|
steveme, Thanks for writing the Guide! It has all the necessary info, and I was able to set up at least a couple of boards following it. The bounty of 20BTC is sent to the address you provided. Just for reference, Quick-start Guide is located at: http://btc.steveme.mailforce.net/CM1%20quickstart%20guide.htmlI wonder if Enterpoint is interested in adding this Guide to their documentation package - it seems a good place to start for new CM1 users. bounty received - thanks! the guide is now on the bitcoin wiki at https://en.bitcoin.it/wiki/CM1Quickstart |
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
September 15, 2012, 11:22:01 PM |
|
BFGMiner 2.8.0 should work with Cairnsmore1 now. I don't really have one to develop/test with, however, so if anyone wants to confirm... donations to get me one are also welcome
|
|
|
|
|
tnkflx
|
|
September 16, 2012, 08:37:11 PM |
|
steveme, Thanks for writing the Guide! It has all the necessary info, and I was able to set up at least a couple of boards following it. The bounty of 20BTC is sent to the address you provided. Just for reference, Quick-start Guide is located at: http://btc.steveme.mailforce.net/CM1%20quickstart%20guide.htmlI wonder if Enterpoint is interested in adding this Guide to their documentation package - it seems a good place to start for new CM1 users. bounty received - thanks! the guide is now on the bitcoin wiki at https://en.bitcoin.it/wiki/CM1QuickstartSome possible additions?: - Emptying the chips takes approx. 2,5 minutes/chip (10 minutes in total) - Flashing the bitstream takes approx. 8 minutes/chip (32 minutes in total) - Make a note somewhere of the modprobe you need to do if you use Linux? - The batch you create for cgminer can be created for bfgminer as well - Maybe a note somewhere that the controller software can only be flashed from Windows? - Maybe expand the guide to also include bfgminer & cgminer when running under Linux? |
| Operating electrum.be & us.electrum.be |
|
|
|
|
steamboat
|
|
September 16, 2012, 10:12:28 PM |
|
This is a make-shift guide for windows users for faster, permanent flashing. I have not yet tested it, but apparrentley Slipbye has had succes with it. It also gets us out of the virtual machine (for good ?) 21:13] <TheSeven> http://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/1.2.6.0/libusb-win32-devel-filter-1.2.6.0.exe/download[21:14] <TheSeven> install that, make sure the board to be flashed is plugged, start the libusb filter wizard [21:14] <TheSeven> select the USB composite device which shows an ID of 0403 8350 [21:14] <TheSeven> install the filter driver for that [21:14] <TheSeven> download this: https://xc3sprog.svn.sourceforge.net/svnroot/xc3sprog/trunk/xc3sprog.exe[21:14] <TheSeven> create a new file called cablelist.txt in the same directory [21:15] <TheSeven> put this line inside that file: [21:15] <TheSeven> cm1 ftdi 20000000 0x0403:0x8350: [21:15] <TheSeven> open a command prompt in the directory where the files are and run these commands: [21:15] <TheSeven> set CABLEDB=cablelist.txt [21:15] <TheSeven> xc3sprog -c cm1 [21:15] <TheSeven> it should detect the fpgas a this point you want to copy the .bit files you'll be using to the same folder as xc3sprog is in. [21:16] <TheSeven> if that worked, you can go ahead with flashing like usual [21:16] <TheSeven> xc3sprog -c cm1 -p 0 -Ixc6lx150.bit file_to_be_flashed.bit Enjoy your 1-3hours of spare time per day This works. Saves a bunch of time |
|
|
|
julz
Legendary
Offline
Activity: 1092
Merit: 1001
|
|
September 18, 2012, 08:49:53 AM |
|
bfgminer version 2.8.0 - Started: [2012-09-18 08:24:01] - [ 0 days 00:21:36] -------------------------------------------------------------------------------- 5s:559.2 avg:795.6 u:258.4 Mh/s | A:78 R:0 HW:0 E:229% U:3.6/m TQ: 0 ST: 3 SS: 0 DW: 0 NB: 1 GW: 34 LW: 744 GF: 0 RF: 0 Connected to http://x.x.x.x:8777 with LP as user x Block: 00000040412b763328116fea4b69a1f3... Started: [08:24:01] -------------------------------------------------------------------------------- [P]ool management Settings Display options Quit ECM 0: | 399.1/398.4/ 59.6Mh/s | A:18 R:0 HW:0 U:0.83/m ECM 1: | 399.0/397.2/198.7Mh/s | A:60 R:0 HW:0 U:2.78/m -------------------------------------------------------------------------------- This probably isn't specifically related to the cairnsmore.. but what is the 'u:' field here? Any idea as to why it's so low? The speed at the mining pool is currently showing as around 250Mh too. |
@electricwings BM-GtyD5exuDJ2kvEbr41XchkC8x9hPxdFd
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
September 18, 2012, 12:06:47 PM |
|
bfgminer version 2.8.0 - Started: [2012-09-18 08:24:01] - [ 0 days 00:21:36]
--------------------------------------------------------------------------------
5s:559.2 avg:795.6 u:258.4 Mh/s | A:78 R:0 HW:0 E:229% U:3.6/m
TQ: 0 ST: 3 SS: 0 DW: 0 NB: 1 GW: 34 LW: 744 GF: 0 RF: 0
Connected to http://x.x.x.x:8777 with LP as user x
Block: 00000040412b763328116fea4b69a1f3... Started: [08:24:01]
--------------------------------------------------------------------------------
[P]ool management Settings Display options Quit
ECM 0: | 399.1/398.4/ 59.6Mh/s | A:18 R:0 HW:0 U:0.83/m
ECM 1: | 399.0/397.2/198.7Mh/s | A:60 R:0 HW:0 U:2.78/m
-------------------------------------------------------------------------------- This probably isn't specifically related to the cairnsmore.. but what is the 'u:' field here? Any idea as to why it's so low? The speed at the mining pool is currently showing as around 250Mh too. Utility hashrate: your mining speed calculated from shares accepted, for the entire runtime and across all pools. In other words, while your Cairnsmore is reporting* 795 Mh/s on average, it's only finding 258 Mh/s worth of shares. That could be due to a number of factors, including (but not only) both clocking too high and/or poor luck. As you only have 78 shares accepted in this case, I'd suspect it's probably luck unless it keeps up for a long while. If your pool uses higher difficulty shares, it will take even longer to average out. |
|
|
|
|
salty
|
|
September 18, 2012, 12:16:58 PM |
|
bfgminer version 2.8.0 - Started: [2012-09-18 08:24:01] - [ 0 days 00:21:36] -------------------------------------------------------------------------------- 5s:559.2 avg:795.6 u:258.4 Mh/s | A:78 R:0 HW:0 E:229% U:3.6/m TQ: 0 ST: 3 SS: 0 DW: 0 NB: 1 GW: 34 LW: 744 GF: 0 RF: 0 Connected to http://x.x.x.x:8777 with LP as user x Block: 00000040412b763328116fea4b69a1f3... Started: [08:24:01] -------------------------------------------------------------------------------- [P]ool management Settings Display options Quit ECM 0: | 399.1/398.4/ 59.6Mh/s | A:18 R:0 HW:0 U:0.83/m ECM 1: | 399.0/397.2/198.7Mh/s | A:60 R:0 HW:0 U:2.78/m -------------------------------------------------------------------------------- This probably isn't specifically related to the cairnsmore.. but what is the 'u:' field here? Any idea as to why it's so low? The speed at the mining pool is currently showing as around 250Mh too. What controller, bitstream and jumper settings are you using? What's the serial # of your board? That's not very healthy looking. I'm getting ~840mh/s reported at my pool... Edit - your power supply could also be causing this, how many amps is it rated at? |
|
|
|
|
|
tnkflx
|
|
September 18, 2012, 02:29:55 PM |
|
bfgminer version 2.8.0 - Started: [2012-09-18 08:24:01] - [ 0 days 00:21:36] -------------------------------------------------------------------------------- 5s:559.2 avg:795.6 u:258.4 Mh/s | A:78 R:0 HW:0 E:229% U:3.6/m TQ: 0 ST: 3 SS: 0 DW: 0 NB: 1 GW: 34 LW: 744 GF: 0 RF: 0 Connected to http://x.x.x.x:8777 with LP as user x Block: 00000040412b763328116fea4b69a1f3... Started: [08:24:01] -------------------------------------------------------------------------------- [P]ool management Settings Display options Quit ECM 0: | 399.1/398.4/ 59.6Mh/s | A:18 R:0 HW:0 U:0.83/m ECM 1: | 399.0/397.2/198.7Mh/s | A:60 R:0 HW:0 U:2.78/m -------------------------------------------------------------------------------- This probably isn't specifically related to the cairnsmore.. but what is the 'u:' field here? Any idea as to why it's so low? The speed at the mining pool is currently showing as around 250Mh too. What controller, bitstream and jumper settings are you using? What's the serial # of your board? That's not very healthy looking. I'm getting ~840mh/s reported at my pool... Edit - your power supply could also be causing this, how many amps is it rated at? He probably flashed the makomk 200 Mhz version: ECM 0 + ECM 1 = 800 Mhz, so that looks good. No idea about the Utility though... |
| Operating electrum.be & us.electrum.be |
|
|
|
kano
Legendary
Offline
Activity: 4466
Merit: 1800
Linux since 1997 RedHat 4
|
|
September 18, 2012, 03:36:19 PM |
|
...
He probably flashed the makomk 200 Mhz version: ECM 0 + ECM 1 = 800 Mhz, so that looks good. No idea about the Utility though...
At a guess, when Apollyon copied my Icarus code, to make the CM1 module, he didn't copy all the HW error detection changes in my git Use my latest git of the real cgminer and it will tell you directly if that is the problem. https://github.com/kanoi/cgminer |
|
|
|
|
