Dry Run 5: The Final Countdown

[Nimrod]

new client

>> blockchain_list_forks

[
  2299,
  2577,
  2591,
  2634,
  2676,
  2681,
  2690
]

[cass]

can i get some funds pls XTS5Ys6UMYxMYyQoNTpihwrVtXTyjWD1JLBkLYmx5AdeFHYtwKdhC (cassyo)

[toast]

bm and toast, do you think we need to schedule a full load testing across continents?

Doing that already, have delegates on several continents and all are bugs now occur only when we stress-test with high transaction volume (several times bitcoin max tx/second)

[toast]

@bytemaster ;@toast
5轮测试后，看起来之前一直没有真正找到分岔的原因，真正定位到问题上。建议：
1.在测试版中，可以所有的代理接点连接到一个固定的接点，当代理接点生成一个块的时候，将生成的需要的LOG信息按顺序发送到这个固定的接点，这样在这个固定的接点上就可以很清楚了解什么时间，某个代表，导致了分岔，有一个整体的了解，配合代理接点更详细的LOG信息，真正定位问题点。
2.从已经开发的POS币上借鉴阻止分岔的好的设计方法。
3.如果在实际运行中发生了分岔，如何处理。

Each case of fork has been different. We have fixed all previous ones and discover new ones when we do more serious stress testing. Existing POS systems are too different for us to learn from them. Suggestion to have centralized server doesn't help because central server is just like a delegate - if server works then delegate works, if delegate doesn't then server wouldn't.

[sfinder]

bm and toast, do you think we need to schedule a full load testing across continents?

[cdryan]

@bytemaster ;@toast
5轮测试后，看起来之前一直没有真正找到分岔的原因，真正定位到问题上。建议：
1.在测试版中，可以所有的代理接点连接到一个固定的接点，当代理接点生成一个块的时候，将生成的需要的LOG信息按顺序发送到这个固定的接点，这样在这个固定的接点上就可以很清楚了解什么时间，某个代表，导致了分岔，有一个整体的了解，配合代理接点更详细的LOG信息，真正定位问题点。
2.从已经开发的POS币上借鉴阻止分岔的好的设计方法。
3.如果在实际运行中发生了分岔，如何处理。

[toast]

We seem to be back to smooth sailing... alt, care to try your flood test again?

I have test again.
805 transactions is done very soon, these are include in block 2614,2615.
the others 195 is  pending a while, finally include in block 2623,2624
fork happened at block 2614  and switch fork works.
I think bts101 is test at the same time, other 600 transactions are include in block 2614,2615

another issue is list_erros hung a long time about 5 minutes, because never clear.

anyway  it works very well now 

We're doing some spam of our own and it seems to still fragment the network... think it's a mix of

* long block processing time
* long block propogation (block not getting priority over trx)
* someone still didn't update after fork resolution bugfix

[alt]

We seem to be back to smooth sailing... alt, care to try your flood test again?

I have test again.
805 transactions is done very soon, these are include in block 2614,2615.
the others 195 is  pending a while, finally include in block 2623,2624
fork happened at block 2614  and switch fork works.
I think bts101 is test at the same time, other 600 transactions are include in block 2614,2615

another issue is list_erros hung a long time about 5 minutes, because never clear.

anyway  it works very well now 

[vikram]

wallet_account_register <account_name> <pay_from_account> [public_data] [delegate_production_fee]

Code: [Select]

  delegate_production_fee (uint32_t, optional, defaults to 255): A value between 0 and 100% delegates, 255 for non delegates

I am confused. What is delegate production fee?

It defines the percent of transaction fees that your delegate will keep as a fee for producing the block, the rest are paid as dividends to the shareholders.   A value between 0 and 100.

Should be renamed to "delegate pay rate"

Done: https://github.com/BitShares/bitshares_toolkit/commit/613235eab279743b819af634249f11154b8352b7

[vikram]

Is there a way to dump list_errors to a file?

Adding this feature now.

Done: https://github.com/BitShares/bitshares_toolkit/commit/b01e3293f1d740d734b115e02ccca45ca98d9f09

[bytemaster]

We seem to be back to smooth sailing... alt, care to try your flood test again?

[bytemaster]

I just updated the Mac client to 0.0.5 (link in OP)

link doesnt work

Fixed.

[clout]

I just updated the Mac client to 0.0.5 (link in OP)

link doesnt work

[bytemaster]

Is there a way to dump list_errors to a file?

Adding this feature now.

[liondani]

I just updated the Mac client to 0.0.5 (link in OP)

What about the windows client?