Bitcoin Forum
December 10, 2016, 10:42:43 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 115 116 117 118 119 120 121 122 ... 129 »
  Print  
Author Topic: Cairnsmore1 - Quad XC6SLX150 Board  (Read 251444 times)
misternoodle
Member
**
Offline Offline

Activity: 108



View Profile
July 20, 2012, 03:45:28 PM
 #1421

Been having issues with my board recently.  It won't even make it past the 1 hour mark before it disconnects in Windows.  Have to constantly power cycle the device so I can have it working somewhat. Undecided
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
zefir
Donator
Hero Member
*
Offline Offline

Activity: 917



View Profile
July 20, 2012, 08:43:13 PM
 #1422

[... lots of in deep info about cgminer internals ...]

Thanks kano for the extended explanation. Happy that I was not too way off understanding the code Wink

Quote
Heh - well then someone should read the FPGA-README in cgminer that I wrote quite a while ago:
WTF! I spent so many hours analyzing the Icarus driver code and it was all already written in a Readme? Serves me right for not remembering to RTFM...

Quote
So yes I stated this when I wrote the code that it required a pair of FPGA (hashing half each)

If these boards are only hashing half the range on a single FPGA then the MH/s value will of course report double what it really is.
The code itself simply doubles the count of hashes completed each time since it knows EXACTLY how many hashes were done and how long it took and assuming there are 2 FPGA (as I said above) then double ((nonce & 0x7fffffff) + 1) is of course correct - NOT an estimate AT ALL.

I was maybe not clear: not saying that the Icarus driver reports the wrong hashrate, only that the cgminer core has no own measure to report the rate other than what the driver is claiming to have processed. I could claim my SoundBlaster DSP can do 1THps and write a driver for it to fool people with that rate being displayed. But you can't cheat the U factor.


Thanks again for all the clarification.


misternoodle
Member
**
Offline Offline

Activity: 108



View Profile
July 20, 2012, 09:37:43 PM
 #1423

Been having issues with my board recently.  It won't even make it past the 1 hour mark before it disconnects in Windows.  Have to constantly power cycle the device so I can have it working somewhat. Undecided

Try changing the USB cable

Just swapped it out, will see how that goes.  Thanks!
Lethos
Sr. Member
****
Offline Offline

Activity: 476


Keep it Simple. Every Bit Matters.


View Profile WWW
July 20, 2012, 10:17:12 PM
 #1424


Think that might be a keypoint to stability issues, I have noticed a lot with the worst problems with stability use windows.
Guess I really need to get my arse into gear and get cgminer working on linux.

Lethos,

I've had boards running without interruption for at least 12 days using Win7 32 bit.  I would take a serious look at your hardware, and possibly swap it out.

A power flicker once required me to shut down and remount the entire system, but that should be obvious if you have any digital clocks.

Also I had one case where the USB chain dropped on the boards over night, but exactly the same thing happened to my Ztex system running completely independently in a different room.  I suspect stray EM interference in that case.  Do you happen to live in the flight path of an airport?

I am not anywhere near an airport. I am however near a cell phone tower it's just 200-300 yards away.
I swear If I'm just moved house (last week) right next to a place that is making it impossible for my new hardware to work reliably I'll be pissed.
I haven't had the time to work on getting it working in linux yet, had a major development project sitting on me past few weeks.

Hey, I'd just be happy to get this working reliably, I'm far more familar with Windows than I am Linux (apart from Centos). I'm not that familar with Ubuntu and Debian which are far more prefered for personal computer Linux OS.
Most of my experience with Linux is with servers, running it for high load game servers, not using Linux as a personal computer, so It's a slightly different aspect of linux for me to learn.

Lethos Designs | UK BTC Seller -  Local Bitcoins | BTC OTC Rating | 1EFhXfX9uXsbXBF3LC69GiVfS3SHCsyMR1
FPGA: 2x Quad XC6SLX150 Boards
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
July 20, 2012, 10:21:19 PM
 #1425

This is dmesg output.

