Stacking Time
gorgeous! spiccioli |
|
|
|
yohan, any news on updated FPGA firmware able to use all four FPGAs per board? My boards are hashing nicely but those red/yellow leds always on (and which remind me the Spanish flag  ) make me feel a little sad  spiccioli |
|
|
|
For the last hour, payments have been offline while we did some wallet maintenance. Payments are now enabled again.
Several of you noticed experienced disconnections from ABCPool in the recent period (aside from the Amazon power failure of course..). During the past few days further maintenance was performed to alleviate this. Maintenance is still ongoing in order to get ABCPool stability back to the levels you were used to. Nevertheless you should already notice significant improvements now!
Happy hashing,
MC
MintCondition, right now my stats page says that last update was at 15:05 UTC, right now is 17:23 UTC. spiccioli |
|
|
|
--icarus-timing I've seen serveral numbers, in this thread, for the --icarus-timing parameter, but most of them seem wrong when used with twin_test.bit. Cgminer sees each hashing FPGA as a full icarus board; a real icarus board splits the nonce range between the two FPGAs it has onboard, so, since in our case only one FPGA in each pair is active, our FPGAs are doing just half of the nonce range, the other half is thrown away (or sent to the disabled FPGA, I don't know). Given that twin_test.bit hashes at 190MH/s every hash takes 1s/190MH or 5.2632 ns. so this is the first number. How long does it take to scan the "full" nonce range? 4GH / 2 (because half nonce range is not hashed) / 190MH/s or 11.3 seconds. So, the second number should be 112, I've started mine with --icarus-timining 5.2632=111
I've used 111 to be on the safe side. Sice I've started it this way the yellow led is always off, so FPGA utilization is full, but now the board speed is around 210-230 MH/s on cgminer with my pool reporting an hashing speed of 185 MH/s. spiccioli |
|
|
|
This works, but it's saying that utf8 is not a reccomended filesystem as it will be case sensitive, In hopes of getting to the how-to eventually I would like one of you mighty wizards of linux to post a spell that specifies a filesystem that wont be case sensitive.
Isoviki, it is just a warning, you only have to read from it so it should work. You write the usb key from windows, then attach it to VirtualBox and do the mount spell from inside VirtualBox and then read from it. spiccioli |
|
|
|
I'm starting to think (I'm thinking loud here ) that the --icarus-timing parameter can be omitted without problems (I'm not using it) at least in the initial phase of testing. Running without it makes cgminer request more work from the pool (not a real problem on p2pool which already has a 10 seconds on average share time) and throw away part of every getwork without hashing it. Throwing away a part of a getwork does no harm to one's expected payouts. But, in my tests, it works a lot better and hashing FPGAs have the yellow led always off, which means that they hash continously. Every time the yellow led shines the FPGA is not hashing and this lowers the hashing speed reported by pools. spiccioli |
|
|
|
Ok a couple of things we have observed partially from all your comments and things we have see here:
First thing is on Linux machines there may be a problem with USB3 ports. We think that might be a Linux driver problem.
Powering up the 12V supply to your Cairnsmore1 before plugging in USB may help as will a reasonable power USB hub. We think there is an inital surge that in some PCs upsets the host controller. With the 12V powered first the on-board regulator supplies the power rather than a big impluse demand on the USB. A powered USB hub shields the host from the main part of the inital surge which is why it helps. Power hubs can have different rating but if sepcs are available go for one with 500mA capability, or better, on each port.
yohan, I'd say powered usb hubs are a must, I cannot attach more than three boards to my pc if not through a powered usb hub (if I try all kind of problems happen to the point that the whole pc freezes - btw, it's not a PC but an HP thin client, this could be part of my problem). How much power (max power) does the board take from the usb port? spiccioli. |
|
|
|
I have just put what I think is the simplified instructions for Windows users to flash the Twin build into Cairnsmore1. It's linked on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html . I have not tested the flow yet of this document so there might be something I missed but I will test it on myself probably in the morning. If anyone using it spots anything let me know and I will update it accordingly. yohan, on page 11, of Virtual Box Installation Windows, there still is a space between -I and xc6lx150.bit. spiccioli |
|
|
|
user@t5570:~$ sudo ./xc3sprog -c cm1 -p 0 -Ixc6lx150.bit twin_test.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 674 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
http://sourceforge.net/mail/?group_id=170565
Check Sourceforge for updates:
http://sourceforge.net/projects/xc3sprog/develop
Using Libftdi,
DNA is 0xb9c83ffc56e627ff
JEDEC: 20 20 0x18 0x00
Found Numonyx Device, Device ID 0x2018
256 bytes/page, 65536 pages = 16777216 bytes total
readusb waiting too long for 9 bytes, only 0 read
error Resource temporarily unavailable
terminate called after throwing an instance of 'io_exception'
Hi again it was the USB hub port and/or usb cable, moving the card to a different cable/hub port fixed the problem and I was able to program this cards as well as the other ones. spiccioli. |
|
|
|
So I updated the controller FPGA on board serial n. 8 and it went withouth problems. Then I started flashing twin_test.bit into my boards and I've found that outside of virtual box it takes a lot less to flash a FPGA. user@t5570:~$ time sudo ./xc3sprog -c cm1 -p 3 -Ixc6lx150.bit twin_test.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 674 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
http://sourceforge.net/mail/?group_id=170565
Check Sourceforge for updates:
http://sourceforge.net/projects/xc3sprog/develop
Using Libftdi,
DNA is 0x390dc1e841c73bf1
JEDEC: 20 20 0x18 0x00
Found Numonyx Device, Device ID 0x2018
256 bytes/page, 65536 pages = 16777216 bytes total
Verify: Success!
real 2m50.569s
user 0m4.340s
sys 0m10.517s
Less than 3 minutes per FPGA. spiccioli. Doing the direct programming of the FPGA is fast but won't stay when you power cycle. Loading ointo the SPI Flash takes longer but is there every time you power up the board. Yohan, I'm loading it into the SPI, I'm using -I see my command above, but I'm not doing it from VirtualBox, but from a linux pc using your xc3sprog. I have a different problem, though, when I try to flash board serial nr. 136, it throws this error: user@t5570:~$ sudo ./xc3sprog -c cm1 -p 0 -Ixc6lx150.bit twin_test.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 674 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
http://sourceforge.net/mail/?group_id=170565
Check Sourceforge for updates:
http://sourceforge.net/projects/xc3sprog/develop
Using Libftdi,
DNA is 0xb9c83ffc56e627ff
JEDEC: 20 20 0x18 0x00
Found Numonyx Device, Device ID 0x2018
256 bytes/page, 65536 pages = 16777216 bytes total
readusb waiting too long for 9 bytes, only 0 read
error Resource temporarily unavailable
terminate called after throwing an instance of 'io_exception'
for both FPGA0/3. I can program them without problems if I don't try to flash the SPI memory. user@t5570:~$ sudo ./xc3sprog -c cm1 -p 0 twin_test.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 674 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
http://sourceforge.net/mail/?group_id=170565
Check Sourceforge for updates:
http://sourceforge.net/projects/xc3sprog/develop
Using Libftdi,
DNA is 0xb9c83ffc56e627ff
Are there differences from board 136 on? I had no problems with board 8 and 104. spiccioli |
|
|
|
So I updated the controller FPGA on board serial n. 8 and it went withouth problems. Then I started flashing twin_test.bit into my boards and I've found that outside of virtual box it takes a lot less to flash a FPGA. user@t5570:~$ time sudo ./xc3sprog -c cm1 -p 3 -Ixc6lx150.bit twin_test.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 674 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
http://sourceforge.net/mail/?group_id=170565
Check Sourceforge for updates:
http://sourceforge.net/projects/xc3sprog/develop
Using Libftdi,
DNA is 0x390dc1e841c73bf1
JEDEC: 20 20 0x18 0x00
Found Numonyx Device, Device ID 0x2018
256 bytes/page, 65536 pages = 16777216 bytes total
Verify: Success!
real 2m50.569s
user 0m4.340s
sys 0m10.517s
Less than 3 minutes per FPGA. spiccioli. |
|
|
|
well done ebereon, ill sort another donation when im at my wallet machine did you stick to the twin_test.bit or go with the 190M_V3.bit bitstream for the SPI and proof for the -I<bitstream.bit> is in the man page ( http://xc3sprog.sourceforge.net/manpage.php) d'oh Makes one wonder why every other option has a space but this one  spiccioli |
|
|
|
If you want to flash both with one command, just do: xc3sprog -c cm1 -p 0 -Ixc6lx150.bit twin_test.bit && xc3sprog -c cm1 -p 3 -Ixc6lx150.bit twin_test.bit This will flash the first (0) and if it was ok, then the last one (3). And that takes ~16 minutes to finnish, just take a cup of coffee  Thanks! Great finding that -I thing, I'm gonna flash mine as well. spiccioli |
|
|
|
I'm tired of testing now.
18 days of testing to get the unit hashing faster, but no success here.
Ebereon, while I can feel you're tired and I don't have definitive answers, I'd like to add some thoughts. Am I right that you are on p2pool? See this, three boards, serial: 8, 104, 136 cgminer version 2.4.3 - Started: [2012-06-27 21:01:05]
--------------------------------------------------------------------------------
(5s):2492.7 (avg):2080.6 Mh/s | Q:116837 A:42219 R:381 HW:0 E:36% U:14.5/m
TQ: 6 ST: 7 SS: 225 DW: 7010 NB: 278 LW: 14068 GF: 226 RF: 272
Connected to http://pool.abcpool.co with LP as xxxxxxxxxxx
Block: 00000167d598249e60d7faab8784a2c8... Started: [21:22:44]
--------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
ICA 0: | 379.9/346.6Mh/s | A:7188 R:63 HW:0 U: 2.47/m
ICA 1: | 379.8/346.7Mh/s | A:6279 R:57 HW:0 U: 2.16/m
ICA 2: | 379.9/346.8Mh/s | A:7242 R:68 HW:0 U: 2.49/m
ICA 3: | 379.8/346.8Mh/s | A:7144 R:56 HW:0 U: 2.45/m
ICA 4: | 379.9/346.8Mh/s | A:7227 R:61 HW:0 U: 2.48/m
ICA 5: | 379.6/347.0Mh/s | A:7140 R:76 HW:0 U: 2.45/m
--------------------------------------------------------------------------------
on ABC. Can you try/did you try a different pool? Maybe the fast p2pool chain creates some problem which I don't seem to have. Maybe it's just me that was lucky with the cards... I don't know, I see that ICA1: is slower than the others, this is FPGA3 on serial nr. 8, but sometimes it is ICA0: which is slower but it never slowed down (up until now, at least) to a few MH/s. And I don't have any icarus-timing thing in my command line which is: ./cgminer -S /dev/ttyUSB2 -S /dev/ttyUSB3 -S /dev/ttyUSB5 -S /dev/ttyUSB6 -S /dev/ttyUSB8 -S /dev/ttyUSB9 -o http://pool.abcpool.co -O x:y -o http://p2pool.soon.it:9332 -O w:z -Q 7 --failover-only
I have p2pool as failover pool, but it was used just a little today in the early morning, CET time, while ABC was having problems. I'm powering them through PCIe connectors from a 500W Antec ATX PSU and on board 8 I did not reprogram the spartan 3. spiccioli. ps. I'm also waiting for something that makes it possible to use all FPGAs on each board, though. |
|
|
|
someone in Italy?
yes me, the other day spiccioli |
|
|
|
I followed these instructions, except I'm using the latest cgminer, which ive been using with the twin_test and shipping_test bitstreams.
I'm running the icarus v3 one at the moment, and on the board i can see it flashing green to say its found shares, but cgminer never reports it. Any idea why?
EDIT: after 10 minutes it has actually submitted 1 share, even though i've been watching the green lights flashing on the cairnsmore1 quite a few times now...
cgminer don't show you invalids, if you use mpbm then you will see much invalids. Every green flash means found share or invalid with this bitstream. My board is now running ~20 hours and was working without invalids 14 hours, but now hashrate is down to 20Mh/s and much much invalids (80% both fpga's)). So the frequency/noise problem take it's place again after running correcly 14 hours. That's realy anoying. I have tested everything now to get the unit working better as with the shipping bitstream, but nothing working longer than 14 hours. All what we can do is, waiting for a better bitstream from enterpoint. ebereon, while it's true that cgminer doesn't show you invalids, if your hashing speed, as seen by the pool, remains more or less the same it means that there are not invalids. I don't have invalids, my hashing speed is more or less constant even after a couple of days (with both mpbm and cgminer). I've found that using --icarus-timing short or long makes no difference, so I've left cgminer think it is attached to an icarus board and it hashes happily with yellow leds on active FPGAs almost always off and ABC pool that tells me I'm at 680-780 MH/s using two boards with twin_test.bit. So it is something different, IMHO, which is creating problems to you. You're on a netbook with windows 7, if I'm not wrong, could it be that your netbook usb ports don't deliver enough power? Could it be that power management/power saving functions of your netbook create problems in the long run? Can you try to attach your board to a PC (not a netbook) and/or a PC with linux? I don't want to start a flame war on windows vs linux, I use both when I have to, but I'm on linux and neither I have problems with cgminer nor I had problems with mpbm while I used it. I went back to cgminer because Mpbm was not giving enough work to my FPGAs which had the yellow leds on even for 10 seconds in a row every now and then. spiccioli. |
|
|
|
rjk, here the image of the boards, on the left serial nr 62-008 and on the right, 62-104 with its military green hue  By the way, if someone needs it (and trusts my build) here it is cgminer 2.4.3 built as a 32 bit linux program without OpenCL/ADL and with icarus support only. http://p2pool.soon.it/cgminer/cgminer-2.4.3Download it, issue a to make it executable and it's ready to go. Given that it is easy to build one, I'll remove it in a few days. spiccioli |
|
|
|
How about this for a conspiracy theory - Members of BFL worked in R&D for crypto chips used by NSA for cracking. After Gavin's talk at the CIA, a plan was devised to secretly build an ASIC mining cluster that could take over the network, just in case bitcoin ever became a viable competitor to the fiat currencies of the world as they slowly crumbled. BFL was set up as a front company and the vanilla sha256 bitstreams and chip designs they had already developed were modified for bitcoin mining. The FPGA chips from an outdated NSA cracking cluster were re-purposed for the initial BFL singles and the serial numbers were removed to reduce the chance that they could ever be linked back to the government contract in which they were purchased. The existing ASIC fabs were redesigned for the "SC" and a slew of moles posing as miners and bitcoin businesses orchestrated a plan to project the illusion of a large market of miners who trusted BFL and received their products as promised. This was done to lure any potentially serious investors away from competing ASIC efforts and into their honeypot, thereby allowing them to dominate the entire market. This included fabricated botnet stories to cover for the incremental ramp-up of the NSA hashing cluster, which actually already controls over %60 of the hashrate while running only a small fraction of total capacity. Now the US government has a bitcoin "takeover switch" that they can turn on at any time to control all transactions in the network. Nobody will question BFLs questionable business practices because they have a govt. contract. They will slowly sell a trickle of ASICs to the public to recoup some of the redevelopment costs and all the ex-TIA guys in the back room at the pentagon get a fat raise and a retirement gift cigar from Howard Schmidt. Nice theory, I lol'd a little bit. Maybe the NSA has figured out how to pwn a box running any given OS via the USB port and trick cgminer into reporting the correct hash rate etc, while silently taking over the network and forwarding hashes to a rendezvous point where a 51% chain that reverts all the way back to the genesis block is being built. Their chip recognizes a specially crafted transaction (more or less like the BIP16 transaction that stopped that botnet a few months ago) and bricks itself. So in a few minutes total network hashing power drops to just a few TH/s and then they can start their 51% attack destroying the bitcoin network 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 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. 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 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. |
|
|
|
|
Show Posts
