The Linux build is ready for testing on the network. It seems solid. I
sent the executable as an attachment in the previous e-mail, but if the
mail server didn't let it through (it's 12MB), you can download it here:
http://rapidshare.com/files/303914158/linux-0.1.6-test1.tar.bz2.html
Linux build ready for testing
Private email with Martti Malmi (sirius-m) · 8 messages · from 8 November 2009 · with Satoshi Nakamoto, mmalmi@cc.hut.fi
Read in Satoshi Mail Archive source
That's great! A major waypoint reached. Seems to work fine here.
The Linux build is ready for testing on the network. It seems solid. I sent the executable as an attachment in the previous e-mail, but if the mail server didn't let it through (it's 12MB), you can download it here: http://rapidshare.com/files/303914158/linux-0.1.6-test1.tar.bz2.html
In the debug.log, it requests the block list, receives the block list,
then begins uploading the list of blocks requested. It doesn't receive
the blocks, but it didn't run long enough for me to be sure it would
have had time yet. Everything else looks normal.
How long did you run it? It could take a few minutes to start
downloading the blocks. Especially if you're on a cable modem, the
uplink can be much lower bandwidth so it would take some time to upload
the block request list.
If you run it again and it still doesn't download blocks, keep it
running for several hours at least and then send me the debug.log. That
should give it time for my node to connect to you and I could see what
it says on my side and correlate it with your debug.log.
You're right about the minimize on close option, there's no reason that
can't be separate. Martti originally had it separate and I made it a
sub-option, my bad. I'll change it back.
Liberty Standard wrote:That is what I meant. The blocks displayed in the status bar did not increase at all while i ran the program. I have attached my debug.log. A good way for you to test the tray icon in Gnome is to remove the notification area and then add it back. If the icon is still displayed after adding the notification back, then it's working correctly. I generally set application preferences to not minimize to the tray, but to close to the tray. And I keep the application minimized. That way I don't accidentally close the program and still have the convenience of being able to open the application from the tray. (I don't display open windows in the 'task bar' but I have an icon that if clicked displays open windows as sub-menu items.) Then if the tray icon disappears, I go into the settings disable and re-enable the tray icon setting to get it to reappear. That's currently not possible with the bitcoin preferences because the close to tray check mark can not be enabled without the minimize to tray check box being enabled. On Sun, Nov 8, 2009 at 9:08 AM, Satoshi Nakamoto <satoshin@gmx.com <mailto:satoshin@gmx.com>> wrote: Liberty Standard wrote: I downloaded it and it runs. It and it is using plenty of CPU, so I think it's working properly. It has not downloaded previously generated blocks. Is that a bug or a new feature? If you mean the blocks count in the status bar isn't working its way up to around 26600, then that's a bug, you should send me your debug.log. (which is at ~/.bitcoin/debug.log) The system tray in Gnome is not very reliable. Sometimes an icon will disappear leaving no way to get back to the program. I have verified that this can happen with bitcoin. It would be nice if starting bitcoin while it's already running would just bring up the GUI of the already running bitcoin process. We haven't figured out how to find and bring up the existing running program yet on Linux like it does on Windows. Given what you say, I should at least turn off the minimize to tray option initially by default.
Liberty Standard wrote:Ok, blocks have now started to increase. It definitely takes longer for them to start increasing than with the Windows version. Also, I think they might be increasing at a slower rate than in with the Windows version. Is there perhaps debugging enabled in the Linux build that you sent me? Block are increasing at about 15 blocks per second (eyeball estimate while looking at a clock). I didn't time how fast they increased in the Windows version, but it seems like it was much faster.
About how long did it take to start? It could be the node that you
happened to request from is slow. The slow start is consistent with the
slow download speed.
I'd like to look at your current debug.log file and try to understand
what's going. It might just be a really slow connection on the other
side, or maybe something's wrong and failed and retried. Taking too
long could confuse other users.
Martti, how long did it take to start downloading blocks when you ran
it, and how fast did it download?
When I launch bitcoin and the bitcoin port is not available, I get the following messages to the command line. I don't get those messages when the bitcoin port is available. Would it be possible for bitcoin to pick another port if the default port is taken? The same think sometimes happens to me with my BitTorrent client. When I restart it, my previously open port is closed. All I have to do is change the port and it starts working again. /usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64 Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so /usr/lib/gio/modules/libgioremote-volume-monitor.so: wrong ELF class: ELFCLASS64 Failed to load module: /usr/lib/gio/modules/libgioremote-volume-monitor.so /usr/lib/gio/modules/libgiogconf.so: wrong ELF class: ELFCLASS64 Failed to load module: /usr/lib/gio/modules/libgiogconf.so
It already uses SO_REUSEADDR so it can bind to the port if it's in
TIME_WAIT state after being closed. The only time it should fail to
bind is when the program really is already running. It's important that
two copies of Bitcoin not run on the same machine at once because they
would be modifying the database at the same time. There is never any
need to run two on one machine as coin generation will now use multiple
processors automatically.
I'm not sure what those lib errors are, I'll do some searching.
Thanks for that, I see what happened. Because the first one was slow,
it ended up requesting the blocks from everybody else, which only bogged
everything down. I can fix this, I just need to think a while about the
right way.
There's no risk in shutting down while there are unconfirmed. When you
make a transaction or new block, it immediately broadcasts it to the
network. After that, the increasing #/confirmed number is just
monitoring the outcome. There's nothing your node does during that time
to promote the acceptance.
Now that I think about it, when you close Bitcoin, it closes the main
window immediately but in the background continues running to finish an
orderly flush and shutdown of the database. Before I implemented that,
it was annoying having a dead hung unresponsive window hanging around.
Until it finishes the orderly shutdown in the background, the port would
be locked, and this is an important protection to make sure another copy
can't touch the database until it's done. I haven't seen the shutdown
take more than a few seconds.
In Wine, there's no way for the Windows version to do SO_REUSEADDR, so
that would add 60 seconds (on my system) of TIME_WAIT after the port is
closed.
If you need to transfer between two copies, you could send it to the
other's bitcoin address. The receiving copy doesn't have to be online
at the time.
The command line to use a different data directory is
bitcoin -datadir=<directory>
For example, on Linux, the default directory is (don't use ~)
bitcoin -datadir=/home/yourusername/.bitcoin
You shouldn't normally have any need to use this switch. It still won't
let you run two instances at once.
Liberty Standard wrote:On Mon, Nov 9, 2009 at 3:23 AM, Satoshi Nakamoto <satoshin@gmx.com <mailto:satoshin@gmx.com>> wrote: Liberty Standard wrote: Ok, blocks have now started to increase. It definitely takes longer for them to start increasing than with the Windows version. Also, I think they might be increasing at a slower rate than in with the Windows version. Is there perhaps debugging enabled in the Linux build that you sent me? Block are increasing at about 15 blocks per second (eyeball estimate while looking at a clock). I didn't time how fast they increased in the Windows version, but it seems like it was much faster. About how long did it take to start? It could be the node that you happened to request from is slow. The slow start is consistent with the slow download speed. It took about a half hour for it to start incrementing quickly. Interestingly, the CPU usage increased before it started to increment steadily and then lowered when it started to increment steadily. Although this time the block incremented to 2 within the first few minutes. I have not yet generated any bitcoins. I'll wait for as long as I have patience to generate a bitcoin, but if none are created by the time I lose patience, I'm going to move back to the wine version. I'd like to look at your current debug.log file and try to understand what's going. It might just be a really slow connection on the other side, or maybe something's wrong and failed and retried. Taking too long could confuse other users. I've included my current debug.log. Martti, how long did it take to start downloading blocks when you ran it, and how fast did it download? When I launch bitcoin and the bitcoin port is not available, I get the following messages to the command line. I don't get those messages when the bitcoin port is available. Would it be possible for bitcoin to pick another port if the default port is taken? The same think sometimes happens to me with my BitTorrent client. When I restart it, my previously open port is closed. All I have to do is change the port and it starts working again. /usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64 Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so /usr/lib/gio/modules/libgioremote-volume-monitor.so: wrong ELF class: ELFCLASS64 Failed to load module: /usr/lib/gio/modules/libgioremote-volume-monitor.so /usr/lib/gio/modules/libgiogconf.so: wrong ELF class: ELFCLASS64 Failed to load module: /usr/lib/gio/modules/libgiogconf.so It already uses SO_REUSEADDR so it can bind to the port if it's in TIME_WAIT state after being closed. The only time it should fail to bind is when the program really is already running. It's important that two copies of Bitcoin not run on the same machine at once because they would be modifying the database at the same time. There is never any need to run two on one machine as coin generation will now use multiple processors automatically. The reason I run two instances at the same time is to transfer bitcoins from one bitcoin instance to another. They of course would need to be accessing different data directories. Perhaps that could be specified as a command line argument. I currently have to move my bitcoin data folder to a virtual machine to do this. Shutting down bitcoin and restarting it with a different data directory is a poor solution because shutting down bitcoin while there are unconfirmed bitcoins risks losing those bitcoins. Bitcoin was definitely not running when i get the busy port error. The process closes quickly and reliably from my experience, but it takes anywhere from 30 seconds to 3 minutes (estimation from memory) for the port to become available again. It occurred while switching from bitcoin 0.1.5 in Wine to the Linux build and again while switching from the Linux build to bitcoin 0.1.5 in Wine. Another thing that I noticed is that the about dialog text does not fit correctly and it cannot be resized. I'm not sure what those lib errors are, I'll do some searching.
Martti, how long did it take to start downloading blocks when you ran it, and how fast did it download?
Started very quickly when I got connected and downloaded quicker than
my Windows PC, which has a slower CPU.
I'll have to focus on a school project (coincidentally C++ coding) for
about a month now, so I don't have that much time for active
developing until December. Let's keep contact anyway.
Liberty Standard wrote: > Ok, blocks have now started to increase. It definitely takes longer > for them to start increasing than with the Windows version. Also, > I think they might be increasing at a slower rate than in with the > Windows version. Is there perhaps debugging enabled in the Linux > build that you sent me? Block are increasing at about 15 blocks per > second (eyeball estimate while looking at a clock). I didn't time > how fast they increased in the Windows version, but it seems like > it was much faster. About how long did it take to start? It could be the node that you happened to request from is slow. The slow start is consistent with the slow download speed. I'd like to look at your current debug.log file and try to understand what's going. It might just be a really slow connection on the other side, or maybe something's wrong and failed and retried. Taking too long could confuse other users. Martti, how long did it take to start downloading blocks when you ran it, and how fast did it download? > When I launch bitcoin and the bitcoin port is not available, I get > the following messages to the command line. I don't get those > messages when the bitcoin port is available. Would it be possible > for bitcoin to pick another port if the default port is taken? The > same think sometimes happens to me with my BitTorrent client. When I > restart it, my previously open port is closed. All I have to do is > change the port and it starts working again. > > /usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64 > Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so > /usr/lib/gio/modules/libgioremote-volume-monitor.so: wrong ELF > class: ELFCLASS64 > Failed to load module: > /usr/lib/gio/modules/libgioremote-volume-monitor.so > /usr/lib/gio/modules/libgiogconf.so: wrong ELF class: ELFCLASS64 > Failed to load module: /usr/lib/gio/modules/libgiogconf.so It already uses SO_REUSEADDR so it can bind to the port if it's in TIME_WAIT state after being closed. The only time it should fail to bind is when the program really is already running. It's important that two copies of Bitcoin not run on the same machine at once because they would be modifying the database at the same time. There is never any need to run two on one machine as coin generation will now use multiple processors automatically. I'm not sure what those lib errors are, I'll do some searching.
You really don't want to keep running in Wine, you're getting database
errors (db.log). You probably developed these rituals of transferring
to a fresh install to cope with database corruption. If there is a way
to lose unconfirmed blocks, it would have to be the database errors.
Any problems you find in the Linux build can be fixed. The Wine
incompatibility deep inside Berkeley DB is unfixable.
I think GCC 4.3.3 on the Linux build optimized the SHA-256 code better
than the old GCC 3.4.5 on Windows. When I was looking for the best
SHA-256 code, there was a lot of hand tuned highly optimized SHA1 code
available, but not so much for SHA-256 yet. I should see if I can
upgrade MinGW to 4.3.x to get them on a level playing field.
Liberty Standard wrote:Everyone that contributed to making this Linux build really did a great job! Thanks for the hard work. It has started maturing some bitcoins, so I'm going to continue to run the Linux client for the time being until I decide whether it's at least as good or better at generating coins than the Windows version running in Wine. On Mon, Nov 9, 2009 at 8:59 AM, Liberty Standard <newlibertystandard@gmail.com <mailto:newlibertystandard@gmail.com>> wrote: Another instance when I would like to run multiple instances is when I upgrade bitcoin. I will uncheck the generate coin check box in the outdated bitcoin, launch and start generating coins in the new bitcoin using a separate data directory, then when the old application's coins have matured I will send them to the new application and then close the old application. I prefer do do clean installs rather than upgrading while maintaining old data. On Mon, Nov 9, 2009 at 7:42 AM, Satoshi Nakamoto <satoshin@gmx.com <mailto:satoshin@gmx.com>> wrote: Thanks for that, I see what happened. Because the first one was slow, it ended up requesting the blocks from everybody else, which only bogged everything down. I can fix this, I just need to think a while about the right way. There's no risk in shutting down while there are unconfirmed. When you make a transaction or new block, it immediately broadcasts it to the network. After that, the increasing #/confirmed number is just monitoring the outcome. There's nothing your node does during that time to promote the acceptance.
You got a lot done with the Linux build, autostart, minimize to tray,
setup and everything, it's really appreciated. Good luck on your C++
project.
mmalmi@cc.hut.fi wrote:I'll have to focus on a school project (coincidentally C++ coding) for about a month now, so I don't have that much time for active developing until December. Let's keep contact anyway.