|
At what sort of hashrate do you think Diff10 becomes useful.
As someone is does around 1.4-1.6Gh/s I'm not sure I quiet fill that yet? or do I?
|
|
|
|
|
It should be an option.
I'd understand if you went diff10 almost exclusively once ASIC units start mining, though.
|
|
|
|
|
There is another meeting soon. Issues like this are going to be brought up again Gabit.
|
|
|
|
For sure, I just wanted to make sure I wasn't setting wrong expectations  Yeah documentation will come soon. The readme is there and it is "complete", but it is rather vague. And doesn't cover any "special" cases, or odd problems. It basically just covers hardware settings, and installing (referring out to the enterpoint instructions, or assuming access to ISE Impact and a JTAG cable). Once we have the next version out that's the last major feature change. After that the bitstreams should remain functionally identical, just with performance improvements or internal structural improvements (without changing overall functionality at all). Eventually way down the road more documentation will be needed for the new protocol but that's a ways off still. Once I get the next release out and it's working, (dynamic clocking) then I'll take a bit of time to do a full documentation writeup, and hopefully the community can help me flesh it out once I get a foundation laid down. If you want any help writing up documentation, you know I've tested it enough |
|
|
|
Matt apparently just made 100 btc, seems like a good days work (~1k dollars).
I would be very amazed to find out I actually get 100 btc out of this. In case I do here is my address: 18MjdXpTyek3ESTPc2HCQnATv1jY4acUeR I am trying to think what to do next if this does not work for the OP. Now you could delete everything (always have a backup of wallet.dat no matter what) and start over. Delete meaning the blockchain and everything else except the client but basically that was already done. So what else could be the problem? Hmm You do realise if what you suggest doesn't work, and what you just suggested now, is what my original suggestion was. Guess where that btc should go  I admit the rescan should work. true. i got lucky and just happened on this thread at the right time. starting from scratch does not seem reasonable since it was just done. Well done Matt, lucky indeed. |
|
|
|
It's mostly a Cryptographic changes, that would be an issue, but as long as it still uses SHA256, it should be possible to still use it, minor software (mining) changes needed could cope maybe? |
|
|
|
Matt apparently just made 100 btc, seems like a good days work (~1k dollars).
I would be very amazed to find out I actually get 100 btc out of this. In case I do here is my address: 18MjdXpTyek3ESTPc2HCQnATv1jY4acUeR I am trying to think what to do next if this does not work for the OP. Now you could delete everything (always have a backup of wallet.dat no matter what) and start over. Delete meaning the blockchain and everything else except the client but basically that was already done. So what else could be the problem? Hmm You do realise if what you suggest doesn't work, and what you just suggested now, is what my original suggestion was. Guess where that btc should go I admit the rescan should work. |
|
|
|
|
Matt apparently just made 100 btc, seems like a good days work (~1k dollars).
|
|
|
|
Could be worse, you could of bought some at 9.5 Guess who?  < ----- Me... |
|
|
|
|
Just follow these steps:
Shut down the Bitcoin program.
Copy your backed-up wallet.dat into your bitcoin data directory.
If copying into existing profile, delete files blk*.dat to make the client re-download the block chain.
*pray to which ever god of your choosing*
Generally speaking aslong as you have these backups, you are fine.
|
|
|
|
|
I've had more problems than most, I wouldn't disagree there. Also I'm not blaming your bitstreams, just like I said before I don't know what is causing the problems I am experiencing. I get it working eventually, it just doesn't always stay stable, I can't pin down what is causing it yet.
Documentation is the only thing left, you guys working flat out, I don't expect a lot, It's why I do my best to write mine up.
|
|
|
|
I'm dying to hear if the conference call has taken place and what the feedback is  It's finished. This time I had some kind of problem with my place so it turned from a video chat to a text-only meeting soon. Though I can confirm taht we saw his face and heard his voice for some time So you have established Friedcat is a human and not a bot.... Well, I guess it is a start Well the vast majority of the talk happened via skype text messages, so their is a good chat log, if it's okay to post it. |
|
|
|
What's the current status regarding the bounty? The way I see it, all requirements for paying out the bounty are met... (I cannot judge point 6, documentation)
When I had it stable I agreed with many, that yes it did meet the requirements. However I've had stability problems since and I don't know what the cause is. However they haven't really finished a polished version yet and apparently working together now, so I guess that new combined one once ready will win it. |
|
|
|
With the COM ports disappearing, that sounds like either a hub, cabling, motherboard port, driver, or FTDI issue. (with the last being the least likely, but still possible).
it could be due to power surging, a tiny variation in power supply (a minor surge on your power lines) combined with a power spike on the board or something might have thrown the FTDI into a wierd state.
Or cabling/hub being slightly out of whack could throw the FTDI into a wierd state too (which wouldn't be corrected without a power cycle.)
The fact the red led was still flashing, implies the 4 worker FPGAs were continuing to work just fine, but since there was no com port there was no way to give them more work.
Is this windows or linux? If it's linux try monitoring dmesg and/or kernel logs. Also if you can run udevd in verbose logging mode it could help show any wierdness on the USB bus that preceeds (and leads up to) this issue.
All very possible. I'm going to start by removing the hub from the equation. |
|
|
|
When they disabled, did they disappear from the host? (the com ports disappeared?). Or did they simply stop mining? Did invalids shoot up? Were the LEDs doing anything wonky on the boards when it occurred? Can you give any further details on the exact behaviour you saw?
It did appear as if the com ports disappeared. Doing a quick usb unplug and plug back in, didn't bring them back. Power cycle was needed. Invalids didn't shoot up, seemed pretty normal and low. So very low rejects and no hardware errors. The LEDs were doing what they usually do when it's not mining when I found it, blinking a steady red and yellow. If it happens again I'll try provide more details. |
|
|
|
Btw Glasswalker, they all decided to disable themselves like a domino effect around 6am this morning, so they last around 36 hours.
Strangely no Hardware errors, but I did have to cold restart them to get them mining again. (thankfully now they are perma-flash).
Updated the icarus options, So lets see if that changes anything.
This was just this one board right? Did anything else happen around that time? Major change in environmental? (heat, power fluctuation, and so on). How is it connected through usb? (hubs/powered hubs) and so on. For it to run rock solid for 36 hours then up and puke sounds more to be related to something off the cairnsmore board (environmental, or infrastructure) unless the board itself is seriously faulty. Let me know, we'll see if we can diagnose. Nope, both boards did it. they both collapsed 30seconds apart. They are unpowered hubs, I could try having them powered separately. I don't think their was any major environmental issue, but I can't rule it out, I wasn't awake at 6am, just found what was left in the logs. Any suggestions on how to diagnose it, I've not looked into cgminer more verbose commands, could it tell me more why they became disabled? |
|
|
|
I'm dying to hear if the conference call has taken place and what the feedback is It's going on right now... |
|
|
|
So if Glasswalker's bitstream does a full nonce range on a single FPGA, yes indeed it would be
--icarus-options :1:1
or even
--icarus-options :1
(both mean the same thing)
I only went off what you said earlier in the thread. Not like I really went into finding out what it did. It has worked beautifully since I done the change. I will update and try :1:1 next time. No worries - just thought I should explain it Trying out a :1:1 setting now Btw Glasswalker, they all decided to disable themselves like a domino effect around 6am this morning, so they last around 36 hours. Strangely no Hardware errors, but I did have to cold restart them to get them mining again. (thankfully now they are perma-flash). Updated the icarus options, So lets see if that changes anything. |
|
|
|
So if Glasswalker's bitstream does a full nonce range on a single FPGA, yes indeed it would be
--icarus-options :1:1
or even
--icarus-options :1
(both mean the same thing)
I only went off what you said earlier in the thread. Not like I really went into finding out what it did. It has worked beautifully since I done the change. I will update and try :1:1 next time. |
|
|
|
|
Show Posts
