The ASICs themselves don't need more than 64-128 KB of SRAM per circuit to be able to hash much more efficiently than a GPU for any N.
Sure, so would FPGA's but at what cost? I mean really at what cost? Gen1 Grid seed and Alpha T will suck at VTC mining, Yeah they might do it at a better Hash/KWh out of the gate but there is much more to consider. Such as re-sale value (in case of crypto-crash) and the premium needed to aquire the ASIC's to start off with. So, fast forward to Gen 2, or more preferably Gen 3, GridSeed. Its got more ram, Its faster, its 24nm or whatever. Its pretty sweet for mining VTC by todays standards. But what about AMD/Nvidia/Intels next chips, The ones that are still just multi-million dollar computer models at the moment. Those are getting faster too. Unless scrypt ASIC rolls out way different than BTC asic in some way. I don't forecast a point I can forsee where I would rather have some $7,000K Propriety black box to get 30Mhash Scrypt (15Mhash VTC) When I can buy AMD R11 980X Ultra's for $499 MSRP. For all we know these future serious cards might hash at 2Mhs scrypt. I'm betting my money that GPU's will need to run, One way or another for a *long* time. Regardless of grid-seed or whomever is doing behind closed doors at the moment. You don't need more RAM; at the current level of RAM it is possible to mine VertCoin with approximately the same efficiency as LTC. This is true for the upcoming adjustments in N values, too. You just need to add a few circuits to regenerate some values on the fly when necessary, for whatever N value. Which means that when Joe the ASIC wafer designer who makes ASICs for Litecoin sees that VertCoin has some value, he can add these circuits for barely any design overhead to his next generation of ASICs and then we're left with very early ASIC adoption for VertCoin, which is exactly what you guys sought to avoid. |
|
|
|
All you'll end up with is a blockchain that's progressively harder to validate as time goes on, which is actually a bad thing. Anyone care to comment on this? This was one of the reasons the N-factor was rescheduled when the hardfork to KGW was released. We wanted to not only keep older GPUs in the game for longer, whilst still maintaining ASIC resistance, but we also wanted to leave open the option of running a full node (ie. a thick client, like the current Vertcoin-Qt) in the mid->far future on "modest" hardware. As Vertcoin develops, one thing we are sure to see is an Electrum type SPV (simplified payment verification) wallet, in which there is no need for the client to validate the blockchain anyway, because it's done on the server, however philosophically I'm not overly keen on the idea of making this kind of thing something that most people feel the need to use because a full client is memory hungry, I'd rather it was an option but that people could still easily run a full node (to maximise decentralisation). Yes, on a full node, the blockchain gets harder to validate as N increases, but Moores law and some awareness of history should suggest it is unlikely to be a big deal - it's like we were sat here 20 years ago talking about how by 2000 it will require a whopping 256MB of RAM to run X program, and how could anyone ever imagine having such an amount. This still doesn't address the fact that it's not any more ASIC resistant than Litecoin... |
|
|
|
"You just put some SRAM on die"...
it's cache, it's expensive. transistor count on litecoin ASICs is mostly due to memory. and they are barely in advantage.
double that, and you can not be competitive with gpus anymore.
you not only double the cost of each chip, but also you reduce yield for every wafer.
to be competitive also for next N number it's simply impossible. nobody would want to buy an asic "ready for the next N=12" simply because it would cost twice as much and the market is so volatile nobody know's what will happen.
OF course it's possible to do. but costs are over the sky
It's not that expensive at 55 nm, as the GridSeed ASICs demonstrate. You don't seem to understand how the TMTO workaround performs: you just regenerate needed values on the fly, and for every amount of memory you halve, you approximately double the amount of intops needed. This is exactly the same tradeoff as per the GPU, so no matter how much memory you use, the ASIC will always be faster and more power efficient. There is a slight advantage to using more memory (see below), but it's not huge.  The ASICs themselves don't need more than 64-128 KB of SRAM per circuit to be able to hash much more efficiently than a GPU for any N. |
|
|
|
Adaptive N-factor doesn't really matter for ASIC resistance, it's still about as easy to make an ASIC for... You just put some SRAM on die and then adjust lookup_gap. ASICs should always have huge power/hashrate advantages whenever you use scrypt, unfortunately. http://www.openwall.com/lists/crypt-dev/2013/03/21/1All you'll end up with is a blockchain that's progressively harder to validate as time goes on, which is actually a bad thing. |
|
|
|
|
Still no per die voltage control?
|
|
|
|
I would warn you guys against mining this one -- I can compile a SHA3 miner in about 20-40 min on windows and mine this. All you have to do is fork yacminer (which has GPU code for SHA3-512 already), change a few lines of code so that it's SHA3-256, remove the scrypt code and whammo, GPU miner. I think this might be an out-the-door scam as they can easily compile a GPU miner too and aren't prereleasing the source code for the testnet beforehand. so Max kaiser who is a highly respected journalist is going to put his name to this coin, that you think is a scam. somebody who is probably already a Bitcoin millionaire. if you believe that mate there is somethin wrong with ur head, wise up.  lol ... okay |
|
|
|
I would warn you guys against mining this one -- I can compile a SHA3 miner in about 20-40 min on windows and mine this. All you have to do is fork yacminer (which has GPU code for SHA3-512 already), change a few lines of code so that it's SHA3-256, remove the scrypt code and whammo, GPU miner. I think this might be an out-the-door scam as they can easily compile a GPU miner too and aren't prereleasing the source code for the testnet beforehand. |
|
|
|
|
Anything >1.5 GH/W you should sell now is my guess, you'll be able to buy 28 nm hardware for more or less nothing later this year so you can always buy back when hardware is actually priced reasonably.
Now is probably the time to sell Bitcoins and buy Litecoins or Peercoins too is also my guess, the former because ASICs are hitting the network and because block reward halving isn't far off, the latter because blockreward halving also isn't far off. I'm holding 1:1:1.
|
|
|
|
If you use our RPI image as configured, you will have a reliable mining system and will get updates as they are made available. Here's my personal system mining away: http://setup.hashfast.com/rpi/-Phil Just curious, what core clock are you running this at? I ran mine at default (550) for a day and it got about 400GH/s, 0.37% rejects, and 1.83% errors and showed 360GH/s on eligius. Overnight I started it at 560 and it shows 412GH/s, 0.36% rejects, and 9.26% errors with 388GH/s showing on eligius. Should I be worried about 9.26% error rate? They run at 80C/80C/70C/72C right now. No issues here with errors, there were connectivity problems with my one but since that's been fixed I'm getting ~0.2% errors on both. |
|
|
|
|
48h stable on 2x Batch 2 BJs on Windows. The internal watcher turns it off if there's a problem, cgminer 3.11.0 catches it and auto-hotplugs it back in if there is an issue. Takes about 10s.
Additionally they no longer reboot themselves very much -- starting to wonder if there's a burn in period for the hardware, and then it works better after that.
|
|
|
|
There are a lot of people complaining about centralization right now, but I doubt we'll run into the problem long term. Here's why I doubt it'll be a problem: http://bitcoincharts.com/charts/mtgoxUSD#rg60zczsg2011-05-01zeg2011-12-31ztgSzm1g10zm2g25zvAfter the big 2011 boom, we got to the point where everyone had video cards and the price was slowly dropping, along with the value of those video cards. At this time large scale miners who had previously been hoarding GPUs began selling them off en masse, redistributing the hardware. It's probably going to be worse for ASICs, because they have no other purpose than Bitcoin. If the mining companies can't turn a profit mining with them themselves, they're going to dump them on consumers as hard and fast as they can -- bumping the prices down for us. As in 2011, this will likely be a temporary state and Bitcoin will eventually begin to surge again. I suspect the mining companies may turn out to be big long term losers in this game. |
|
|
|
|
Stability with these is HIGHLY related to ambient temperature... at -4 C ambient they're very stable, whereas at 22C ambient they crash a lot. Not that it super matters, 3.11.0 cgminer restarts it whenever it crashes anyway.
24 hours stable hash rate so far.
|
|
|
|
There is a known problem with the USB stack on windows. This is a cgminer known issue, which is why we recommend a linux-based mining solution and provide the RPI with every BJ. The best you could do is make some sort of a script that restarts cgminer, or better yet windows itself, after mining stops or even just after 8 hours or so.
Hopefully once we get cgminer and the firnmware stable, we can look at possible windows solutions. Windows in general is not a stable platform, which is why most servers on the internet don't use it.
-Phil
You can reboot it by script every 2h on windows like this with python: import os, subprocess, time
while True:
print("Starting cgminer...")
p = subprocess.Popen("C:\\Users\\my-pc\\Desktop\\mycgminerfolder\\mine.bat")
time.sleep(7200)
print("Terminating cgminer...")
p.terminate()
time.sleep(5)
where mine.bat is what you use to launch it I've been having zero stability issues so far, though. |
|
|
|
For all the people here that are running on something other than the RPI's, Here's the source code for cgminer 3.9.0h2 (same version we're currently using on the RPI). This version has somewhat correct hashrate reporting, and has a few other things, such as the per-die voltage and temperature readout. It seems to be the most stable during our testing. One of our top Engineers is currently working with Con Kolivas right now to get some of these things improved. Thanks Con! cgminer 3.9.0h2 source (can be complied on most Linux distros): http://setup.hashfast.com/cgminer-3.9.0h2.tar.gzI'd love reports back to see if this improves your mining performance/stability. Again; please ignore the strings of HW errors, this should not be a problem. -Phil Can we edit per die voltages in this version? I'll make a note *not* to hotplug fans into the BJ when it's running too, as that caused a shutdown. The third fan connector works fine, in any case. |
|
|
|
|
Okay I have my BJs set up. 3.11.0. So far, so good.
I have to go to work (they're already pissed at me for staying home to receive this fedex shipment), but these are my thoughts so far:
- Risers and screws were jingling in both units when I received them, the problem is the extra set of risers on the bottom seem to fall off. HASHFAST, if you're reading this, tell CIARA to tape these to the inside of the case in a bag instead of extra screwing them in.
- Hashrate for first unit is 398 GH/s and the second 405 GH/s, the one is pulling 460 W while the other is pulling 476 W (Blue Planet energy meter, usually more accurate than a Kill-A-Watt). Temps are 76 C and 79 C. Not exactly the efficiency we were promised, and not a lot of room for OCing, oh well. Pool confirms these hash rates.
- Would be nice to get a voltage control in cgminer, I want to try undervolting.
- Comes with a nice Seasonic 1000 W Platinum PSU, unfortunately there is no 24+4 pin and 8-pin 12V cables for a motherboard in case you want to recycle it. Also, shows that even at 90% efficiency these are actually less efficient than my Bitfury rig running at 85% efficiency and overclocked.
But, well, at least they're up and running! Seem to work nicely as space heaters.
|
|
|
|
Okay I may seem stupid but im new to this and I cant get connected using the raspberry pi at all. So does anybody know the drivers for the BJ I switched it to winUSB but I still cant get Cgminer to read it. If someone could please help me setup cgminer as I cannot get the pi working after many attempts and I am new to mining any help would be great.
Load drivers with zadig http://zadig.akeo.ie/ |
|
|
|
Well, a big "f*ck you" to Hashfast for figuring out another way to screw batch-1 customers even more. They shouldn't be doing anything at all with subsequent batches before honoring all commitments to batch-1, like the damn MPP that got us all to buy from them and fund the operation in the first place. The same MPP that they now refuse to give any shipment-timeframe information about.
I think we all lost. I paid 22 BTC for a miner that's going to return me 3.3 BTC. |
|
|
|
|
Show Posts
