Author Topic: October 5 Test Network  (Read 127139 times)

0 Members and 1 Guest are viewing this topic.

Offline spartako

  • Sr. Member
  • ****
  • Posts: 401
    • View Profile
bitshares-argentina  can you please let me know if you have changed your software in any way because it appears your node is consistently producing blocks even though you are not in the set of active witnesses.

Everyone else, please update your witness to the latest master before block 58500  (about 4 hours).

spartako updated to the lastest master
wallet_account_set_approval spartako

Offline Bhuz

  • Committee member
  • Sr. Member
  • *
  • Posts: 467
    • View Profile
  • BitShares: bhuz
Everyone else, please update your witness to the latest master before block 58500  (about 4 hours).

Can someone please tell me how to update the witness without stop it?

Can I copy the current "graphene" folder, rename it to "current-graphene", update the copied "graphene", restart the witness in this new folder?
Do I have to use update_witness when launching the updated one? How does it works?

Thanks xD
« Last Edit: October 07, 2015, 01:49:00 pm by Bhuz »

Offline Fox

Have you deleted the object_database and oct5 directories as Spectral did?
Historically all that I have done is issue --resync-blockchain and the witness connects to the seed(s) to rebuild the chain.  Upon witeness startup the console logs:
Code: [Select]
483498ms th_a       witness.cpp:111               plugin_initialize    ] witness plugin:  plugin_initialize() end
483500ms th_a       db_management.cpp:98          wipe                 ] Wiping database
483513ms th_a       object_database.cpp:81        wipe                 ] Wiping object_database.
484226ms th_a       application.cpp:242           operator()           ] Initializing database...

However, "Wiping object_database" does not seem to be occurring as expected, as the witness was unable to get blocks beyond 45158.

I did take the advise to manually remove both the object_database and data_dir directories from the witness, leaving only the genesis.json file.  This of course forces the node to start from a clean state.  This resulted in a proper sync to the main chain.

This seems like a bug to me, but will defer to development to review if that is as designed functionality.  If so, please advise what the best practice is to force the witness to start from a clean state using command line options, as I'd rather not script from shell.

Best,
Fox
Witness: fox

Offline bytemaster

bitshares-argentina  can you please let me know if you have changed your software in any way because it appears your node is consistently producing blocks even though you are not in the set of active witnesses.

Everyone else, please update your witness to the latest master before block 58500  (about 4 hours).

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline twitter

  • Sr. Member
  • ****
  • Posts: 279
    • View Profile
If you are are seeing very high latency try restarting your witness to see if it lowers your latency.
it  may be caused by network resource limitations. I had same problem while using home internet from bell and getting much better after moving my server to hosting data center
witness:

Offline Spectral

How can I see my own latency?

On the witness_node you should see at the end of the Got block line
for example:
Code: [Select]
2796111ms th_a       application.cpp:388           handle_block         ] Got block #53313 with time 2015-10-07T12:46:36 from network with latency of 110 ms from init9
2799000ms th_a       witness.cpp:182               block_production_loo ] Not producing block because it isn't my turn
2799568ms th_a       application.cpp:388           handle_block         ] Got block #53314 with time 2015-10-07T12:46:39 from network with latency of 567 ms from in.abit
2802000ms th_a       witness.cpp:182               block_production_loo ] Not producing block because it isn't my turn
2802111ms th_a       application.cpp:388           handle_block         ] Got block #53315 with time 2015-10-07T12:46:42 from network with latency of 109 ms from init4

Is that my own witness latency? I thought that was the latency of the others.

Or maybe it is composite latency...
« Last Edit: October 07, 2015, 12:53:49 pm by Spectral »
Vote for BTS-2 witness: spectral (1.6.30)
0.9 DVS delegate: dvs1.bitspace
Stay tuned for bitspace-clains worker!

Offline Bhuz

  • Committee member
  • Sr. Member
  • *
  • Posts: 467
    • View Profile
  • BitShares: bhuz
How can I see my own latency?

On the witness_node you should see at the end of the Got block line
for example:
Code: [Select]
2796111ms th_a       application.cpp:388           handle_block         ] Got block #53313 with time 2015-10-07T12:46:36 from network with latency of 110 ms from init9
2799000ms th_a       witness.cpp:182               block_production_loo ] Not producing block because it isn't my turn
2799568ms th_a       application.cpp:388           handle_block         ] Got block #53314 with time 2015-10-07T12:46:39 from network with latency of 567 ms from in.abit
2802000ms th_a       witness.cpp:182               block_production_loo ] Not producing block because it isn't my turn
2802111ms th_a       application.cpp:388           handle_block         ] Got block #53315 with time 2015-10-07T12:46:42 from network with latency of 109 ms from init4

Offline Spectral

If you are are seeing very high latency try restarting your witness to see if it lowers your latency.

How can I see my own latency?
Vote for BTS-2 witness: spectral (1.6.30)
0.9 DVS delegate: dvs1.bitspace
Stay tuned for bitspace-clains worker!

Offline lafona

  • Sr. Member
  • ****
  • Posts: 231
    • View Profile
  • BitShares: lafona
