I will test it, but the link is not working :-/
Whoops, sorry. Fixed. |
|
|
|
OK, thanks! Think that pretty much covers everything. Something truely bizarre is going on here. Unless running http://www.makomk.com/~aidan/fpgaminer_cm1_160_test_nods_pullup.bit on FPGA1/2 and fpgaminer_cm1_160_test_ds.bit on 0/3 shows immediate improvement - and it's a long enough shot that I'm not sure it's even worth testing to be honest - I'm gonna say screw it, wait for Glasswalker's stuff. |
|
|
|
Same behavor, pair 0/1 is working U ~5 (53 shares/10min). Pair 3/2 orange led on 98% of the time, U ~0.1(1 share/10min).
eb
OK, that's just really really weird. I'm guessing 3/2 should work with those bitstreams if you load everything but FPGA1 and leave FPGA1 with no bitstream loaded on it? |
|
|
|
I tested again with my best board which is running 200Mh/s bitstream in twin_test setting with 2.81U/m each (running 4 days), but the same here, your bitstream is running at FPGA0 and 1(~4U/m) but 2 and 3 is not working anymore, best is 0.6U/m. I think frequency is instable or problems with noise etc. So if anyone get a Bitstream done like you, it wont run propably.  OK, that's really weird because this runs at the same input frequency at twin_test. You can try running http://www.makomk.com/~aidan/fpgaminer_cm1_160_test_ds.bit on FPGA0/3 and http://www.makomk.com/~aidan/fpgaminer_cm1_160_test_nods.bit on FPGA1/2 but it's a long shot - other than that I'm stumped as to what could be going on. |
|
|
|
The correct one is the "fpgaminer_cm1_160_test_b21_b22.bit" but it's not working as it should. When I flash it to FPGA0 and 1 then FPGA2 and 3 does not work anymore even if I let twin_test on FPGA3. I tested every comination but I don't get better results as with twin_test bitstream. It could be that the controller needs an update to get it work. Does the timing met with that bitstream?
The behavor is the same as with the shipping bitstream, FPGA2 and 3 have the orange led on to most of time, sometimes it turns off when a new job comes in, but turn on after ~3 seconds.
Curious. According to the constraints file I have, FPGA0 and FPGA1 are a pair and FPGA2 and FPGA3 are also a pair, and because this is an Icarus-like bitstream both pairs should be totally independent of each other (you need to run a seperate miner on each). Also, the logic that forwards work from the first FPGA in the pair to the second is a straight wire with really lax timing requirements so I'm not sure how that could break either... Edit: Yeah, I suspect the controller is doing something interesting. |
|
|
|
Whoops. Obviously I wasn't paying enough attention when looking at the UCF file.
can you change that with the fpga editor? i would test it if you have the new bitstream  In theory, hold on a second... Are you sure it should be that way around and not vice-versa? I reckon B21 as TxD and B22 as RxD from the UCF that Enterpoint have released? |
|
|
|
makomk, did you use the correct ucf settings? as far as I know it should be: # TTL level serial port: ja3 = rxd, ja2 = txd
NET "extminer_txd<0>" LOC = "B22";
NET "extminer_rxd<0>" LOC = "B21";
I saw in your git you still have the icarus pinout in you ucf file? This bitstream is not working. eb Whoops. Obviously I wasn't paying enough attention when looking at the UCF file. |
|
|
|
If you think this as an investment, then its terrible. How many ppl have got these board worked at intended speed? and if you did, for how long? I'm not a technical person but spending a month of tinkering is not acceptable. Maybe we should now know why BFL had a long waiting for their production.
As a potential customer, may i know exactly why you sell the boards without a working bitstream?
It was sold as a DEVELOPMENT BOARD. If you had really been following the thread "very closely", you would know this. Having followed the thread, I don't think Enterpoint released the information required to actually develop on it until about a week ago. Unrelatedly, in theory this should be a working 160 MHz Icarus-style bitstream for the Cairnsmore1 board but I don't have an actual board to test it on: http://www.makomk.com/~aidan/fpgaminer_cm1_160_test.bit Since this is a proper Icarus-like bitstream, I think you'd want to set SW1 and SW6 according to the "Twin Build" diagram on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html and SW2-5 according to the "Initial Shipping Build" diagram. Treat as two Icarus boards in your miner. Note that I have no idea if this will work in practice; ngzhang's clock domain crossing logic looks rather hairy... |
|
|
|
... The options to achieve this are a bit esoteric though - it's the nature of the beast really. I just did a SmartXplorer run on a dual-core and it hit Fmax = 166 MHz in under 24 hours; not quite what I was aiming for but not too shabby.
Can you please tell us what options you use? I think that is the biggest problem to get something out the works. Whole bunch of the nicked pretty much wholesale from ztex's project files, which is where the hashing code comes from originally. Unless I've screwed something up the cairnsmorewip branch at https://github.com/makomk/Icarus/tree/cairnsmorewip should have them in. It's probably just a problem of running SmartXplorer against that to search for a seed that works well. |
|
|
|
And the part that is a pain though, is his opensource code doesn't include any project files, settings, or configurations, and it requires a fairly elaborate setup mixing multiple tools for various subsections of the bitstream in order to get it to build at all without failing hard. None of this is documented or provided (without extraordinary measures in digging up the info)  You should be able to build ngzhang's Icarus miner using just ISE's built-in synthesis tools, it's actually a relatively straightforward combination of bits from various existing miner projects that were originally meant to be built that way. The options to achieve this are a bit esoteric though - it's the nature of the beast really. I just did a SmartXplorer run on a dual-core and it hit Fmax = 166 MHz in under 24 hours; not quite what I was aiming for but not too shabby. |
|
|
|
This is dmesg output. [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? |
|
|
|
|
My last GBP withdrawal went into my bank account on, I think, the 16th after waiting several days over the weekend. No idea what withdrawals have been like since then. Looking in IRC phantomcircuit claimed that the web banking interface to their GBP account wasn't working last night when he went to do a batch of withdrawals, so in theory no-one should've got any overnight.
|
|
|
|
Problems with Intersango today. Trading has been halted and some bitcoind issues also. I would like to know what is going on.
A bad order wedged the trading engine and something is making bitcoind perform badly, according to phantomcircuit in #intersango. |
|
|
|
I've also noticed this issue and am looking into it.
I'm running a recentish git version of the Bitcoin client and noticed the same thing happen on that a couple of days ago too, actually - started the client after having it closed for a while, and the balance on the summary page showed some bitcoins I'd received in the meantime as unconfirmed when the transaction had over 100 confirmations. Must be an upstream bug in the Bitcoin client. |
|
|
|
I don't know Rackspace's procedures nor your procedures; but I can offer you a clean explanation of not being able to restore the individual backups. I'm kinda familiar how other kinda-cloud provider does backups. All the backups are encrypted with a transactional key. There are separate keys for each VM and for each incremental backup. The keys are stored only as long as the accounting record for the VM is open. Once the VM is deleted and summarized for the purpose of charging all transactional keys are deleted zeroized (I forgot to use the proper lingo). The encryption key deletion zeroization is a security precaution against many inside attacks as well as against compromised backup media. The above procedure is actually an important selling point. If you don't do that internaly for the 3rd party data then you should start doing this as soon as practical to lower your own liability. http://en.wikipedia.org/wiki/Hardware-based_full_disk_encryptionhttp://www.hgst.com/internal-drives/self-encrypting-drives/Rackspace also supposedly allowed automated password reset via e-mail and didn't have any way to lock an attacker out of their management console once they'd authenticated, if we believe what Bitcoinica. Using this kind of protection against VM or backup compromise would be the equivalent of having an elaborately-boobytrapped steel front door which randomly maimed people who opened it wrong and then, around the back, having another access route though a rotted garden gate and a doorway secured with a single-lever lock. It'd be completely nuts as an approach to security. |
|
|
|
Core Credit LTD is a New Zealand Limited Company and the General Partner of Bitcoinica LP.
Ah this is new info. On 2012/06/07 Amir claimed that Core Credit Limited is Tihan's Parent company (the Limited Partner). See: https://bitcointalk.org/index.php?topic=84042.msg946751#msg946751 Core Credit LTD was renamed to Bitcoinica Consultancy LTD significantly after the events occurred.
Yes it happened on 2012/05/30 and it was never explained why this happened despite me asking repeatedly. Nevertheless the legal incorporation date for Bitcoinica Consultancy is 2012/01/30 according to the NZ documentation. Look at the documents posted up on the New Zealand Companies House website for the company you just linked: here. If you look through it, the company was registered as Core Credit Limited on the 30th of January 2010 and it was renamed to Bitcoinica Consultancy LTD on the 30th of May. Your own references show that phantomcircuit is right and you're lying through your teeth. This isn't new information either, someone noticed it and brought it up ages ago. There is no way you could possibly have interpreted the linked reference to mean what you say it does. |
|
|
|
Does it matter what file system is on the HDD that we are attempting to recover from?
Not particularly, so long as it's not encrypted or compressed. Some filesystems may give a better chance of success than others though. |
|
|
|
**There is a known side channel attack against AES on Linux servers that use the "Completely Fair Scheduler" (CFS), Windows is well known as a security nightmare. OpenBSD is our recommended deployment platform. Are you sure that's a good idea? The paper in question references <a href=" http://www.cs.huji.ac.il/~dants/papers/Cheat07Security.pdf">another attack that can be used to stealing large amounts of CPU time</a>, which apparently worked on the BSDs at the time of writing and could presumably be used to launch a very similar side channel attack on BSD systems. |
|
|
|
All payments sent thankyou all so much for all your help!! i definitely wont be so careless next time! however another lesson learnt on how much shit is left on your computer after a format, and thank god for that.... this time anyway.. Yeah, I noticed your payment to me this morning - thanks! Glad to hear that it all worked out in the end and you managed to get your bitcoins back! |
|
|
|
|
Show Posts
