Dry Run 8: Need for Speed

[sumantso]

Lost all connections

EDIT: Getting 1/2 connections intermittently.

[bytemaster]

Okay this next two delegates will decide.   Auto firing can be implemented in the future.


Sent from my iPhone using Tapatalk

[Fox]

Can any delegate try to cheat and see what will happen.

My attempt at 'cheating' is to run the same delegate on two (2) nodes each with ~14 peer connections.  My block production slot came and went without any apparent issue. 

This somewhat surprises me, as I would expect both nodes to assume it is their time to create the block and independently publish a (potentially) different block to the network.  Further, I assume the resulting differing blocks have the potential to create a fork.

Will this issue be raised only at higher transaction volumes when the block contain differing transactions and therefor different resulting hash?

This seems a bad practice for a delegate, as one should produce only a single block.  How does the network react to this series of events and ultimately vote on this behavior?

[bytemaster]

General status update... Market Order Matching (minus shorts) is basically implemented in the blockchain of the dryrun9 branch.  This weekend I will be updating the wallet / CLI to provide the user feedback to understand how your orders were actually matched without looking at the log file.

We will likely Launch Dryrun 9 early next week with a full test of market order matching of user issued assets.     

[mitao]

Can any delegate try to cheat and see what will happen.


Sent from my iPhone using Tapatalk

[bytemaster]

I am asking and posing the question from from am implentation standpoint as we move away from the theoretical.   Coming from the mission critical background so going from conceptual to implementation, we test the what if scenerios(as many as we feel that cause a failure) and  putting a system/network through a battery of extensive stress tests would be prudent. All delegates/users would want to see how the network responds and confident in its operation.

what is happening right now is more like functional testing, which is great. I am wondering if there will be some testng of possbile failure scenerios and  observe the findings. Has anyone thought of creating or has started a test script on of possible failure scenerios?

...

[Fox]

I need to know what a suggested port would be to allow traffic in on though

I am currently using TCP 8801 on my client.  You may set it from the command line using the --p2p-port arg:

Code: [Select]

./bitshares_client --p2p-port 8801
Do be sure to poke a hole in your firewall for TCP port 8801

Thanks,

Code: [Select]

wallet_approve_delegate fox

[raslfrasl]

Ok I think I have my system all figured out.

I need to know what a suggested port would be to allow traffic in on though

My address is bitshare.matavesi.com

The 5 Public Keys are:
bs02-1 XTS5psceYCcvjUzX3csKp3uZr3gEMhGk3yHCnjoaGVhs1NRwLcA4D
bs02-2 XTS5zZEtZ82ymJq7W6wSHR2oLPaUXSPwArFA7pwGTaHQ5xPTWi5Xo
bs02-3 XTS6fbf7ettJrNvujCqwiwwrKtRPuFcTQULibof4mFJz6xnGsex4v
bs02-4 XTS6c9wKhfdDmmWepQ9373yAdZJYRpSEujbid5HtEHVCV43DcWsso
bs02-5 XTS75gNM8w9A5X4hvT8hB4GuYB8FGRgmiDWts8Yvt136ig6egkQRE

I'm in Austin, Texas, USA
Have a 100MB connection at a datacenter
Running Ubuntu 14.04 LTS Server on vmWare 5.x
Hardware is 2 3GHZ Xenon reserved and 2GB RAM reserved for the system

[jbutta2k13]

I am asking and posing the question from from am implentation standpoint as we move away from the theoretical.   Coming from the mission critical background so going from conceptual to implementation, we test the what if scenerios(as many as we feel that cause a failure) and  putting a system/network through a battery of extensive stress tests would be prudent. All delegates/users would want to see how the network responds and confident in its operation.

what is happening right now is more like functional testing, which is great. I am wondering if there will be some testng of possbile failure scenerios and  observe the findings. Has anyone thought of creating or has started a test script on of possible failure scenerios?

[toast]

The min connection count is for the delegate's own convenience. You can override it and set it to 0, easier than making 5 fake nodes. But why on earth would you do this? You'd just be putting yourself on a minority fork.

In practice delegates will probably have hundreds of connections. Right now we don't have that many because I do not think we have 100 people participating in these dry runs.

[jbutta2k13]

This may not be the right place for the topic but i wanted to discuss it anyway.  please feel free to move it where you believe it needs t go.

Questions and possible testing requirements of the network.

• Delegate are required to maintain a mimimum number of connections to make blocks.  What keeps a delegate from running multiple delegates maintaining the min connections?  If the current min connection is 5, and a delegate is running 5+ each with "hard added nodes", then these effectively can produce blocks on their own.  What happens in the event this happens
• What happens if a  multi-delegate maintain min connection but blocks IPs of other delegates.
• How do you monitor that delegates are not actively participating in blocking other delegates.
• It seems to me, that to be a delegate, we would want ones the have the most active connections and therefore providing the most network connectivity since this is the most important feature of blockchain creation. It seems to me that delegates should be maintaining at least 100 connections. I find it strange that we can't get 100 connections.  IS anyone else getting even close to that?

[li] I think it would be a good idea for there to be a reporting mechanism for delegates to show active connections with peers.  this would allow the BTX to visually network connectivity maps. Who know what useful information this would provide.


[/li][/list]

[sumantso]

Checked my client after over 12 hours and it has been running smoothly and producing blocks I guess its quite close to being the final product now.

Don't let suman drop out, eh? Its quite close to bottom.

[spartako]

I had a segfault after ~14 hour my client was running:

Code: [Select]

--- there are now 5 active connections to the p2p network
default (unlocked) >>>
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff647afd0 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb)

