Topic: LTC FPGA discussion! - page 10. (Read 23663 times)
I'll be watching this..
By the way, if you need a C/C++ developer for the project, PM me.
We aim to please.
Please me by sending me one, uncle. Sheeit! I'm one dissatisfied pre-customer. :trlf: :trlf: :trlf:
We aim to please.
"why smoothie isnt dead after drinking so much sugar, why simran is forever alone etc."
This made me LOL so hard.
Also, I am very much looking forward to LTC fpgas, if not to mine with for myself, then for the increased security of the LTC network and less nuclear power plants running the LTC network.
So excited
I'd like to volunteer my services. 
I'm an IRL electrical engineer. I also have all the tools I'd need to do hardware & software level debugging at home (scopes, power supplies, etc).
I think their in-house guy is more than capable of doing such things, but I'm putting it out there just in case.
I'm an IRL electrical engineer. I also have all the tools I'd need to do hardware & software level debugging at home (scopes, power supplies, etc).I think their in-house guy is more than capable of doing such things, but I'm putting it out there just in case.
Not just anyone can be an "Internet Engineer" you do first have to speak with authority.
Are you certain that every cell of memory is used each time?
Even if not, how long do the 1024 32-bit words have to stay valid until the next call to scrypt() overwrites all of them?
When doing 1 kilohash per second a completely new scrypt() is executed every 1ms, which overwrites all of the previous data.
The maximum refresh period for most of DRAM chips is on the order of 64ms.
For the homework solve the following problems:
1) how is the natural scrypt() refresh period affected by pipelining the implementation?
2) how is the natural scrypt() refresh period affected by reading the memory by a wider units than the 32-bit words native to scrypt()?
If you solve the above without cheating you can upgrade yourself from "internet engineer".
I'd just like to add that even if this thing can only put out as many Kh/s as a GPU, costs the price of a GPU, uses less wattage compared to a GPU, and will just run on its own while doing all that, it'd be well worth it for me and for many others (I'm sure).
This is obviously at the very least our aim, but anything better of course would be better.
Are you certain that every cell of memory is used each time?
Even if not, how long do the 1024 32-bit words have to stay valid until the next call to scrypt() overwrites all of them?I honestly don't know.
Are you certain that every cell of memory is used each time?
Even if not, how long do the 1024 32-bit words have to stay valid until the next call to scrypt() overwrites all of them? You are right, it should work without refreshing. The question then is what is greater: The amount of invalid shares due to memory errors from non-deterministic refresh or the overhead from the refreshing circuitry?
I don't get it. Are you kidding? What memory errors? scrypt(1024,1,1) provides perfect memory refresh for free, unless you somehow slowed it down, e.g. by a breakpoint in debugging.I suspected as much too but wasn't sure there wouldn't be any "holes" in it.
Are you certain that every cell of memory is used each time?
You are right, it should work without refreshing. The question then is what is greater: The amount of invalid shares due to memory errors from non-deterministic refresh or the overhead from the refreshing circuitry?
I don't get it. Are you kidding? What memory errors? scrypt(1024,1,1) provides perfect memory refresh for free, unless you somehow slowed it down, e.g. by a breakpoint in debugging.External DRAM, needs to dedicate FPGA resources for refreshing circuitry but memory is a lot cheaper and there might be spare logic blocks anyway (so that what I did bet on)
Why would you even enable refresh for the scrypt(1024,1,1) scratchpad? What is the probability that given memory cell in the scratchpad RAM will not be accessed within its maximum refresh period?You are right, it should work without refreshing. The question then is what is greater: The amount of invalid shares due to memory errors from non-deterministic refresh or the overhead from the refreshing circuitry?
External DRAM, needs to dedicate FPGA resources for refreshing circuitry but memory is a lot cheaper and there might be spare logic blocks anyway (so that what I did bet on)
Why would you even enable refresh for the scrypt(1024,1,1) scratchpad? What is the probability that given memory cell in the scratchpad RAM will not be accessed within its maximum refresh period?
By the way, would it be possible to re-target this miner to alt. cryptos other then LTC?
Then plugging it to this feed would make a great multi-miner machine:
http://dustcoin.com/mining
Since the "engineers" only dabble in the most vague details my answer will have to do:Then plugging it to this feed would make a great multi-miner machine:
http://dustcoin.com/mining
Merge mine?No.
Switching back and forth from scrypt (litecoin) to others like bitcoin? Depends. They would need to specifically account for it, and this will add some amount of complexity to their implementation. It's doable but not likely.
By the way, would it be possible to re-target this miner to alt. cryptos other then LTC?
Then plugging it to this feed would make a great multi-miner machine:
http://dustcoin.com/mining
Then plugging it to this feed would make a great multi-miner machine:
http://dustcoin.com/mining
It should work for any sCrypt coin. Other than that, the other coins use SHA-256 which BTC FPGA/ASICs can mine.
By the way, would it be possible to re-target this miner to alt. cryptos other then LTC?
Then plugging it to this feed would make a great multi-miner machine:
http://dustcoin.com/mining
Then plugging it to this feed would make a great multi-miner machine:
http://dustcoin.com/mining
I'm never mad, just tired. Litecoin has gone from being a hobby to a major source of income for me now, as my graduate stipend is frankly awful as the gov't cuts more money from science and edlngineering, and my wife also has a disability that keeps her from working, so I'm starting to worry more about the health of the chain and of course I'd be worried if a scammy company like BFL would come out trying to sell Litecoin hardware.
The professionalism is my concern, not whether or not there are FPGAs or whatever. I can always sell my GPU rigs and buy FPGAs later.
The professionalism is my concern, not whether or not there are FPGAs or whatever. I can always sell my GPU rigs and buy FPGAs later.
Nice, man! You know I'm just trolling lol <3
I got love for all of y'all! We don't need BFL touching LTC at all. BFL Josh can such my dick while I'm hollering "187"!
I'm never mad, just tired. Litecoin has gone from being a hobby to a major source of income for me now, as my graduate stipend is frankly awful as the gov't cuts more money from science and edlngineering, and my wife also has a disability that keeps her from working, so I'm starting to worry more about the health of the chain and of course I'd be worried if a scammy company like BFL would come out trying to sell Litecoin hardware.
The professionalism is my concern, not whether or not there are FPGAs or whatever. I can always sell my GPU rigs and buy FPGAs later.
The professionalism is my concern, not whether or not there are FPGAs or whatever. I can always sell my GPU rigs and buy FPGAs later.
Jump to: