i/o timeouts

[0xmichalis]

In some simulations, especially as the number of actors used is increasing, i/o timeouts may happen to the btcwallet rpc clients.

[tuxcanfly]

Try getting a goroutine dump of btcwallet using the --profile arg. It would be helpful in debugging the issue.

[jrick]

Are all your deps up to date?

[0xmichalis]

I run an update on both btcd and btcwallet a couple of days ago.

Let me run another one now and post another stacktrace while having this reproduced

UPDATE Removed all stacktraces to favor readability of the issue

[tuxcanfly]

I can repro it by varying actorsAmount. Will try to debug and isolate the issue.

[0xmichalis]

In the latest simulations i have been running, i have noticed that i/o timeouts only happens when i use 7-8 or more actors. All simulations normally finish but i think that the results i get on 8 or more actor sims are corrupted:

actors: 1, tps: 53.53
actors: 2, tps: 70.95
actors: 3, tps: 85.89
actors: 4, tps: 86.62
actors: 5, tps: 87.34
actors: 6, tps: 86.25
actors: 7, tps: 86.49
actors: 8, tps: 91.53
actors: 9, tps: 98.87
actors: 10, tps: 111.17
actors: 11, tps: 119.15

https://github.com/conformal/btcsim/blob/fb66752c24ee9d9260d71269d25d304063b69da0/img/1-11.png This curve is not realistic, the number of transactions per second should tend to align around 8 actors but instead it starts growing more and more.

https://github.com/conformal/btcsim/blob/fb66752c24ee9d9260d71269d25d304063b69da0/img/1-7.png This is a more realistic approach to it.

ps. averaged the above results from the following simulations: http://pastebin.com/GmDgZegd ./btcsim -maxblocks 14000 -maxactors [1-11]

[0xmichalis]

I am suspecting that the reason behind i/o timeouts now happening to a-fixed-number-of-actors simulations (7 in my case) and more rather than randomly to any number [of actors] has to do with the transition from SendFrom* to raw transactions.