If I restart the client and then I give the quit command, at the exit I have an other segfault:

Code: [Select]

Program received signal SIGSEGV, Segmentation fault.
fc::detail::average_rate_meter::update_const(unsigned int) const () at /home/fabiux/ssd/bitshares_toolkit/libraries/fc/include/fc/time.hpp:59
59              bool   operator <=( const time_point& t )const                              { return elapsed._count <=t.elapsed._count; }
(gdb)


Code: [Select]

default (unlocked) >>> about
{
  "bitshares_toolkit_revision": "2c46468de8e587229d54efe47d55fdf599c1da6f",
  "bitshares_toolkit_revision_age": "20 hours ago",
  "fc_revision": "87196008d4dacf292523e0b2e89e3af16e125dde",
  "fc_revision_age": "39 hours ago",
  "compile_date": "compiled on Jul 10 2014 at 09:15:43"
}

System: Ubuntu 12.04

[alt]

don't know if it's a known issue.
my client failed to  sync blocks at block 9661.
from the logs, switch fork failed because of detected duplicate transaction

Actually, switch fork is called here not because of a real fork.
This happened when I just begin the program.
It begin to fetch block from very early.
then  it  reached to block 9661("76fdaa3232590335bace099a977c31a36327a4ef"), and have commit block 9661 to the chain.
then it get another two block: ["c91e6df277471ad7654273370452f783e78c9cb5","3c5a66fe4b06a2b7798d8c167bddf472d3dc847a",] ,
when merge block "3c5a66fe4b06a2b7798d8c167bddf472d3dc847a", it failed with duplicate transaction.

I'm confused.

Sorry for my poor English.
I mean it's not about fork. no fork at block 9661.
In fact every new block  it received, it will call switch_to_fork before apply_transactions, I don't know if it's correct?

Code: [Select]

20140711T010009.201990       th_a      store_and_index ]            we already know about its previous: 6a853190ba4dba7807d2d6d5ba161cd1d1cbc64f                       
chain_database.cpp:423
20140711T010009.202035       th_a      store_and_index ]           current_fork: {"next_blocks":["5d3f66068d585528d480b70a18c29eec25c7e8f6"],"is_linked":true,"is_valid"
:null,"invalid_reason":null,"is_included":false,"is_known":false}                       chain_database.cpp:447
20140711T010009.202071       th_a      store_and_index ]           prev_fork: {"next_blocks":["927d90285e7b2fb0c1e688e365ac99068c7c3444"],"is_linked":true,"is_valid":nu
ll,"invalid_reason":null,"is_included":false,"is_known":true}                   chain_database.cpp:448
20140711T010009.202129       th_a       switch_to_fork ] switch from fork 6b8de8e41c40b37f17c459a591b25cccfdedfc99 to 927d90285e7b2fb0c1e688e365ac99068c7c3444         
        chain_database.cpp:497
20140711T010009.202153       th_a     get_fork_history ]                        chain_database.cpp:842
20140711T010009.202209       th_a     get_fork_history ] return: ["927d90285e7b2fb0c1e688e365ac99068c7c3444","6a853190ba4dba7807d2d6d5ba161cd1d1cbc64f","6b8de8e41c40b37
f17c459a591b25cccfdedfc99"]                     chain_database.cpp:863
20140711T010009.202241       th_a       switch_to_fork ]     extend 6a853190ba4dba7807d2d6d5ba161cd1d1cbc64f                    chain_database.cpp:507
20140711T010009.203609       th_a   apply_transactions ] Applying transactions from block: 9538                 chain_database.cpp:517
20140711T010009.554571       th_a       switch_to_fork ]     extend 927d90285e7b2fb0c1e688e365ac99068c7c3444                    chain_database.cpp:507
20140711T010009.556027       th_a   apply_transactions ] Applying transactions from block: 9539                 chain_database.cpp:517
20140711T010010.228383       th_a         on_new_block ] After push_block, current head block is 9539                   client.cpp:848


Code: [Select]

20140711T010013.258569       th_a      store_and_index ]            we already know about its previous: a7f0ead5ce478cfbe374c222b40ff8a9a2420f13                       
chain_database.cpp:423
20140711T010013.258615       th_a      store_and_index ]           current_fork: {"next_blocks":["354082413dcb4416c33d2f9472491b42d01324db"],"is_linked":true,"is_valid"
:null,"invalid_reason":null,"is_included":false,"is_known":false}                       chain_database.cpp:447
20140711T010013.258651       th_a      store_and_index ]           prev_fork: {"next_blocks":["73db1927767e8acf932d1529f60aaa9b12dee709"],"is_linked":true,"is_valid":tr
ue,"invalid_reason":null,"is_included":true,"is_known":false}                   chain_database.cpp:448
20140711T010013.259998       th_a   apply_transactions ] Applying transactions from block: 9542                 chain_database.cpp:517
20140711T010015.380021       th_a         on_new_block ] After push_block, current head block is 9542                   client.cpp:848


[bytemaster]

don't know if it's a known issue.
my client failed to  sync blocks at block 9661.
from the logs, switch fork failed because of detected duplicate transaction

Actually, switch fork is called here not because of a real fork.
This happened when I just begin the program.
It begin to fetch block from very early.
then  it  reached to block 9661("76fdaa3232590335bace099a977c31a36327a4ef"), and have commit block 9661 to the chain.
then it get another two block: ["c91e6df277471ad7654273370452f783e78c9cb5","3c5a66fe4b06a2b7798d8c167bddf472d3dc847a",] ,
when merge block "3c5a66fe4b06a2b7798d8c167bddf472d3dc847a", it failed with duplicate transaction.

I'm confused.