Code:
[636683.527463] usb 1-3: USB disconnect, device number 2
[636683.527480] usb 1-3.1: USB disconnect, device number 4
[636683.527969] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[636683.528056] ftdi_sio 1-3.1:1.0: device disconnected
[636683.531516] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[636683.531571] ftdi_sio 1-3.1:1.1: device disconnected
[636683.537769] ftdi_sio ttyUSB2: FTDI USB Serial Device converter now disconnected from ttyUSB2
[636683.537810] ftdi_sio 1-3.1:1.2: device disconnected
[636683.541175] ftdi_sio ttyUSB3: FTDI USB Serial Device converter now disconnected from ttyUSB3
[636683.541216] ftdi_sio 1-3.1:1.3: device disconnected
[636683.541585] usb 1-3.2: USB disconnect, device number 5
[636683.541957] ftdi_sio ttyUSB4: FTDI USB Serial Device converter now disconnected from ttyUSB4
[636683.542003] ftdi_sio 1-3.2:1.0: device disconnected
[636683.543191] ftdi_sio ttyUSB5: FTDI USB Serial Device converter now disconnected from ttyUSB5
[636683.543241] ftdi_sio 1-3.2:1.1: device disconnected
[636683.546774] ftdi_sio ttyUSB6: FTDI USB Serial Device converter now disconnected from ttyUSB6
[636683.546815] ftdi_sio 1-3.2:1.2: device disconnected
[636683.549974] ftdi_sio ttyUSB7: FTDI USB Serial Device converter now disconnected from ttyUSB7
[636683.550008] ftdi_sio 1-3.2:1.3: device disconnected
[636683.550311] usb 1-3.3: USB disconnect, device number 6
[636683.550616] ftdi_sio ttyUSB8: FTDI USB Serial Device converter now disconnected from ttyUSB8
[636683.550655] ftdi_sio 1-3.3:1.0: device disconnected
[636683.552739] ftdi_sio ttyUSB9: FTDI USB Serial Device converter now disconnected from ttyUSB9
[636683.552782] ftdi_sio 1-3.3:1.1: device disconnected
[636683.556542] ftdi_sio ttyUSB10: FTDI USB Serial Device converter now disconnected from ttyUSB10
[636683.556577] ftdi_sio 1-3.3:1.2: device disconnected
[636683.559003] ftdi_sio ttyUSB11: FTDI USB Serial Device converter now disconnected from ttyUSB11
[636683.559037] ftdi_sio 1-3.3:1.3: device disconnected
[636683.559342] usb 1-3.4: USB disconnect, device number 7
[636683.559647] ftdi_sio ttyUSB12: FTDI USB Serial Device converter now disconnected from ttyUSB12
[636683.559688] ftdi_sio 1-3.4:1.0: device disconnected
[636683.562317] ftdi_sio ttyUSB13: FTDI USB Serial Device converter now disconnected from ttyUSB13
[636683.562362] ftdi_sio 1-3.4:1.1: device disconnected
[636683.565950] ftdi_sio ttyUSB14: FTDI USB Serial Device converter now disconnected from ttyUSB14
[636683.565985] ftdi_sio 1-3.4:1.2: device disconnected
[636683.569579] ftdi_sio ttyUSB15: FTDI USB Serial Device converter now disconnected from ttyUSB15
[636683.569614] ftdi_sio 1-3.4:1.3: device disconnected
[636683.808058] usb 1-3: new high-speed USB device number 15 using ehci_hcd
[636698.920070] usb 1-3: device descriptor read/64, error -110
[636714.136074] usb 1-3: device descriptor read/64, error -110
[636714.352074] usb 1-3: new high-speed USB device number 16 using ehci_hcd
[636729.464051] usb 1-3: device descriptor read/64, error -110
[636744.680055] usb 1-3: device descriptor read/64, error -110
[636744.896057] usb 1-3: new high-speed USB device number 17 using ehci_hcd
[636755.304068] usb 1-3: device not accepting address 17, error -110
[636755.416075] usb 1-3: new high-speed USB device number 18 using ehci_hcd
[636765.824088] usb 1-3: device not accepting address 18, error -110
[636765.824235] hub 1-0:1.0: unable to enumerate USB device on port 3
[636766.080066] usb 3-1: new full-speed USB device number 2 using uhci_hcd
[636766.225103] usb 3-1: not running at top speed; connect to a high speed hub
[636766.250260] hub 3-1:1.0: USB hub found
[636766.252447] hub 3-1:1.0: 4 ports detected
[636766.537118] usb 3-1.1: new full-speed USB device number 3 using uhci_hcd
[636766.639088] usb 3-1.1: not running at top speed; connect to a high speed hub
[636766.675515] ftdi_sio 3-1.1:1.0: FTDI USB Serial Device converter detected
[636766.675636] usb 3-1.1: Detected FT4232H
[636766.675648] usb 3-1.1: Number of endpoints 2
[636766.675660] usb 3-1.1: Endpoint 1 MaxPacketSize 64
[636766.675672] usb 3-1.1: Endpoint 2 MaxPacketSize 64
[636766.675684] usb 3-1.1: Setting MaxPacketSize 64
[636766.677277] usb 3-1.1: FTDI USB Serial Device converter now attached to ttyUSB0
[636766.681010] ftdi_sio 3-1.1:1.1: FTDI USB Serial Device converter detected
[636766.681143] usb 3-1.1: Detected FT4232H
[636766.681155] usb 3-1.1: Number of endpoints 2
[636766.681167] usb 3-1.1: Endpoint 1 MaxPacketSize 64
[636766.681179] usb 3-1.1: Endpoint 2 MaxPacketSize 64
[636766.681191] usb 3-1.1: Setting MaxPacketSize 64
[636766.683866] usb 3-1.1: FTDI USB Serial Device converter now attached to ttyUSB1
[636766.687509] ftdi_sio 3-1.1:1.2: FTDI USB Serial Device converter detected
[636766.687627] usb 3-1.1: Detected FT4232H
[636766.687639] usb 3-1.1: Number of endpoints 2
[636766.687651] usb 3-1.1: Endpoint 1 MaxPacketSize 64
[636766.687663] usb 3-1.1: Endpoint 2 MaxPacketSize 64
[636766.687675] usb 3-1.1: Setting MaxPacketSize 64
[636766.689301] usb 3-1.1: FTDI USB Serial Device converter now attached to ttyUSB4
[636766.692684] ftdi_sio 3-1.1:1.3: FTDI USB Serial Device converter detected
[636766.692783] usb 3-1.1: Detected FT4232H
[636766.692793] usb 3-1.1: Number of endpoints 2
[636766.692803] usb 3-1.1: Endpoint 1 MaxPacketSize 64
[636766.692812] usb 3-1.1: Endpoint 2 MaxPacketSize 64
[636766.692821] usb 3-1.1: Setting MaxPacketSize 64
[636766.694253] usb 3-1.1: FTDI USB Serial Device converter now attached to ttyUSB5
[636766.769118] usb 3-1.2: new full-speed USB device number 4 using uhci_hcd
[636766.872093] usb 3-1.2: not running at top speed; connect to a high speed hub
[636766.910520] ftdi_sio 3-1.2:1.0: FTDI USB Serial Device converter detected
[636766.910646] usb 3-1.2: Detected FT4232H
[636766.910658] usb 3-1.2: Number of endpoints 2
[636766.910670] usb 3-1.2: Endpoint 1 MaxPacketSize 64
[636766.910682] usb 3-1.2: Endpoint 2 MaxPacketSize 64
[636766.910693] usb 3-1.2: Setting MaxPacketSize 64
[636766.913543] usb 3-1.2: FTDI USB Serial Device converter now attached to ttyUSB8
[636766.916687] ftdi_sio 3-1.2:1.1: FTDI USB Serial Device converter detected
[636766.916811] usb 3-1.2: Detected FT4232H
[636766.916823] usb 3-1.2: Number of endpoints 2
[636766.916835] usb 3-1.2: Endpoint 1 MaxPacketSize 64
[636766.916847] usb 3-1.2: Endpoint 2 MaxPacketSize 64
[636766.916858] usb 3-1.2: Setting MaxPacketSize 64
[636766.918279] usb 3-1.2: FTDI USB Serial Device converter now attached to ttyUSB9
[636766.921514] ftdi_sio 3-1.2:1.2: FTDI USB Serial Device converter detected
[636766.921634] usb 3-1.2: Detected FT4232H
[636766.921646] usb 3-1.2: Number of endpoints 2
[636766.921658] usb 3-1.2: Endpoint 1 MaxPacketSize 64
[636766.921670] usb 3-1.2: Endpoint 2 MaxPacketSize 64
[636766.921681] usb 3-1.2: Setting MaxPacketSize 64
[636766.923932] usb 3-1.2: FTDI USB Serial Device converter now attached to ttyUSB12
[636766.927514] ftdi_sio 3-1.2:1.3: FTDI USB Serial Device converter detected
[636766.927637] usb 3-1.2: Detected FT4232H
[636766.927649] usb 3-1.2: Number of endpoints 2
[636766.927661] usb 3-1.2: Endpoint 1 MaxPacketSize 64
[636766.927673] usb 3-1.2: Endpoint 2 MaxPacketSize 64
[636766.927684] usb 3-1.2: Setting MaxPacketSize 64
[636766.929279] usb 3-1.2: FTDI USB Serial Device converter now attached to ttyUSB13
[636767.005107] usb 3-1.3: new full-speed USB device number 5 using uhci_hcd
[636767.107088] usb 3-1.3: not running at top speed; connect to a high speed hub
[636767.145527] ftdi_sio 3-1.3:1.0: FTDI USB Serial Device converter detected
[636767.145649] usb 3-1.3: Detected FT4232H
[636767.145662] usb 3-1.3: Number of endpoints 2
[636767.145674] usb 3-1.3: Endpoint 1 MaxPacketSize 64
[636767.145686] usb 3-1.3: Endpoint 2 MaxPacketSize 64
[636767.145697] usb 3-1.3: Setting MaxPacketSize 64
[636767.147857] usb 3-1.3: FTDI USB Serial Device converter now attached to ttyUSB40
[636767.151504] ftdi_sio 3-1.3:1.1: FTDI USB Serial Device converter detected
[636767.151635] usb 3-1.3: Detected FT4232H
[636767.151647] usb 3-1.3: Number of endpoints 2
[636767.151659] usb 3-1.3: Endpoint 1 MaxPacketSize 64
[636767.151671] usb 3-1.3: Endpoint 2 MaxPacketSize 64
[636767.151682] usb 3-1.3: Setting MaxPacketSize 64
[636767.153281] usb 3-1.3: FTDI USB Serial Device converter now attached to ttyUSB41
[636767.156697] ftdi_sio 3-1.3:1.2: FTDI USB Serial Device converter detected
[636767.156820] usb 3-1.3: Detected FT4232H
[636767.156831] usb 3-1.3: Number of endpoints 2
[636767.156843] usb 3-1.3: Endpoint 1 MaxPacketSize 64
[636767.156855] usb 3-1.3: Endpoint 2 MaxPacketSize 64
[636767.156866] usb 3-1.3: Setting MaxPacketSize 64
[636767.159105] usb 3-1.3: FTDI USB Serial Device converter now attached to ttyUSB42
[636767.162427] ftdi_sio 3-1.3:1.3: FTDI USB Serial Device converter detected
[636767.162534] usb 3-1.3: Detected FT4232H
[636767.162543] usb 3-1.3: Number of endpoints 2
[636767.162553] usb 3-1.3: Endpoint 1 MaxPacketSize 64
[636767.162563] usb 3-1.3: Endpoint 2 MaxPacketSize 64
[636767.162572] usb 3-1.3: Setting MaxPacketSize 64
[636767.164807] usb 3-1.3: FTDI USB Serial Device converter now attached to ttyUSB43

