2.1.5 compiled on ubuntu 11.10, i7 2700k @ 4.5GHz
Not sure what the problem is exactly, this happened a few times
I've seen quite a few boooos today as well but I don't know that that has anything to do with the new miner. As a data point, I get 38.5kh/s on 3 cores of a 4.3ghz 2500k. So, about 13kh/s per core (verified by running 4 cores/4 threads). Previously, I was getting about 10.5kh/s per core. There seems to be something wrong with the new miner: Round Shares
Your Valid: 4630
Your Stale: 500, 10.8% Using 2.1.4 I got 0.5% stale This is happening on both the Windows and the Unix builds edit: seems okay now, wondering if the problem is actually pool-x.eu Earlier today I was getting a lot of stales but so was the rest of the pool, maybe it has nothing to do with the miner At the moment I'm getting 60 kh/s on my 2700k @ 4.5Ghz. A 25% increase in hash rate is impressive. |
|
|
|
[2012-03-07 18:09:55] accepted: 123/140 (87.86%), 65.64 khash/s (yay!!!)
[2012-03-07 18:09:58] accepted: 124/141 (87.94%), 65.64 khash/s (yay!!!)
[2012-03-07 18:10:01] accepted: 125/142 (88.03%), 65.64 khash/s (yay!!!)
[2012-03-07 18:10:04] accepted: 126/143 (88.11%), 65.64 khash/s (yay!!!)
[2012-03-07 18:10:07] accepted: 127/144 (88.19%), 65.64 khash/s (yay!!!)
[2012-03-07 18:10:09] accepted: 128/145 (88.28%), 65.64 khash/s (yay!!!)
[2012-03-07 18:10:12] accepted: 129/146 (88.36%), 65.64 khash/s (yay!!!)
[2012-03-07 18:10:14] accepted: 130/147 (88.44%), 65.64 khash/s (yay!!!)
[2012-03-07 18:10:17] accepted: 131/148 (88.51%), 65.64 khash/s (yay!!!)
[2012-03-07 18:10:19] accepted: 131/149 (87.92%), 65.64 khash/s (booooo)
[2012-03-07 18:10:21] accepted: 131/150 (87.33%), 65.64 khash/s (booooo)
[2012-03-07 18:10:23] accepted: 131/151 (86.75%), 65.64 khash/s (booooo)
[2012-03-07 18:10:25] accepted: 131/152 (86.18%), 65.64 khash/s (booooo)
[2012-03-07 18:10:25] accepted: 131/153 (85.62%), 65.64 khash/s (booooo)
[2012-03-07 18:10:25] accepted: 131/154 (85.06%), 65.64 khash/s (booooo)
[2012-03-07 18:10:25] accepted: 131/155 (84.52%), 65.64 khash/s (booooo)
[2012-03-07 18:10:25] thread 2: 3162 hashes, 7.06 khash/s
[2012-03-07 18:10:25] accepted: 131/156 (83.97%), 65.22 khash/s (booooo)
[2012-03-07 18:10:26] accepted: 131/157 (83.44%), 65.22 khash/s (booooo)
[2012-03-07 18:10:26] accepted: 131/158 (82.91%), 65.22 khash/s (booooo)
[2012-03-07 18:10:26] thread 7: 6165 hashes, 7.46 khash/s
[2012-03-07 18:10:26] accepted: 131/159 (82.39%), 65.62 khash/s (booooo) 2.1.5 compiled on ubuntu 11.10, i7 2700k @ 4.5GHz Not sure what the problem is exactly, this happened a few times |
|
|
|
i have heard on btc-e chat, that mtrlt made a half-speed of the reaper13-DEMO...
the full version should work twice as fast...
so the ltc-gpu-mining is profitable down to ~0.0007 btc/ltc and not for the public with ~0.0014...
i think there must be a new ltc-algo to save the public from the grifter(s)...
Edit: the half-speed-reaper13-DEMO-release seems to be the compromise between giving the release or not
The speeds reported by mtrlt were the same as the release for the demo, the rumor as I understood it was that his new SC2 miner was supposed to be twice as fast for GPU I've wondered if the reason mtrlt has not released the source code is because it may borrow heavily from ssvb's code, as ssvb was the one to solve the in-place hashing of ltc Anyway, this outlines the difficulty in actually a creating an algorithm that can not easily be serialized so that it will run faster on a CPU than a GPU. I've been thinking about it some, and I've wondered if using multiple algorithms and randomizing a number of the settings for each (then possibly the order in which they are used) to generate 10s or hundreds of thousands of possible algorithms, only one of which could possibly decrypt the next block. The difficulty in parallelizing the data would have to do with the difficulty of assembling a large number of algorithms sequentially and then assessing them. It's hard to think of something that a CPU can due better than a GPU when it's a repetitive task based on the same operations of a dataset... Having to brute force the actual construction of the algorithm may be something that a GPU might struggle with, though. edit: There's a pretty neat paper of algorithms and their runtime comparisons for GPU/CPU. There are sorting and physics algorithms that perform significantly slower on a CPU as compared to a GPU. www.cs.utexas.edu/users/ckkim/papers/isca10_ckkim.pdfMore info on the mentioned sorting algorithm: Our 4-core implementation is competitive with the per-
formance on any of the other modern architectures, even
though Cell/GPU architectures have at least 2X more
compute power and bandwidth. Our performance is
1.6X–4X faster than Cell architecture and 1.7X–2X faster
than the latest Nvidia GPUs (8800 GTX and
Quadro FX 5600). Also note that as the set size becomes larger, GPUs run out of memory and are unable to even compute the set, although extrapolating from the data even if they were able to it would still be slower than for the CPU. http://pcl.intel-research.net/publications/sorting_vldb08.pdfThe algorithm was subsequently surpassed with this GPU one, however for small data sets Intel's TBB parallel sort is still faster. http://mgarland.org/files/papers/gpusort-ipdps09.pdfApparently over the past few years there has been a battle between Intel and nVidia to try to find things that CPUs and GPUs do better than one another, and there is a wealth of well-cited literature out there. The algorithm was again overhauled, and CPU-based radix/merge sort still manages to beat out GPUs in a number of cases: Comparing CPUs and GPUs: In terms of absolute performance
of CPU versus GPU, we find that the best radix sort, the CPU radix
sort outperforms the best GPU sort by about 20%. The primary rea-
son is that scalar buffer code performs badly on the GPU. This ne-
cessitates a move to the split code that has many more instructions
than the buffer code. This is enough to overcome the 3X higher
compute flops available on the GPU4 . On the other hand, the GPU
merge sort does perform slightly better than the CPU merge sort,
but the difference is still small. The difference is due to the absence
of a single instruction scatter, and the additional overheads, such as
index computations, affecting GPU performance. http://dl.acm.org/citation.cfm?id=1807207So, it seems reasonable that an algorithm which is heavily dependent on the radix sort implemented will perform faster on CPUs as compared to GPUs. It's important that only non-multifield data be used, because a very fast GPU algorithm was implemented for that recently: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5713164There's also a tree search algorithm here which runs significantly faster with smaller data sets on CPUs/MICA versus GPUs; if it could be integrated into an encryption algorithm it might destroy GPU performance www.webislands.net/pubs/FAST__SIGMOD10.pdf |
|
|
|
|
You said my solo mining instructions did not work; did you try running litecoin daemon as an administrator from the command prompt (type cmd into the start menu, right click, run as administrator)? If it's running correctly it should at least give you some kind of error in reaper that it's downloading the block chain or something. The command prompt will also tell you if the daemon gets some kind of error (it will kill itself and return an error if your configuration is messed up).
|
|
|
|
|
Cayman: 69xx
Barts: 68xx
Cypress: 58xx
Juniper: 57xx
Tahiti: 79xx
Trying to use the kernel for Barts from Cayman doesn't seem to work... (connects to pool, but only gives stales)
|
|
|
|
here's the bottom line: lots more people are mining SolidCoin than LiteCoin, as far as i can tell. LOTS.
Solidcoin's difficulty is only usually 3-5k right now... It was 10 times that before the most recent block reward nerf. Hardly anyone is actually mining SC2 because as soon as the difficulty goes up you go from losing 90% based on the amount of electricity you used to 95%, which I guess is unacceptable for pretty much everyone. |
|
|
|
This is my screen. I still don't know why other cant mine.
The kernel build uses code that is specific for 58xx or 69xx GPUs... only people who own those may mine, it crashes or mines stales for everyone else. |
|
|
|
|
release the source code guys
In the meantime, nothing bad has happened. The chain is alive and being hashed more than ever and it still has a lot of value.
|
|
|
|
|
Here's a good question... why isn't mrlrt releasing the source code for the miner? What's he waiting on?
|
|
|
|
Remember, mtrlt released to the public the *demo* version, aka slow version. This version was just to prove Scrypt is more efficient on a gpu than it is on a cpu.
Using dishwara's numbers from that screenshot (219kh/s), and an estimated 5870 power consumption of 188w, that makes for 1.16kh/w.
Using data from the litecoin wiki it seems a top of the line cpu gets 25kh/s at 125w, that makes for 0.2kh/w.
Being generous, and assuming the litecoin wiki is out of date, and using poolers latest miner, lets just give the cpu 50kh/s at the same 125w, that is still only 0.4kh/w.
Scrypt is *not* gpu unfriendly.
BTW, the current private version of Reaper is getting over 2kh/w when mining scrypt.
Comparing GPU and CPU mining and the power required... Why is it that the power used in the computations are only the consumption of the GPU? GPU's can't do squat without a CPU. CPU can mine even with a crappy Intel IGP. When comparing power numbers, please use the wall usage numbers. Not only this, but, unlike mining btc, high voltage is required to the onboard ram on the gpu as hashing speed for ltc is both ram and gpu dependent. So, ltc mining will always have added power draw as compared to btc mining where the memory can be underclocked. Further, a 95w sandy bridge cpu can easily do 30kh/s undervolted to 75w or 35kh/s stock.. Undervolted 1055ts can do about 32kh/s at 80w. This is all done without maximizing the thermal limits of the hardware like with this new gpu miner, too. |
|
|
|
3) GPU mining makes it easier to 51% the chain. It would be easy for a decently sized GPU farm to 51% the chain.
I think I'm most worried about the last one.
The addition of GPU mining to bitcoin actually enhanced security of the coin. I saw this discussed on BTCe with Artforz and it was generally held that the more expensive the mining hardware required, the more reinforced the bitcoin chain becomes. What I think would really add a lot to LTC is to implement a chain that halves in six months but does so incrementally, that is, every block or 200 blocks or whatever decreases a certain percent, with 50% block size at six months. Liquidcoin has proved this to be easily possible. |
|
|
|
|
Something I've wondered:
Why are you using N=1024, r=1, and p=1 for scrypt? Why didn't the recommended values from the paper, N=1024, r=8, p=1 get used?
|
|
|
|
Does not work with pools for me To solo on windows: 1. Download litecoin daemon from github: https://github.com/coblee/litecoin/downloads2. Go to C:\Users\{yourcomputer}\AppData\Roaming\litecoin\ and create litecoin.conf. 3. Put this in it: # Network-related settings:
# Run on the test network instead of the real bitcoin network.
#testnet=1
# Connect via a socks4 proxy
#proxy=127.0.0.1:9050
# Use as many addnode= settings as you like to connect to specific peers
#addnode=69.164.218.197
#addnode=10.0.0.2:8333
# … or use as many connect= settings as you like to connect ONLY
# to specific peers:
#connect=69.164.218.197
#connect=10.0.0.1:8333
# Do not use Internet Relay Chat (irc.lfnet.org #bitcoin channel) to
# find other peers.
#noirc=1
# Maximum number of inbound+outbound connections.
#maxconnections=
# JSON-RPC options (for controlling a running Bitcoin/bitcoind process)
# server=1 tells Bitcoin to accept JSON-RPC commands.
#server=1
# You must set rpcuser and rpcpassword to secure the JSON-RPC api
rpcuser=user
rpcpassword=password
# How many seconds bitcoin will wait for a complete RPC HTTP request.
# after the HTTP connection is established.
rpctimeout=30
# By default, only RPC connections from localhost are allowed. Specify
# as many rpcallowip= settings as you like to allow connections from
# other hosts (and you may use * as a wildcard character):
#rpcallowip=10.1.1.34
#rpcallowip=192.168.1.*
# Listen for RPC connections on this TCP port:
rpcport=9332
# You can use Bitcoin or bitcoind to send commands to Bitcoin/bitcoind
# running on another host using this option:
rpcconnect=127.0.0.1
# Use Secure Sockets Layer (also known as TLS or HTTPS) to communicate
# with Bitcoin -server or bitcoind
#rpcssl=1
# OpenSSL settings used when rpcssl=1
rpcsslciphers=TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!AH:!3DES:@STRENGTH
rpcsslcertificatechainfile=server.cert
rpcsslprivatekeyfile=server.pem
# Miscellaneous options
# Set gen=1 to attempt to generate bitcoins
gen=0
# Use SSE instructions to try to generate bitcoins faster. For muliple core processors.
#4way=1
# Pre-generate this many public/private key pairs, so wallet backups will be valid for
# both prior transactions and several dozen future transactions.
keypool=100
# Pay an optional transaction fee every time you send bitcoins. Transactions with fees
# are more likely than free transactions to be included in generated blocks, so may
# be validated sooner.
paytxfee=0.00
# Allow direct connections for the ‘pay via IP address’ feature.
#allowreceivebyip=1
# User interface options
# Start Bitcoin minimized
#min=1
# Minimize to the system tray
#minimizetotray=1 4. Make this your litecoin.conf in the reaper directory: host localhost
port 9332
user user
pass password
protocol litecoin
worksize 256
aggression 18
threads_per_gpu 1
sharethreads 20 5. Run litecoind.exe and let it catch up with the network. 6. Run reaperDEMO.exe. If it throws a kernel error, go into the directory. There should be a litecoin-reaperv13.XXXXX.bin file where XXXXX is your architecture. Rename litecoin-reaperv13.Cayman.bin to litecoin-reaperv13.XXXXX.bin. Reaper should work fine now. |
|
|
|
Also I wish BTC was more accepted so I can grab a taco or a burrito and pay in BTC and that payment takes less than 5 secs (quicker than a debit card).I like 1 click and here's my tacho/burrito in bitcoins.
TacoCoin 2.0 will bring discrete taco vending, trusted nodos sabrosas, a 35% sour-cream and guacamole tax, and will be acceptable at Taco Bell, Casa Bonita, AND Chipotle. The price in pesos of the currency will be tied to the price of ground beef through our infamous currency manipulation and centralized banking, or "jodidos económicas". |
|
|
|
|
RealSolid is the best troll account ever
|
|
|
|
I think it's obvious as to who is losing a battle when you start talking for everyone. "almost every conscious being in the world" . Haha, wow, a few teenagers on a competitors forum who don't understand SolidCoin but dislike some concepts is "almost everyone" . Ah you teenies with your biebers and inexperience in life. Funny to the "mature" people that see it.
Ah, that's the CoinHunter I remember! |
|
|
|
|
Okay, if you double that quantity you get a little less than the quantity of the CPF (133128 versus 131754 coins in the CPF) and if you look at the CPF you can see that it actually getting a 10% tax per block rather than a 5% tax. Well, whatever, but what happened to the 133128 - 131754 = 1374 coins? There are no outgoing transactions from the CPF... Can we see coins the CPF spends? Did they go somewhere not the CPF?
edit: Also, CH, you're surprisingly level headed tonight, not flying off the handle at all!
|
|
|
|
|
Hey,
sTcMHFiviET9ZSNBsMkNBwnfUsCMUX3Xo8 has
12997 lost
sR24466tcHbW7yhsU5TpQst5H6Kw8vDNSj has
53567 lost
That's a total of 66564.
Where do the other coins in the CPF come from?
Also, the CPF can be spent, correct...? if the goal is eventually to eventually transfer all coins from the trusted nodes into the CPF, doesn't that mean that all the coins are eventually spendable by whoever controls the CPF account? So the trusted nodes are all spendable, just not right now?
|
|
|
|
|
I got 46kh/s on a 2600K @ 4.5GHz after compiling the miner on ubuntu (which was a pain in the ass).
|
|
|
|
|
Show Posts
