I was bothered by losing half the performance, so I experimented to find and fix this.
I had to throw out last weeks code dealing with scripts and come up with a new way to stream the data.
The performance is still a bit choppy, but I am seeing bursts above 100MB/sec, which is double what it was before I streamlined things and close to what it used to be without the scripts data. Now I put all the vin scripts in the vins directory and the vout scripts in the vouts directory. I also went to a brute force one file per block within a bundle directory in the tmp, probably just for debug but it is quite handy to have the first pass data in separate files.
For now, it would help if people could run bandwidth tests using bmon. The big question is what percentage of available bandwidth does iguana use. Right now, it goes as fast as it can, we can throttle it down later if it is an issue.
Theoretically, the data is perfect and it can be used for wallet operations, but of course I will need to fully validate the bundle files by brute force comparing it to a known good reference. So for now, just an indication of what percentage of bandwidth iguana uses will be helpful.
For unix:
git clone https://github.com/jl777/SuperNET
cd SuperNET
./m_onetime m_unix
cd iguana
./m_unix
Now iguana is built in the SuperNET/agents directory. but the directory structure is set up to expect you run iguana from SuperNET/iguana directory.
../agents/iguana "{\"agent\":\"iguana\",\"method\":\"addcoin\",\"newcoin\":\"BTC\",\"active\":1,\"services\":129,\"maxpeers\":128,\"numhelpers\":4,\"poll\":1}"
It will print massive amounts of debug output to the console. you can nohup it if that bothers you.
the status printout is:
1st.7 N[202] Q.129 h.378293 r.209401 c.0:160000:0 s.302128 d.81 E.80:128139 M.56000 L.402270 est.8 1.97GB 0:16:03 158.573 peers.35/256 Q.(0 0)
1st.7 means bundle 7 is the first one that is not complete
s.302128 means 302128 blocks saved
d.81 done downloading raw files for 81 bundles
E.80 means the bundle file is completed
M.56000 is how far the mainchain has been validated (via headers)
L.402270 is the longest chain seen by peers
0:16:03 16 minutes 3 seconds
I tend to make many test versions and during this period things are likely broken, so if you see many recent version in git, safer to go back to the one that didnt change for a while
James
P.S. http://docs.supernet.org has API bindings for sending requests over localhost. After the first build, just do another ./m_unix to build the latest version
I had to throw out last weeks code dealing with scripts and come up with a new way to stream the data.
The performance is still a bit choppy, but I am seeing bursts above 100MB/sec, which is double what it was before I streamlined things and close to what it used to be without the scripts data. Now I put all the vin scripts in the vins directory and the vout scripts in the vouts directory. I also went to a brute force one file per block within a bundle directory in the tmp, probably just for debug but it is quite handy to have the first pass data in separate files.
For now, it would help if people could run bandwidth tests using bmon. The big question is what percentage of available bandwidth does iguana use. Right now, it goes as fast as it can, we can throttle it down later if it is an issue.
Theoretically, the data is perfect and it can be used for wallet operations, but of course I will need to fully validate the bundle files by brute force comparing it to a known good reference. So for now, just an indication of what percentage of bandwidth iguana uses will be helpful.
For unix:
git clone https://github.com/jl777/SuperNET
cd SuperNET
./m_onetime m_unix
cd iguana
./m_unix
Now iguana is built in the SuperNET/agents directory. but the directory structure is set up to expect you run iguana from SuperNET/iguana directory.
../agents/iguana "{\"agent\":\"iguana\",\"method\":\"addcoin\",\"newcoin\":\"BTC\",\"active\":1,\"services\":129,\"maxpeers\":128,\"numhelpers\":4,\"poll\":1}"
It will print massive amounts of debug output to the console. you can nohup it if that bothers you.
the status printout is:
1st.7 N[202] Q.129 h.378293 r.209401 c.0:160000:0 s.302128 d.81 E.80:128139 M.56000 L.402270 est.8 1.97GB 0:16:03 158.573 peers.35/256 Q.(0 0)
1st.7 means bundle 7 is the first one that is not complete
s.302128 means 302128 blocks saved
d.81 done downloading raw files for 81 bundles
E.80 means the bundle file is completed
M.56000 is how far the mainchain has been validated (via headers)
L.402270 is the longest chain seen by peers
0:16:03 16 minutes 3 seconds
I tend to make many test versions and during this period things are likely broken, so if you see many recent version in git, safer to go back to the one that didnt change for a while
James
P.S. http://docs.supernet.org has API bindings for sending requests over localhost. After the first build, just do another ./m_unix to build the latest version
Last edited: