Test Net for Advanced Users

[alt]

I set up 51 VPSs from three different regions around the world. If I did correctly, they will spam the network at the same time at 2015/9/28 0:02 AM PST (7:02 UTC)

unbeliveable, how could you manage so many VPS?

[xeroc]

I set up 51 VPSs from three different regions around the world. If I did correctly, they will spam the network at the same time at 2015/9/28 0:02 AM PST (7:02 UTC)

wow ..

[clayop]

I set up 51 VPSs from three different regions around the world. If I did correctly, they will spam the network at the same time at 2015/9/28 0:02 AM PST (7:02 UTC)

[clayop]

Hello all,

I've been lurking here since mid-2014 and I've decided to become more active.

Please vote for my new witness node: mindphlux-witness on testnet.

I've already talked to bytemaster, I will learn ReactJS and help out the frontend development team. Web development is my main job, very experienced in plain JS, so it should be an easy task.

Thank you

Best Regards
mindphlux

 

[cass]

Hello all,

I've been lurking here since mid-2014 and I've decided to become more active.

Please vote for my new witness node: mindphlux-witness on testnet.

I've already talked to bytemaster, I will learn ReactJS and help out the frontend development team. Web development is my main job, very experienced in plain JS, so it should be an easy task.

Thank you

Best Regards
mindphlux

Awesome, welcome!

Yep!!! Welcome, great to have you aboard!

[svk]

Hello all,

I've been lurking here since mid-2014 and I've decided to become more active.

Please vote for my new witness node: mindphlux-witness on testnet.

I've already talked to bytemaster, I will learn ReactJS and help out the frontend development team. Web development is my main job, very experienced in plain JS, so it should be an easy task.

Thank you

Best Regards
mindphlux

Awesome, welcome!

[mindphlux]

Hello all,

I've been lurking here since mid-2014 and I've decided to become more active.

Please vote for my new witness node: mindphlux-witness on testnet.

I've already talked to bytemaster, I will learn ReactJS and help out the frontend development team. Web development is my main job, very experienced in plain JS, so it should be an easy task.

Thank you

Best Regards
mindphlux

[jtme]

Once boost is built from source and "b2 install" is run on the target VPS can the boost/boost_1_57_0 folder hierarchy be removed?

Does the witness_node and cli_wallet binaries require anything from the boost tree or only from the shared libraries (/usr/local/lib/libboost*.so.1.57.0)? What about the gui out of curiosity?

ldd witness_node              shows

Code: [Select]

linux-vdso.so.1 =>  (0x00007ffe627f7000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f00b79ad000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f00b77a8000)
librt.so.1 => /lib64/librt.so.1 (0x00007f00b75a0000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f00b7291000)
libm.so.6 => /lib64/libm.so.6 (0x00007f00b6f88000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f00b6d71000)
libc.so.6 => /lib64/libc.so.6 (0x00007f00b69b4000)
/lib64/ld-linux-x86-64.so.2 (0x000055d7ecbf4000)

that witness_node is statically linked. Shared boost libs are not needed on the production host.
I would asume for the build it would be only needed to have the cpp headers and static *.a
boost libs from install dir to bulid a witness.

Thanks for the reply jtme, I'm a bit rusty with my unix dev skills. Is that list definitive in terms of the boost libs required by graphene, and what tool did you use to get that list?

From what I can see boost is so big almost nobody uses it all so it gets chopped up and pulled apart to make use of various elements, if they want a static build. Static builds are great for removing external dependencies, which really makes sense for building blockchain apps & tools, but it can make for some mighty big executable images.

One last but important question, this may only be known by cryptonomex devs: can boost 1.57.0 libs be installed on a host running the 0.9.x code without any collisions? If 0.9.x was also built with static linking I presume the answer to that is yes, they can coexist without an issue. I'd like a solid confirmation tho before I run my graphene VPS setup script on my production delegate VPS.

ldd is the unix cmd that will show which shared libs the binarry needs to be linked with at runtime.
As for your last q. I would think there should be no problem. Your 1.57.0 boost shared libs should
have different versions if their api or behaviour changed, so your 0.9 client wont link with them.
Plus you can install boost into some other dir like /usr/grapheneboost , then 0.9 clients
cannot link them for sure unles you will point them to the dir using LD_LIBRARY_PATH
env. variable

[Thom]

Once boost is built from source and "b2 install" is run on the target VPS can the boost/boost_1_57_0 folder hierarchy be removed?

Does the witness_node and cli_wallet binaries require anything from the boost tree or only from the shared libraries (/usr/local/lib/libboost*.so.1.57.0)? What about the gui out of curiosity?

ldd witness_node              shows

Code: [Select]