just checked again and it is now synced up with the network. I didn't change anything though...
BTS Witnesses: delegate-1.lafona     Witness Thread: https://bitsharestalk.org/index.php/topic,21569.msg280911/topicseen.html#msg280911
MUSE Witness: lafona

Offline bytemaster

If you are are seeing very high latency try restarting your witness to see if it lowers your latency.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline Bhuz

  • Committee member
  • Sr. Member
  • *
  • Posts: 467
    • View Profile
  • BitShares: bhuz
Don't take this the wrong way, I'm certainly not complaining, but anyone on the proper chain could've easily checked that calling get_witness on spectral. So I guess I should have asked someone to check that. Something to remember for later.

Sorry but I am new to all these and didn't think to check that

I am in the same state.  My nodes are unable to --resync-blockchain beyond block 45158 using seed node "104.236.51.238:2005"

You are keep missing blocks
Have you deleted the object_database and oct5 directories as Spectral did?

Offline Fox

Woke up this morning to witness not producing blocks. Looks like it might have been on a fork.
Code: [Select]
2907580ms th_a       db_block.cpp:134              _push_block          ] Switching to fork: 0000a4ae2e624ed370d37ab44ab50082f5eb9b71
2907585ms th_a       application.cpp:419           handle_block         ] Error when pushing block:
10 assert_exception: Assert Exception
second_branch_itr != _index.get<block_id>().end():
    {}
    th_a  fork_database.cpp:198 fetch_branch_from

    {"first":"0000a4ae2e624ed370d37ab44ab50082f5eb9b71","second":"0000a3d3d8e5e0d1f70d13aa2e3f2a3f1574bfa8"}
    th_a  fork_database.cpp:229 fetch_branch_from

I am currently having trouble getting it sync back up with the chain, I have tried deleting the oct5 and object_database directories and it still seems to get stuck at block 45158. I am uploading the logs to google drive right now and can share the link as soon as they are ready. Is there another seed node up I can try connecting too?

I am in the same state.  My nodes are unable to --resync-blockchain beyond block 45158 using seed node "104.236.51.238:2005"
Witness: fox

Offline Spectral

Should I do something? restart/reinstall?

Ok, I must have been stuck on a fork. closed the witness node, deleted the object_database and oct5 directories. The witness now starts up and provides normal output.

On calling get_witness it now shows plenty of missed blocks.

Code: [Select]
get_witness spectral
{
  "id": "1.6.38",
  "witness_account": "1.2.73210",
  "last_aslot": 54941,
  "signing_key": "GPH8ZWNd9K82gPqKVDbkK8etaYTBMQ3ME3MTQ6HqF586ZbMLrZ5DH",
  "pay_vb": "1.13.64",
  "vote_id": "1:49",
  "total_votes": "7827836627013",
  "url": "bitspace.no",
  "total_missed": 507,
  "last_confirmed_block_num": 51294
}

Don't take this the wrong way, I'm certainly not complaining, but anyone on the proper chain could've easily checked that calling get_witness on spectral. So I guess I should have asked someone to check that. Something to remember for later.
Vote for BTS-2 witness: spectral (1.6.30)
0.9 DVS delegate: dvs1.bitspace
Stay tuned for bitspace-clains worker!

Offline lafona

  • Sr. Member
  • ****
  • Posts: 231
    • View Profile
  • BitShares: lafona
Woke up this morning to witness not producing blocks. Looks like it might have been on a fork.
Code: [Select]
2907580ms th_a       db_block.cpp:134              _push_block          ] Switching to fork: 0000a4ae2e624ed370d37ab44ab50082f5eb9b71
2907585ms th_a       application.cpp:419           handle_block         ] Error when pushing block:
10 assert_exception: Assert Exception
second_branch_itr != _index.get<block_id>().end():
    {}
    th_a  fork_database.cpp:198 fetch_branch_from

    {"first":"0000a4ae2e624ed370d37ab44ab50082f5eb9b71","second":"0000a3d3d8e5e0d1f70d13aa2e3f2a3f1574bfa8"}
    th_a  fork_database.cpp:229 fetch_branch_from

I am currently having trouble getting it sync back up with the chain, I have tried deleting the oct5 and object_database directories and it still seems to get stuck at block 45158. I am uploading the logs to google drive right now and can share the link as soon as they are ready. Is there another seed node up I can try connecting too?
BTS Witnesses: delegate-1.lafona     Witness Thread: https://bitsharestalk.org/index.php/topic,21569.msg280911/topicseen.html#msg280911
MUSE Witness: lafona

Offline Spectral

have the same problem....
I have deleted "oct5" folder  and "object_database" and tried again but same results....  (could it be the router's firewall?)

I think a core dev or someone with intimate insight into the code needs to assess this output, e.g. @bytemaster...

Quote from: Bhuz
Are yours latency good?

How can I see the latency of my own witness or the others? (see my output, it has no info on that anymore)
« Last Edit: October 07, 2015, 10:40:17 am by Spectral »
Vote for BTS-2 witness: spectral (1.6.30)
0.9 DVS delegate: dvs1.bitspace
Stay tuned for bitspace-clains worker!