Bitcoin Forum
October 01, 2016, 07:02:09 AM *
News: Due to DDoS attacks, there may be periodic downtime.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: Bitcoin 0.3.1 released  (Read 7071 times)
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile
July 15, 2010, 09:40:34 PM
 #21

On Windows, the priority of the Coin Generation is still net for normal. If you run BitCoin in Generate Coin mode, then load up something to eat up all the CPU (like CPU hog for example: http://www.microtask.ca/cpuhog.html) you'll see that both BitCoin and CPU hog share the CPU 50/50 instead of CPU Hog taking all the CPU and BitCoin running only on idle/low process. The khash/s is also reduced in half, so further evidence that the threads are not running in a lower than normal prioirty.
I was not able to reproduce this.  I have dual-proc, so I ran two memory hogs.  Bitcoin got 0% of CPU according to the task manager.  The khash/sec meter stayed stuck because it couldn't get any CPU to update it.

Do you have dual-proc?  Are you sure you weren't running a single processor hog?
1475305329
Hero Member
*
Offline Offline

Posts: 1475305329

View Profile Personal Message (Offline)

Ignore
1475305329
Reply with quote  #2

1475305329
Report to moderator
1475305329
Hero Member
*
Offline Offline

Posts: 1475305329

View Profile Personal Message (Offline)

Ignore
1475305329
Reply with quote  #2

1475305329
Report to moderator
1475305329
Hero Member
*
Offline Offline

Posts: 1475305329

View Profile Personal Message (Offline)

Ignore
1475305329
Reply with quote  #2

1475305329
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1475305329
Hero Member
*
Offline Offline

Posts: 1475305329

View Profile Personal Message (Offline)

Ignore
1475305329
Reply with quote  #2

1475305329
Report to moderator
1475305329
Hero Member
*
Offline Offline

Posts: 1475305329

View Profile Personal Message (Offline)

Ignore
1475305329
Reply with quote  #2

1475305329
Report to moderator
1475305329
Hero Member
*
Offline Offline

Posts: 1475305329

View Profile Personal Message (Offline)

Ignore
1475305329
Reply with quote  #2

1475305329
Report to moderator
knightmb
Sr. Member
****
Offline Offline

Activity: 308


Timekoin - Save Electricity, Don't Waste It!


View Profile WWW
July 15, 2010, 09:48:29 PM
 #22

On Windows, the priority of the Coin Generation is still net for normal. If you run BitCoin in Generate Coin mode, then load up something to eat up all the CPU (like CPU hog for example: http://www.microtask.ca/cpuhog.html) you'll see that both BitCoin and CPU hog share the CPU 50/50 instead of CPU Hog taking all the CPU and BitCoin running only on idle/low process. The khash/s is also reduced in half, so further evidence that the threads are not running in a lower than normal prioirty.
I was not able to reproduce this.  I have dual-proc, so I ran two memory hogs.  Bitcoin got 0% of CPU according to the task manager.  The khash/sec meter stayed stuck because it couldn't get any CPU to update it.

Do you have dual-proc?  Are you sure you weren't running a single processor hog?
LOL, I think you are right. I've got waaaayy too many PCs around me and it's difficult to keep track of which is single core, dual core, quad, 8 core, etc. I'll test it again on the single proc PC and see what happens.

knightmb
Sr. Member
****
Offline Offline

Activity: 308


Timekoin - Save Electricity, Don't Waste It!


View Profile WWW
July 15, 2010, 09:56:09 PM
 #23

Yeah, you are right, works just fine. *smacks forehead for not counting cores ahead of time*, so scrap the prioirty bug then, I'll go back and edit my post. Works just fine on Windows 2000, XP, Vista, and 7

satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile
July 15, 2010, 10:07:35 PM
 #24

On the Linux client (64 bit), the "minimize on close" will still minimize to tray (causing X server hang after a short while by spawning multiple tray icons).
I updated the first post with a link to rc2 for linux with the fix for this.  Please check that this is fixed for you.  Thanks!

http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile
July 15, 2010, 10:10:19 PM
 #25

The listreceivedbyaddress and getreceivedbyaddress commands are duplicated in bincoind help. (Same in 0.3.0.)
Yes a bug.  It'll have to be fixed in the next version.
db
Sr. Member
****
Offline Offline

Activity: 279



View Profile
July 15, 2010, 10:23:52 PM
 #26

On Linux 0.3.0 gets nice 0 when generating but with 0.3.1 the generating thread gets nice 19 while the other threads stay at 0. Looks good.
RHorning
Full Member
***
Offline Offline

Activity: 210


View Profile
July 15, 2010, 10:29:28 PM
 #27

I'm not exactly sure what the "Start BitCoin on window system startup" is suppose to do?

In Windows, it should put Bitcoin.exe into "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run" for the system registry... or as an alternative into "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"

I don't see either happening, although it did get put into the "Startup" folder.  That is so Windows 95ish (just kidding..... Microsoft has so screwed this up that it isn't even funny).  I would recommend the registry settings for a number of reasons including the fact that most software puts the startup in that location, even though I personally find the startup folder to be more attractive and how most software on Windows should behave.

I haven't done a full forensics with this new version in Windows, but the install seemed to go without a hitch for me... using the Windows install.

1FLK3uUT3Vup5JtkGJVXKHAoS3AZWPcKdv
adavid
Newbie
*
Offline Offline

Activity: 2


View Profile
July 15, 2010, 10:39:33 PM
 #28

But, the priority of the threads all seem to be "nice" properly I think. The ones using all the CPU time are nice to 19, so the others that are 0 and 2 aren't using any CPU time so the system seems to be responsive.

I confirm this. bitcoind is actually nice now.
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile
July 15, 2010, 11:23:04 PM
 #29

I don't see either happening, although it did get put into the "Startup" folder.  That is so Windows 95ish (just kidding..... Microsoft has so screwed this up that it isn't even funny).  I would recommend the registry settings for a number of reasons including the fact that most software puts the startup in that location, even though I personally find the startup folder to be more attractive and how most software on Windows should behave.
It could go either way.  The Startup folder has the advantage that the end user can see it and manually remove it with the regular UI (not regedit) if they already blew away the Bitcoin directory and its uninstaller.  Bitcoin will not relentlessly keep re-adding it if you delete it manually.

OpenOffice is another example of something that puts its link in the Startup folder.
lachesis
Full Member
***
Offline Offline

Activity: 210


View Profile
July 16, 2010, 12:03:22 AM
 #30

On the Linux client (64 bit), the "minimize on close" will still minimize to tray (causing X server hang after a short while by spawning multiple tray icons).
I updated the first post with a link to rc2 for linux with the fix for this.  Please check that this is fixed for you.  Thanks!

http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz
Satoshi, you didn't fix the bug; you just ripped out the minimize to tray code. Could you possibly make this optional? I wasn't experiencing the original bug, and I very much like the minimize to tray feature.

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1QGacAtYA7E8V3BAiM7sgvLg7PZHk5WnYc
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile
July 16, 2010, 12:44:32 AM
 #31

Run it with the undocumented switch -minimizetotray and the option is available in the options menu.

I don't know how to fix it.  It's something wrong deep inside wxWidgets or GTK or Gnome.
lachesis
Full Member
***
Offline Offline

Activity: 210


View Profile
July 16, 2010, 01:12:26 AM
 #32

Alright, thanks. That's all I need.

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1QGacAtYA7E8V3BAiM7sgvLg7PZHk5WnYc
BioMike
Legendary
*
Offline Offline

Activity: 1218


View Profile
July 16, 2010, 05:24:59 AM
 #33

Build 0.3.1 on an x86 gentoo linux system with my own makefile (builds a dynamic client instead of a static one), seems to run more smoothly than 0.3.0.

B.T.W. Why does the standard makefile builds a static version anyway?
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile
July 16, 2010, 03:09:59 PM
 #34

Because of all the dependencies that different systems don't have.  It's easier to just static link what we can.  It doesn't increase the size by very much.
knightmb
Sr. Member
****
Offline Offline

Activity: 308


Timekoin - Save Electricity, Don't Waste It!


View Profile WWW
July 16, 2010, 03:27:26 PM
 #35

Anyone notice, that for Windows Clients anyway, when you connect a bunch of other clients to it manually (through the -connect option) that if you go over 8, the windows client ends up cutting out the "outside world" connections and stick with the original 8 or more internal machines thinking that it's the entire network?

I never noticed this since I use a Linux client to funnel all my PCs to the outside world, but I tried it with a Windows client and noticed that at first, it had about 10 connections, then after adding another 50 clients internally that connect directly to it, the number would eventually drop down to just "internal clients" only.