linux-vdso.so.1 =>  (0x00007ffe627f7000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f00b79ad000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f00b77a8000)
librt.so.1 => /lib64/librt.so.1 (0x00007f00b75a0000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f00b7291000)
libm.so.6 => /lib64/libm.so.6 (0x00007f00b6f88000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f00b6d71000)
libc.so.6 => /lib64/libc.so.6 (0x00007f00b69b4000)
/lib64/ld-linux-x86-64.so.2 (0x000055d7ecbf4000)

that witness_node is statically linked. Shared boost libs are not needed on the production host.
I would asume for the build it would be only needed to have the cpp headers and static *.a
boost libs from install dir to bulid a witness.

Thanks for the reply jtme, I'm a bit rusty with my unix dev skills. Is that list definitive in terms of the boost libs required by graphene, and what tool did you use to get that list?

From what I can see boost is so big almost nobody uses it all so it gets chopped up and pulled apart to make use of various elements, if they want a static build. Static builds are great for removing external dependencies, which really makes sense for building blockchain apps & tools, but it can make for some mighty big executable images.

One last but important question, this may only be known by cryptonomex devs: can boost 1.57.0 libs be installed on a host running the 0.9.x code without any collisions? If 0.9.x was also built with static linking I presume the answer to that is yes, they can coexist without an issue. I'd like a solid confirmation tho before I run my graphene VPS setup script on my production delegate VPS.

[jtme]

Once boost is built from source and "b2 install" is run on the target VPS can the boost/boost_1_57_0 folder hierarchy be removed?

Does the witness_node and cli_wallet binaries require anything from the boost tree or only from the shared libraries (/usr/local/lib/libboost*.so.1.57.0)? What about the gui out of curiosity?

ldd witness_node              shows

Code: [Select]

linux-vdso.so.1 =>  (0x00007ffe627f7000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f00b79ad000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f00b77a8000)
librt.so.1 => /lib64/librt.so.1 (0x00007f00b75a0000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f00b7291000)
libm.so.6 => /lib64/libm.so.6 (0x00007f00b6f88000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f00b6d71000)
libc.so.6 => /lib64/libc.so.6 (0x00007f00b69b4000)
/lib64/ld-linux-x86-64.so.2 (0x000055d7ecbf4000)

that witness_node is statically linked. Shared boost libs are not needed on the production host.
I would asume for the build it would be only needed to have the cpp headers and static *.a
boost libs from install dir to bulid a witness. 

[clayop]

Can I have some more CORE for spamming? Thanks in advance.

Id: clayop

[Thom]

I'm writing a VPS install script for graphene nodes and I'm not sure of the best way to handle the boost libs. I need some input about boost from a dev who has used it. It is one humongus library! I looked at the boost website but couldn't find anything about deployment there.

I don't plan to build any of the binaries on the VPS. I compile boost on a dev system from source, then afterwards compress the entire boost source hierarchy into a tarball (it's big, yeah I know) and run the "b2 install" after decompressing on it the VPS which installs the shared libs. From what I can tell, that approach still does some compiling and / or linking for configuration at install time, but it doesn't take nearly as long as starting from scratch. Still it's minutes not seconds.

The script installs all of the same packages required to compile graphene from scratch, even if they're all not needed (tho I think most if not all are).

Once boost is built from source and "b2 install" is run on the target VPS can the boost/boost_1_57_0 folder hierarchy be removed?

Does the witness_node and cli_wallet binaries require anything from the boost tree or only from the shared libraries (/usr/local/lib/libboost*.so.1.57.0)? What about the gui out of curiosity?

Of course all this wouldn't be necessary if a binary package for the version graphene requires were available via apt-get, or I knew how to produce a .deb file from the boost build tree.

The idea of this effort is to start with a brand new VPS, copy a script and a big tarball to it and when it is done executing it will be a configured, secured node for a witness, seed or backbone node. It installs monitoring, packages, users, tools, optimizes inode caching, swaping etc. So far the script is 125 lines long and it's 95% complete.

Today I hope to add built graphene binaries to the tarball so that will be the iron test. I just hope I can gather all the info I need to run a graphene witness in the testnet from this thread. It's been a few weeks and I see many others have joined in, but don't see much recent info on the process now or if it has changed.

[clayop]

Only an issue during spamming


Sent from my iPhone using Tapatalk

IMO, it can be a potential problem in the future. What if a very successful exchange based on BitShares process 100 txs per second on average? (now with 36 core / 120G memory VPS can input about 40 txs per second on average). What happens about one third of transactions of the exchange are not broadcast and are expired?

[clayop]

For spamming, I found that issuing asset is more efficient than transfer.

[roadscape]

Can I get some more votes for roadscape (1.6.5249)? Dropped out again.