yep, that 2 is exactly what im talking about..
wait a little longer and another thread might reset too.. after my change all my threads all stay 19 forever....
Ah I see now. Since you've already dove into the code and disabled the function, is there any reason why the function in question wouldn't just set everything to lowest priority by default? Why would it need to change it around? I'm afraid to dive in myself, otherwise I'll spend days fixing it, hehe. |
|
|
|
knightmb - just curious, if you check not just the main process, but all the thread processes (ps -eflL | grep bitcoin - need the L, or else it will just show the main process), do you see the other thread processes change the priority after a little while ? When I change the priority or renice, it will just stick for the main process, but some of threads will change priority everytime it goes to the generate coin function..
Feedback from the ps -elfL | grep bitcoin command [knightmb@KnightMB ~]$ ps -eflL | grep bitcoin
0 S knightmb 11200 6781 11200 0 10 99 19 - 114169 poll_s 17:17 ? 00:00:02 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin
1 S knightmb 11200 6781 11202 0 10 99 19 - 114169 hrtime 17:17 ? 00:00:00 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin
1 S knightmb 11200 6781 11203 0 10 99 19 - 114169 hrtime 17:17 ? 00:00:00 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin
1 S knightmb 11200 6781 11204 0 10 99 19 - 114169 hrtime 17:17 ? 00:00:00 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin
1 S knightmb 11200 6781 11212 0 10 99 19 - 114169 sk_wai 17:17 ? 00:00:00 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin
1 R knightmb 11200 6781 11213 0 10 99 19 - 114169 - 17:17 ? 00:00:00 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin
1 S knightmb 11200 6781 11214 0 10 99 19 - 114169 hrtime 17:17 ? 00:00:00 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin
1 S knightmb 11200 6781 11215 0 10 82 2 - 114169 hrtime 17:17 ? 00:00:00 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin
1 R knightmb 11200 6781 11216 86 10 99 19 - 114169 - 17:17 ? 00:40:37 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin
1 R knightmb 11200 6781 11219 85 10 99 19 - 114169 - 17:17 ? 00:40:11 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin
0 R knightmb 13291 12282 13291 0 1 80 0 - 1842 - 18:04 pts/1 00:00:00 grep --color bitcoin
Anything in that look out of place? I did notice one that was nice to "2" instead of "19" [edit] I see now from the other topic, I'm running the client, the other was the server daemon, might be a bug with just the daemon, not sure though. |
|
|
|
On a side note, I've tracked down the other GUI issue. The "minimize to tray instead of taskbar" is what was eating up all the CPU on my system. After I turned this off, the issue was resolved with Runaway CPU. This only seems to affect the 64 bit Client, as the 32 bit Clients I have don't seem to be affected by this. I did notice on the 64 bit Client, what happens is, it spawns multiple "tray" icons until X server finally kills over, so I guess I should submit that as a bug to somewhere?  |
|
|
|
It automatically raises it, I don't think nice 20 ./bitcoin will help to be honest. I think some people have set higher priorities for themselves in /etc/security/limits.conf, and when -20 isn't available as a nice level, a lower priority is tried. So, I think the dirty hack of editing /etc/security/limits.conf might fix it. I wondered about that, but I've never noticed any issues on a dual-core 64bit system.
I don't have any problems on my quad core system here either! That may be the issue because you can't "Nice 20" anything, 19 is the max  So far, I've "Nice 19" 3 clients (one 64 bit and two 32 bit) for the last hour and they haven't changed the Nice level on me yet. I figured since the process is started at that level, it would remain for all child processes spawned afterwards. I could be wrong though, I'll check again in another few hours to see. |
|
|
|
I guess the worry here is that it's possible that bitcoins could end up being worth a lot more than they are today. For example, if 0.01 BTC works out to be the equivalent of $1 today, then that built-in 0.01 transaction fee is far too high.
If there is some way to make the transaction fee scale with the worth of the currency that would be best, but I can't think even conceptually how that could be possible. It's not like the currency has any idea how much it is worth in real terms.
Ideally, you raise the ceiling in this situation. Right now, there is a 21 million coin limit. So as the value goes up, so does the ceiling so to speak. Unless one person has 20 million bitcoins and the rest of the world has to trade with 1 million, there should be no reason go in the opposite direction for the value to value comparison. But I do understand exactly what you mean though because some world currency is traded like that where 1 unit of XYZ country equals 20,000 of another, so small decimal values have to be used. Since the transaction fee can't get below 0.01, the value should always be greater than the fee, otherwise, people are not making any financial sense. It would be like living in a city where it cost $10.00 to drink from a water fountain. The business model should fail in light of free, public water fountains outside, so who would bother to pay that much money when the alternative makes more financial sense. Same way with the 0.01 fee limit, people already expect it and won't value things beneath it as it wouldn't make financial sense. If the lowest possible fee is 0.01, why would anyone sell anything for less than that? You would put yourself out of business quickly. |
|
|
|
There has been a problem in settings the "nice" level on Linux.
A programmer who wasn't familiar with Unix/Linux used the highest priority (-20) instead of the lowest priority (20)!
So, we have a bug.
Yeah, that always gets me too. You would think a negative number would mean less and positive number means more, but it turns out "Nice" works the opposite of that, you want it to be more "nice" so you want a higher number, LOL. I checked the 32bit Linux clients, they run a Nice level of 0, so I guess it's running equal time with everything else. On the Windows clients, Bit Coin runs at "normal" priority as well. It's easy to start the process in low priority via command line for both of them, so for now I can do that to manually control their priority  |
|
|
|
|
I wonder if you can point multiple clients to the same file over the network? I'm guessing it that might not work well if multiple clients are trying to modify/update the same database at the same time?
|
|
|
|
That is right that it acts as a bridge for the nodes that -connect to it, however, it does not get their funds. All the nodes are still independent.
All that -connect does is this: instructs the bitcoin client to connect to that peer as the one and only peer it connects to. Otherwise, it operates as normal, just as if that had been the only other peer in the world other than you and you didn't use -connect.
Thanks for clearing that up, I wasn't sure. Actually kind of glad too, keeps it from having the "all the eggs in one basket" so to speak.  |
|
|
|
I did a forum search, didn't see this mentioned by anyone yet. I have 5 Bit Coin clients, some running Windows Bit Coin, others running Linux Bit Coin. I only have one 64 bit Linux system, but when I run Bit Coin, after about 10 minutes, the CPU usage runs away and brings the system to a stall unless I kill the Bit Coin application. Now I have 2 other computers running a 32 bit Linux Bit Coin client and they work just fine, no runaway CPU. I've tried running the 32 bit Bit Coin on the 64 bit Linux system, but the same thing still happens. My 64 bit Linux system has a dual-core processor, and even when I choose the "use only 1 processor" option, after a while Bit Coin ends up using both CPU to the 100% max that it can. Is this a bug that only affects 64 bit Linux users at the moment? Using the latest version 0.3.0 from the front page of the website. System OS: Linux Mandriva 2010.0 (64 bit) RAM 16GB Processor - Intel Dual-Core 3.06 CPU Feedback or advice welcome. Edit by Xunie: I merged this thread with the other "Bitcoin slowing down your Linux system?" thread, so things my be confusing for a second, heh. |
|
|
|
I have a quick question about the connect=x.x.x.x option - what exactly does it do? I understand that it "points" a certain bitcoin client to another PC on the LAN, but what does this mean for the bitcoin application itself? Does all coin generation funnel to the wallet that is held on the target PC? Or does a client that is pointed to another local PC just funnel its connections through port 8333 on that PC, and still manage its own wallet? Just curious.  It acts as a bridge for the other computers. When you only have one IP address, you can technically only forward your connection to a single computer (on port 8333) so the other computers on your network that are running BitCoin won't be able to accept inbound connections from others. From what I've seen, you have one computer that kind of acts like a server. The other computers on your network connect to it and thus can download all the blocks more quickly to begin processing. The difference is, instead of one computer acting alone to generate coins or process blocks, you now have *other* computers doing part of the work for it and report the results back to it. I haven't run this long enough to see what effect is has, I'll report back here when I do. My guess is that all the coin generation is funneled back to the "main" computer that all the clients connect to. So, while each client may not get a piece of coin generation, there is no reason why you can't transfer coin around to the clients after they are generated at the main computer (since you have control/access to all of them anyway). It may take a while, but when I do see some results, I'll post it here because I'm curious myself. |
|
|
|
Chances to generate bitcoins shouldn't depend on network connectivity above a certain base level. If you can receive blocks in a timely manner (somewhat low latency and a decently low packet loss), generating should only depend upon CPU speed (and maybe some other internal specs like memory speed).
Forwarding ports helps the network since more people can connect to you, but I'm running on a university network so I can't forward any ports and it works fine for me.
-connect is a command line option. Right click on your shortcut for Bitcoin, go to properties, and add "-connect 192.168.0.100" (no quotes, and replace the IP with the right one for you) to the end of the path.
Took me a while to figure this out, the command line is wrong (had to dig into the source for this) It's -connect=192.168.0.100 You forgot the equal sign Otherwise, it doesn't work for either Windows or Linux |
|
|
|
|
Show Posts
