I thought Dan said they already did a LAN test, and achieved something like 186k tps. Is there a reason we're trying to do this again? other than capturing it on video. I would think they would have some scripts for this already also.
the WAN test might be more interesting.
It sounds like there are still a great deal of optimizations that can be implemented. Is now the best time to spend money on powerful/connected servers, only to do it again later with better optimizations?
Why can we not just use the existing test network in a organized fashion to capture this data. It may not produce the ultimate upper bounds but should still reveal bottlenecks and have something meaningful for video or whatever media angle you're interested in. Im not fully convinced is best to spend a bunch of money at this time.
I'm willing to donate some personal funds to aid in this:
1. I'm contributing with the following amount of BTS: 2500
2. N/A
3. N/A
but for any significant amount from BitsharesBreakout, at this time I'd like to hold off for a moment to get a better feel for the value derived and necessity for doing this now, and in the way described. Get some feed back from devs etc as to whether this is valuable for their work.
I have to agree with this, we are testing for testing. Why focus in an scenario that we can build towards and not focus on the current world. Our testnet is a good way to prove what we can do now, with the current vps / servers we currently need.
Probably best is to organise the testnet in a better way. If we are using Azure / AWS we can ensure we are all in the same region and using better connectivity. If you are using a home server you are still good to go.
We need to ensure that we have enough funds to test
. Most of us have used puppies /clayop autohotkey script or xerocs (I used xerocs as I was using putty) and quickly ran out. If xerocs script is modified so we distribute funds across all named participants, we might not ran out of CORE. Also ensure that we can quickly restart our witness if down.
Maybe scripts should run a counter to verify all the transactions are sent / received.
Once all this is organised, then we can experiment on scaling vertically and horizontally. More transactions, more clients / users to count votes, bigger vms.