Test Net for Advanced Users

[Krills]

For now, the dev team can't even publish a testnet for general users,how low quality they are,no wonder the price act like shit.

[puppies]

It's there currently a way to check witness performance?  I couldn't find one outside of watching my witness node or manually looking at blocks.

[lafona]

Is setting a checkpoint something any witness could do? Would that have been enough keep the testnet going (at least temporarily)?
Also sorry for the massive amount of missed blocks, tried switching my witness to a rasberrypi and never managed to get it working on the vps after that. Guess I got too excited. It did seem to work fine on the micro AWS instance though.

[betax]

Whats going on here?

Code: [Select]

3299997ms th_a       witness.cpp:239               block_production_loo ] slot: 1 scheduled_witness: 1.6.1 scheduled_time: 2015-08-16T08:55:00 now: 2015-08-16T08:55:00
3300134ms th_a       application.cpp:342           handle_block         ] Got block #134274 from network
3300436ms th_a       application.cpp:342           handle_block         ] Got block #134274 from network
3300538ms th_a       application.cpp:437           get_item             ] Request for item {"item_type":1001,"item_hash":"84dc9853e4ddd3941281f6260886aef9713829f0"}
3300997ms th_a       witness.cpp:239               block_production_loo ] slot: 0 scheduled_witness: 1.6.0 scheduled_time: 1970-01-01T00:00:00 now: 2015-08-16T08:55:01
3300998ms th_a       witness.cpp:207               operator()           ] Not producing block because head block time is in the future (is the system clock set correctly?).
3301997ms th_a       witness.cpp:239               block_production_loo ] slot: 0 scheduled_witness: 1.6.0 scheduled_time: 1970-01-01T00:00:00 now: 2015-08-16T08:55:02
3301998ms th_a       witness.cpp:207               operator()           ] Not producing block because head block time is in the future (is the system clock set correctly?).
3302997ms th_a       witness.cpp:239               block_production_loo ] slot: 0 scheduled_witness: 1.6.0 scheduled_time: 1970-01-01T00:00:00 now: 2015-08-16T08:55:03
3302998ms th_a       witness.cpp:207               operator()           ] Not producing block because head block time is in the future (is the system clock set correctly?).
3303997ms th_a       witness.cpp:239               block_production_loo ] slot: 1 scheduled_witness: 1.6.1439 scheduled_time: 2015-08-16T08:55:04 now: 2015-08-16T08:55:04



I have the same issues every so often, and I have ntp running

@Bytemaster any ideas about this issue?

my witness was producing blocks, but every so often we have this issue.

[bytemaster]

For those asking the obvious question: 

The undo history is currently set at 1000 blocks.   Every 10 blocks the undo buffer grew by 2 which means it took the network 83 minutes to "hang" given that 50% of the witnesses were not producing blocks.

[emski]

Is it possible for a pre-anounce of the next test network ?
For example X days before it is started so the witnesses can prepare.

[xeroc]

I have looked into why this test network died and it was due to low witness participation... test witnesses joined, got elected, and failed to produce blocks!      bad, bad test witnesses!   

Under Graphene we have some "safety" features that may be overly strict in the context of a test network. 

The idea is that the nodes will increase the amount of undo history they track by 2 every time a block is missed and decrease it by 1 every time a block is produced.     The nodes are configured to maintain a maximum undo history  and once that history has been reached no new blocks may be pushed without a checkpoint to clear the history.     Since no one was around to produce a checkpoint block production simply stopped.

In a production environment we would expect that witness participation rate shouldn't fall below 66% for very long and if it did then all of the witnesses would be actively monitoring and repairing the network by setting a checkpoint.

With 1 second blocks it probably didn't take much wall-clock time for hit the limit.   

Note: the reason for this limit is to make sure that no blockchain can exist where a new node could get "stuck" on a dead branch and unable to automatically rejoin the main network. 

Can we have the next blockchain start with N=101 witnesses? that way, we can gradually remove the initial delegates that are supposed to be more reliable, aren't they?

[bytemaster]

I have looked into why this test network died and it was due to low witness participation... test witnesses joined, got elected, and failed to produce blocks!      bad, bad test witnesses!   

Under Graphene we have some "safety" features that may be overly strict in the context of a test network. 

The idea is that the nodes will increase the amount of undo history they track by 2 every time a block is missed and decrease it by 1 every time a block is produced.     The nodes are configured to maintain a maximum undo history  and once that history has been reached no new blocks may be pushed without a checkpoint to clear the history.     Since no one was around to produce a checkpoint block production simply stopped.

In a production environment we would expect that witness participation rate shouldn't fall below 66% for very long and if it did then all of the witnesses would be actively monitoring and repairing the network by setting a checkpoint.

With 1 second blocks it probably didn't take much wall-clock time for hit the limit.   

Note: the reason for this limit is to make sure that no blockchain can exist where a new node could get "stuck" on a dead branch and unable to automatically rejoin the main network. 

[bytemaster]

Code: [Select]

locked >>> info
info
{
  "head_block_num": 147334,
  "head_block_id": "00023f868da02c32c1d8c6faef53b4a0c51ade92",
  "head_block_age": "23 hours old",
  "next_maintenance_time": "22 hours ago",
  "chain_id": "081401ede64c8fe30b23c91d7ab8750103acb1a39548a866fb562f2edf4627d6",
  "active_witnesses": [
    "1.6.0",
    "1.6.1",
    "1.6.2",
    "1.6.3",
    "1.6.4",
    "1.6.1435",
    "1.6.1439",
    "1.6.1446",
    "1.6.5155",
    "1.6.5156"
  ],
  "active_committee_members": [
    "1.5.0",
    "1.5.1",
    "1.5.2",
    "1.5.3",
    "1.5.4",
    "1.5.5",
    "1.5.6",
    "1.5.7",
    "1.5.8",
    "1.5.9"
  ],
  "entropy": "cac65461d8694c0c44c9c0909041bb8d15121e79"
}
I had a node that was a mere passive observer on the network and this was its final state.   

[bytemaster]

Well this testnet died a firey death.   We are looking into the cause and will report back later.

[abit]

if anyone wants to keep testing, I have started a new chain.  Just change the seed node to 45.55.6.216:1776

You can use the same wallet, but I am assuming you will need to import_balance again.

oh.  and delete the chain folder or launch with --resync-blockchain

Or set a different data directory. Re-syncing.

[puppies]

if anyone wants to keep testing, I have started a new chain.  Just change the seed node to 45.55.6.216:1776

You can use the same wallet, but I am assuming you will need to import_balance again.

oh.  and delete the chain folder or launch with --resync-blockchain

[roadscape]

I still can't get past 147334. Anyone have a higher blockhead?

I'm stuck at 147,334 as well.

[clayop]

I'm still having the same problem. Waiting for Devs back

[puppies]

I still can't get past 147334. Anyone have a higher blockhead?