I have to say, that doesn't look like a bitstream problem. It looks very much like there's some problem with the USB hub that you're connecting the boards to - it's dropping off the bus, failing to enumerate at USB 2.0 speeds, and eventually falling back to USB 1.1. Try a different hub or connecting them directly?

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
July 20, 2012, 10:40:32 PM
 #1426

This is dmesg output.

...
I have to say, that doesn't look like a bitstream problem. It looks very much like there's some problem with the USB hub that you're connecting the boards to - it's dropping off the bus, failing to enumerate at USB 2.0 speeds, and eventually falling back to USB 1.1. Try a different hub or connecting them directly?
Well that's certainly a good suggestion - but of course, spiccioli, note that they will get different USB numbers so be sure to compare the old and new correctly
i.e. plug a few directly into the computer and compare to the ones in the hubs - but unplug them, then first take a listing of 'ls /dev/ttyUSB*' then plug them in and compare to what it was before - the new numbers not present in the previous listing (which can be higher or in the middle of the old numbers) are of course the direct connected ones.

Also, certain old linux kernels have a problem with sending/receiving > 64 bytes over Serial+USB and literally chop off a byte at 64
Seeing the number 64 in there reminded me of that - but I don't know the kernel numbers.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
nave
Donator
Full Member
*
Offline Offline