When this happens, the block count doesn't increment anymore, basically the Windows client has separated itself from "the network" and all the other clients all think that they are the entire network now. If I do a "netstat -a -n" on the windows client, I can see it's only connected to the Internal clients and the IRC bootstrap channel and basically doesn't to connect to anyone else on the outside world. You know it's happening because the block count starts to fall behind of what is really going on outside of your local network (Internet for the rest of the world)

It's kind of a self-collapsing loop? Doesn't seem to affect Linux clients though, they will happily connect to and be connected to about as many as it can handle. I could see this is kind of a DoS on windows clients if someone was evil enough.

satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile
July 16, 2010, 05:26:17 PM
 #36

Good point.  If you're going to have more than 8 LAN nodes connect to one gateway node, then you'd better have the gateway node set up so it can receive incoming connections.  Otherwise, while the gateway node has 8 or more connections, it will not try to add any more outbound connections.  As the outside nodes you're connected to come and go, it doesn't make new outbound connections to replace them.  You'll be fine if you can accept incoming connections, then there will be plenty of others connecting to you.
knightmb
Sr. Member
****
Offline Offline

Activity: 308


Timekoin - Save Electricity, Don't Waste It!


View Profile WWW
July 16, 2010, 05:58:24 PM
 #37

Good point.  If you're going to have more than 8 LAN nodes connect to one gateway node, then you'd better have the gateway node set up so it can receive incoming connections.  Otherwise, while the gateway node has 8 or more connections, it will not try to add any more outbound connections.  As the outside nodes you're connected to come and go, it doesn't make new outbound connections to replace them.  You'll be fine if you can accept incoming connections, then there will be plenty of others connecting to you.
The Windows Client had it's own static IP with port 8333 open for it, I could see from the gateway device that it was connecting out to other peers and other peers were connecting back in. But after the 8, it's like it quit connecting out to peers and after a while the incoming peers stopped as well since it appeared to only be concerned with the peers on the LAN vs the WAN. The behavior of the Linux client is different though I've noticed, even if 50 people are connected to it, it will still seek outbound connections to other peers and inbound peers continue to trickle in as well.

While this will only be a problem for people like me that have hundreds of PCs at their disposal, the reverse is, one could setup PC(s) to connect to a single client 8 or more times and then after a while, the poor windows client would suck itself into it's own matrix world where it thinks it's on the network solving blocks, but it's really trapped back in time.

This is just a theoretical attack of course, I'm not going to lose any sleep over it, but I figured I would throw it out there for the future. The easiest way to negate this would be to put in some self-checking code for IPs. Basically, have to check that is has 8 connections or more that are NOT from the LAN/Same IP Address/etc when it's running as a dual node/client mode.

BioMike
Legendary
*
Offline Offline

Activity: 1218


View Profile
July 16, 2010, 07:46:39 PM
 #38

Because of all the dependencies that different systems don't have.  It's easier to just static link what we can.  It doesn't increase the size by very much.

I think size (static binary is 8x as big in my case) is not the problem, but security.

Boost, openssl and Berkeley DB are fairly common on unix systems (many things depend on them) and also Wxwidgets (the only argument is that bitcoin uses the current development branch and not the stable branch). Second, static linking doesn't mean you can always run it (in my case it tries to load libpng-1.2, which is not present on my system, libpng-1.4 is, and the static fails to load). Third, openssl hasn't been free of security issues, by statically compiling people keep using the insecure version even if their system provides an updated safe version.

satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile
July 16, 2010, 09:06:57 PM
 #39

I uploaded windows 0.3.1 rc1 and linux 0.3.1 rc2 to SourceForge and updated the links on the homepage.

You don't need to update to 0.3.1 unless you had one of the problems listed in the first post.  If you've got it working already, stay with 0.3.0.
knightmb
Sr. Member
****
Offline Offline

Activity: 308


Timekoin - Save Electricity, Don't Waste It!


View Profile WWW
July 17, 2010, 12:11:43 AM
 #40

On the Linux client (64 bit), the "minimize on close" will still minimize to tray (causing X server hang after a short while by spawning multiple tray icons).
I updated the first post with a link to rc2 for linux with the fix for this.  Please check that this is fixed for you.  Thanks!

http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz
Testing the new release candidate. This resolves the minimize on close accidentally doing a minimize to tray. No X server crashes either, nice! Now only if we could get that tray thing to work again  Wink

Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!