Windows or Linux? If you're using Windows, it might well be that excessive load (not cpu usage) was only a problem under Linux, and you didn't experience it even with the old drivers. Windows. Don't really know how to tell the difference between CPU usage and load from the task manager indeed, unlike on Linux where top makes it obvious ^^ |
|
|
|
Yeah, I know it might sound confusing. The point is that CPU usage is the same, but CPU load is not. Lucky you... I have the same temps as before, around 58-59°C (Phenom 2 955 @3.6GHz) |
|
|
|
Uhm, bizarre. On my main Bitcoin rig I see no slowdown at all using both CPU cores of a Sempron for Litecoin (5.8 kH/s) and two 5870's for Bitcoin (850 MH/s). This is using ATI drivers 11.12 and AMD Stream SDK 2.5, under Linux. And CPU temperature went down from 64°C to 60°C. Works like a charm now!
+/- fixed by setting GPU miner affinity to a single core and raising its priority while lowering LTC miner priority. Still, I don't get how your CPU temperature can decrease if all you did in the end was replace a 100% CPU usage by driver mess with a 100% CPU usage by LTC miner... |
|
|
|
By the way, for those of you who are doing both CPU and GPU mining with an ATI card on the same rig, consider updating ATI drivers to version 11.12. This new version should solve the CPU usage problem, even on multiple-card setups. Yup, I noticed that too, only problem is I still can't use all my cores to mine LTC because then the GPU miner almost stops. And also when I don't leave 2 idle cores the GPU miner mines a bit slower. |
|
|
|
Using CPU instead of GPU: I wouldn't really consider it only on the pro side. It's really double-edged, can be considered both as pro and as con.
Could you please explain why you see it as a possible con? Cheaper 50%+1 attack and botnet nuisance, mainly. Not to mention the need to adapt the proof of work should FGPAs or more capable GPUs arise. Not really a huge issue IMO, but still, it's not 100% white and miraculous as some people claim. It's just another way to think the currency. |
|
|
|
==Cons==
*Less supported
* Less merchant support than bitcoin (none?)
* Not as many clients
Con: massive LTC distribution to a small number of people who mined during the first 48-72h. (ok, BTC had the same problem, but it's been +/- absorbed now, while LTC is still young) Using CPU instead of GPU: I wouldn't really consider it only on the pro side. It's really double-edged, can be considered both as pro and as con. |
|
|
|
lol I used to solomine litecoins with rpcallowip=*
I too thought that the worst that could happen would be for someone else to mine for me(don't think I forwarded the port on my router though) guess I got lucky.
Same here. There should be some kind of warning in the client when the configuration is clearly too open such as rpcallowip=*. I never thought RPC was for anything else than mining... I think I kept it at rpcallowip=127.0.0.1, though. |
|
|
|
This project started off as ONE THING and has morphed into an ugly manifestation of one man’s frustrations at never living up to any of his own expectations. I quite agree. I liked the concept behind SC 1, but SC 2 smelt so fishy from the beginning that I didn't run it for more than a few minutes. I guess it just took you longer to realize that (and a little direct help from RS  ). RS has done nothing, I am just tired of battling all the FUD. And to be quite honest right now, SC seems like more of a liability than an investment. This is sad because I like many here own NMC,SC,and LTC. I mean when I say that, all these "altcoins" have "weaknesses", and investing in them is risky as HELL. Yup, that's why I'm sticking with BTC (which is risky enough already) and only throw remaining idle CPU power to other cryptocurrencies. That's probably what quite a few other people do, which would explain why the only remaining living alt cryptocurrencies are CPU-biased (with the exception of the merged-mining one). |
|
|
|
The unknown part of the litecoin mining power is still at 80% . This kind of "unknown" amount mining a coin is quite unheard of. The fact some people here laugh it off like it's nothing to worry about it is quite concerning.
By "unheard of" you mean that SC keeps tabs on all the peasant nodes and Bitcoin uses pools because the difficulty is so high. In Litecoin the nodes are not unknown, they are just unaffiliated. That is actually the goal by the way, to have a high percentage of hashing power not under the control of a single person. That sums it up pretty well. On a side note, I'm doing like 2-3 transactions per day and didn't notice any issue with them yet, so doesn't look like a silent sneaky 50%+1 attack is going on, as far as I can see. |
|
|
|
|
I think it does no harm to include it as an unobtrusive option, so that:
- it doesn't bother a casual user that doesn't have a clue (do we really have those right now anyway?)
- it is practical for a user who doesn't want to bother grabbing an independent client. It would be nice to have at least a few options, though, such as configuring where to mine. A bit like *cough* SC actually.
Clearly not a priority feature, though.
|
|
|
|
|
I don't see how stating the obvious is trolling. Block chain size is a monotonic function in its current state. And I'm not sure there's much left to compress in the chain. At some point we'll need to think of a way to prune some of it, kind of what SC did at the launch of SC2. It's nice to be optimistic that somehow the problem will be solved before it even becomes a problem, but it's all but guaranteed...
|
|
|
|
If the network can't really handle all the TX spam how will it handle when real volume starts working and the spam is actually real transactions. Is this system scalable ? We don't really know. TX spam is quite useful in a way. Test the reliability of our systems. Many were down etc. Indeed. There's a double issue there: - first, the many tiny transactions grew the block chain with junk, plainly blocking them by a fee like it was done is good enough, it's fixed alright. - second, it seems that those many transactions made some clients become slow as hell or even crash, and here we can ask ourselves what will happen when we actually have that many legitimate transactions... |
|
|
|
I guess I should have said transfer $0.06 multiple times and quickly. The number of free "slots" is limited and there may already be multiple free transactions waiting thus it could be a "while" before a free small transaction clears. Ok, then that was what I understood. I think if someone wants to be cheap they can at least cope with the idea that maybe their free tiny transaction will be somewhat slower. When you're in a hurry usually you can afford some cent to speed up the transaction... It happened quite often that I reserved a train ticket an hour earlier for an extra 10€ after all... Time is money, etc. |
|
|
|
Again a .1 fee to transfer 6 LTC kinda sucks. Is there really a need to transfer $0.06 equivalent? Also, maybe I missed something, but I thought there was still a small amount of free transactions in a block, only they have lower priority. (or maybe this was changed too?) |
|
|
|
Or if predictability is that important, I can always fix the fee to the previous period's difficulty. So you will just use today's difficulty to figure out the fee for the next period. Sounds good indeed. And maybe to reduce variability (improve predictability even further), if it's not too much trouble, compute today's fee based on average diff of the last 2 weeks or something (like average of the last 4 diff). |
|
|
|
Though it's just a simple calculation that anyone can do if they know the difficulty, so it's not something mysterious. Yeah, I meant that more in the way that you can't predict what the fee will be like in a week (since the diff will change). I don't like unpredictable stuff. I believe lots of financial people don't like unpredictable stuff either, just see the mess at Wall Street and such.  |
|
|
|
So you want centralized fee policy? To me this proposal is the right incentive structure. It's not really centralized since noone is forced to update their client. Fees go up as the network becomes more secure. If I understood well, the point of coblee's idea is precisely to keep a stable fee (in fiat value), which is somewhat equivalent to the fees going down as the network becomes more secure. Note that I don't really mind the automatically adjusting fee, I'm just not sure it's as needed as psychologically uncomfortable. When I started using BTC, that mysterious unpredictable fee was a major turn off to me. |
|
|
|
Here's another thought I have. Ideally, I'd like to tie the transaction fees with current price of Litecoin so that the cost of spamming stays the same in terms of fiat cost. (We are still living in a fiat world whether we like it or not.) But that's impossible to do in code. The next best thing is to tie it to the difficulty. The idea is that difficulty is loosely coupled with price. If ltc price goes up, difficulty will follow as more miners jump in. And as ltc price goes down, mining becomes unprofitable, miners leave, and difficulty goes down.
[...]
Thoughts?
I'm not sure difficulty is that much linked to coin value. For instance, the BTC diff is now about what it was in early June or something, but its value is like 10 times lower. I'm not sure either if a fluctuating fee (or to put it in other words, a somewhat unpredictable fee) is a good thing psychologically. Manual adjustment from time to time, depending on the economic situation, sounds good enough to me. |
|
|
|
LOL  Now Litecoin finds itself in the same predicament that Solidcoin had to solve to fend off malicious attackers. It's going to be very interesting seeing how Coblee fixes this "bug" in the protocol. HENCE THE ENTIRE DILEMMA . You can't even tell the difference between a (small) transaction fee (=given back to miners) and a (huge) king tax (=kept by the magic fairy of everythingisfineland)... just go run the TaxCoin logo design contest or something. |
|
|
|
I like this idea too  |
|
|
|
|
Show Posts