Activity: 160



View Profile
July 21, 2012, 12:34:15 AM
 #1427

Ok, I've been bumbling through trying to flash the twin_test.bit onto the two boards I just got the other day (434 and 435). I don't know a whole lot about linux, so I'm hoping I missed something very simple and someone can help me out. I have the dip switches set according to the instructions PDF (SW1: 3 off, SW3&4: 1&2 off, all others on). When trying to flash with the command xc3sprog -c cm1 -p 0 -Ixc6lx150.bit twin_test.bit I get the following:



Based on the post below I checked the directory and I don't have a xc6lc150.bit file. Am I in the wrong directory, or doing something else wrong? I tried to follow the PDF guide from enterpoint to the letter. Thanks for any help anyone can offer me.

Code:
xc3sprog –c cm1 –p 0 –Ixc6lx150.bit twin_test.bit
does not work, but this time it's complaning about a filename issue to me. My initial hunch is that since the board im punishing is #108 the firmware filename on it has changed along the way. I'll re-read up on this , of how I wsh the search function on this forum worked better Smiley .. but for now Im going with the temporary flash.

Strange...
When you type a "ls -l" do you see the files in the directory? And make sure you use the correct filename, the filename in UPPERCASE is XC6LX150.bit, I did a typo the first times, so I used xc61 (number one here! but it is a small "L")...

Here is my directory (ls -l) after copy the files from usb stick:


If you have the same, the commandline should work.

good luck!
nave
Donator
Full Member
*
Offline Offline

Activity: 160



View Profile
July 21, 2012, 01:41:04 AM
 #1428

Ok, I've been bumbling through trying to flash the twin_test.bit onto the two boards I just got the other day (434 and 435). I don't know a whole lot about linux, so I'm hoping I missed something very simple and someone can help me out. I have the dip switches set according to the instructions PDF (SW1: 3 off, SW3&4: 1&2 off, all others on). When trying to flash with the command xc3sprog -c cm1 -p 0 -Ixc6lx150.bit twin_test.bit I get the following:


Did you program the FPGA first?  That looks like the error I saw when I tried skipping the FPGA programming and just changing the flash over.

What is the command for this? I'm not seeing it in the PDF.
daemonic
Jr. Member
*
Offline Offline

Activity: 49


View Profile
July 21, 2012, 01:59:32 AM
 #1429

Based on the post below I checked the directory and I don't have a xc6lc150.bit file. Am I in the wrong directory, or doing something else wrong? I tried to follow the PDF guide from enterpoint to the letter. Thanks for any help anyone can offer me.

When copying the twin_test.bit and shipping_test.bit files, did you not run;
Code:
Type: cp /mnt/*.bit . <return>

Although thinking about it, looks like you mustve downloaded "Twin Bitstream Update (Windows Version)" (http://www.enterpoint.co.uk/cairnsmore/twin_test.zip) from looking at that zip, it isnt included in there, so you will also need to download the older version "Cairnsmore1 Bitstreams and Instructions" (http://www.enterpoint.co.uk/cairnsmore/CairnsmoreProgramming.zip) which does include the necessary .bit file Cheesy
this time
Jr. Member
*
Offline Offline

Activity: 55


View Profile
July 21, 2012, 02:13:32 AM
 #1430

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

Thanks for the offer. I don't speak german, the german file reference was just part of the error. I've now got my boards going on mpbm. I couldn't figure what was causing that error and I wound up installing python 2.6 and the standard version of mpbm from github.
nave
Donator
Full Member
*
Offline Offline

Activity: 160



View Profile
July 21, 2012, 02:33:42 AM
 #1431

Based on the post below I checked the directory and I don't have a xc6lc150.bit file. Am I in the wrong directory, or doing something else wrong? I tried to follow the PDF guide from enterpoint to the letter. Thanks for any help anyone can offer me.

When copying the twin_test.bit and shipping_test.bit files, did you not run;
Code:
Type: cp /mnt/*.bit . <return>

Although thinking about it, looks like you mustve downloaded "Twin Bitstream Update (Windows Version)" (http://www.enterpoint.co.uk/cairnsmore/twin_test.zip) from looking at that zip, it isnt included in there, so you will also need to download the older version "Cairnsmore1 Bitstreams and Instructions" (http://www.enterpoint.co.uk/cairnsmore/CairnsmoreProgramming.zip) which does include the necessary .bit file Cheesy

That was it, thanks for the help. Downloaded the other zip and copied the files over and it's working now. I guess I just assumed all the files I needed would be included in the zip associated with the PDF. Silly me.
this time
Jr. Member
*
Offline Offline

Activity: 55


View Profile
July 21, 2012, 02:51:55 AM
 #1432

You can also rename the files to x.bit and t.bit to save on repetitive typing.
spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
July 21, 2012, 07:15:49 AM
 #1433

This is dmesg output.

...
I have to say, that doesn't look like a bitstream problem. It looks very much like there's some problem with the USB hub that you're connecting the boards to - it's dropping off the bus, failing to enumerate at USB 2.0 speeds, and eventually falling back to USB 1.1. Try a different hub or connecting them directly?
Well that's certainly a good suggestion - but of course, spiccioli, note that they will get different USB numbers so be sure to compare the old and new correctly
i.e. plug a few directly into the computer and compare to the ones in the hubs - but unplug them, then first take a listing of 'ls /dev/ttyUSB*' then plug them in and compare to what it was before - the new numbers not present in the previous listing (which can be higher or in the middle of the old numbers) are of course the direct connected ones.

Also, certain old linux kernels have a problem with sending/receiving > 64 bytes over Serial+USB and literally chop off a byte at 64
Seeing the number 64 in there reminded me of that - but I don't know the kernel numbers.

makomk, kano

I don't think I have the old kernel issue,

Code:
uname -a
Linux t5570 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

It could be a usb hub issue, I'll buy a new hub soon, just to see if it makes some difference.

I can't connect them directly, though, since my HP thin client 5570 which I'm using as host pc can handle a maximum of three units since the boards require powered ports which it has not.

spiccioli
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
July 21, 2012, 11:22:08 AM
 #1434

Ok guys just to let know I'm not ignoring you all for any other reason than I am working on something interesting and won't be on the forum for the rest of the weekend and may be also limited in my visits during the coming week for the following reason:

Courtesy of one of our development partners, who has been working on this since we started, we now have a bitstream running a golden nonce test at 200MHz clock and without issue on all 4 FPGAs on a couple of boards for 30mins+. Now don't get too excited yet as this build still has problems running a full nonce range for mining and we are looking to see if we can stabilise this to run full range or to see if our partner can improve timing. Technically at the moment timing isn't met yet for 200MHz but there is a reasonable possibility that timing can be totally closed for 200 MHz or at 175MHz that is our 2nd fallback target level. We also have to expand testing to a wider number of boards to be more certain of design stability. The new build can run Icarus pair style or individually with the pinout we are using but we are getting better results running as individual processing units on 4 individual com channels.

Our own native development bitstream continues in parallel.

I know there will be a pile of questions ypu all want to ask on this but I am going dark, on all forms of contact, for at least the rest of the weekend so i stand a chance of progressing the design through to better stability and being more useful.

hm
Member
**
Offline Offline

Activity: 106


View Profile
July 21, 2012, 06:22:10 PM
 #1435

good to hear news from the bitstream front.

my board #62-0017 is hashing between ~100 and ~200MH/s and only periodically reaches 380MH/s (controller rev. 1.3 & twin_test bitstream). no usb problems though (no disconnects).
i have set up a linux box in the hope that it will allow the cairnsmore to run more stable than on win7. i'll give it a try tomorrow.
in the case that my new linux setup won't fix the hashing instability, i'll contact enterpoints bitcoin.support.
happy weekend.
Lethos
Sr. Member
****
Offline Offline

Activity: 476


Keep it Simple. Every Bit Matters.


View Profile WWW
July 21, 2012, 11:06:17 PM
 #1436

Good problem, I saw it over in the bounty thread first.

I've finally got my little Ubuntu atom computer running these now.
We'll see if windows was the cause of the stability issues or not.
It's only been 10-15 minutes so tomorrow morning will tell me weither it worked or not.
However it's was always going to end up here, so it's good to get it setup eventually.

Take ages to get it sorted, I only use this as my HTPC (via XBMC), so it only has a wireless mouse.
On-screen keyboards suck when you actually got a lot of typing to do.

Thanks to spiccioli, your earlier posts proved quiet useful in getting it working under linux.

Lethos Designs | UK BTC Seller -  Local Bitcoins | BTC OTC Rating | 1EFhXfX9uXsbXBF3LC69GiVfS3SHCsyMR1
FPGA: 2x Quad XC6SLX150 Boards
Lethos
Sr. Member
****
Offline Offline

Activity: 476


Keep it Simple. Every Bit Matters.


View Profile WWW
July 22, 2012, 07:52:06 AM
 #1437

It was stable all night, lasted a good 8 hours. Something that is a good 4x longer than was ever acheived in windows.
I think it was Ubuntu that made the difference, I will do my best to answer any queries in this.

Lethos Designs | UK BTC Seller -  Local Bitcoins | BTC OTC Rating | 1EFhXfX9uXsbXBF3LC69GiVfS3SHCsyMR1
FPGA: 2x Quad XC6SLX150 Boards
hm
Member
**
Offline Offline

Activity: 106


View Profile
July 22, 2012, 01:30:08 PM
 #1438

Over night I still kept it running on the win7 machine.
BUT this time I used a dual usb cable that gets power fom two usb ports.
The dual usb cable seems to have solved the instability issues regarding the hashrate:





I use a laptop (ThinkPad T500) for running cgminer. I assume it does not deliver enough power on usb or it reduces usb-power at will even though I disables all the energy management settings regarding USB and PCIe.

A friend of mine uses a siemens lifebook s series (old pentium m, win7) using standard usb cable (same energy management settings as me) and does not have any stability issues regarding hash rates.

In short, my problems seem to have been caused by bad usb powering of the controller part of the board.

but STOP... I am writing this and suddenly, both ICA fail....  Huh



I don't understand Cry I just wanted to read power comsumption from the watt-meter and moved it some inches when the FAIL happened at the same time... strange coincidence.. wouldn't the board reinitialize on a milliseconds power outage (which i could have caused by moving the watt-meter) ?

sorry... seems I was the cause of the FAIL by touching the usb cable with my elbow and loosening a little bit the connection between dual usb adapter cable and original usb cable... Roll Eyes
cgminer is running again Cheesy
ebereon
Sr. Member
****
Offline Offline

Activity: 407


View Profile
July 22, 2012, 01:43:34 PM
 #1439

hm,

i had the same problem with 2 units, i just used a different usb cable and it's running now for 3 days without disconnecting. With the original usb it was disconnecting every day 1-2 times.

eb
hm
Member
**
Offline Offline

Activity: 106


View Profile
July 22, 2012, 01:56:32 PM
 #1440

thank you for the tip, eb. this time, the FAIL was sitting in front of the computer... it was me not knowing what my elbow does ... (edited original post)

I should fix it a-team style with some panzertape or move my setup from my desktop to a dedicated rack.. away from cats and children and stray elbows
Pages: « 1 ... 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 115 116 117 118 119 120 121 122 ... 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!