BitShares Forum
Main => General Discussion => Topic started by: emski on September 19, 2014, 07:14:19 am
-
Here is the output of 0.4.16-RC1
(wallet closed) >>> blockchain_list_blocks
HEIGHT TIMESTAMP SIGNING DELEGATE # TXS SIZE LATENCY PROCESSING TIME
===================================================================================================
524633 2014-09-19T07:11:00 dc-delegate 0 166 0 0.001018
524632 2014-09-19T07:10:50 b.delegate.xeroc 0 166 0 0.000921
524631 2014-09-19T07:10:40 anchor.crazybit 0 166 1 0.001981
524630 2014-09-19T07:10:30 delegate1-galt 0 166 0 0.000916
524629 2014-09-19T07:10:20 a.delegate.xeroc 0 166 0 0.000973
524628 2014-09-19T07:10:10 delegate2.adam 0 166 0 0.000837
524627 2014-09-19T07:10:00 immortal.bitdelegate 0 166 0 0.001771
524626 2014-09-19T07:09:50 www.minebitshares-com 0 166 5 0.000647
524625 2014-09-19T07:09:40 delegate.webber 0 166 15 0.000731
524624 2014-09-19T07:09:30 mrs.agsexplorer 0 166 25 0.000679
524623 2014-09-19T07:09:20 delegate-baozi 0 166 35 0.000648
524622 2014-09-19T07:09:10 happyshares-2 0 166 45 0.000649
524621 2014-09-19T07:09:00 init43 0 166 55 0.000664
524620 2014-09-19T07:08:50 delegate.liondani 0 166 65 0.000689
524619 2014-09-19T07:08:40 init53 0 166 75 0.000695
524618 2014-09-19T07:08:30 wackou-delegate 0 166 85 0.000673
524617 2014-09-19T07:08:20 riverhead-del-server-1 0 166 95 0.005542
524616 2014-09-19T07:08:10 emski 8 1458 105 0.001207
524615 2014-09-19T07:08:00 mr.agsexplorer 0 166 115 0.000699
524614 2014-09-19T07:07:50 delegate.xeroc 0 166 125 0.000671
(wallet closed) >>> info
{
"blockchain_head_block_num": 524633,
"blockchain_head_block_age": "10 seconds old",
"blockchain_head_block_timestamp": "2014-09-19T07:11:00",
"blockchain_average_delegate_participation": "99.02 %",
"blockchain_confirmation_requirement": 1,
"blockchain_delegate_pay_rate": "2.68357 BTSX",
"blockchain_share_supply": "1,999,872,545.30412 BTSX",
"blockchain_blocks_left_in_round": 62,
"blockchain_next_round_time": "at least 10 minutes in the future",
"blockchain_next_round_timestamp": "2014-09-19T07:21:30",
"blockchain_random_seed": "c1d44518e765cb16437ac0080b45e678e14547ab",
"client_data_dir": "/home/emski/bitsharesExperimental/bitsharesx/programs/client/v0.4.15-RC1",
"client_version": "v0.4.16-RC1",
"network_num_connections": 10,
"network_num_connections_max": 200,
"ntp_time": "2014-09-19T07:11:10",
"ntp_time_error": 0.000687,
"wallet_open": false,
"wallet_unlocked": null,
"wallet_unlocked_until": null,
"wallet_unlocked_until_timestamp": null,
"wallet_last_scanned_block_timestamp": null,
"wallet_scan_progress": null,
"wallet_block_production_enabled": null,
"wallet_next_block_production_time": null,
"wallet_next_block_production_timestamp": null
}
And here is the output of 0.4.15-RC1:
(wallet closed) >>> blockchain_list_blocks
HEIGHT TIMESTAMP SIGNING DELEGATE # TXS SIZE TOTAL FEES LATENCY PROCESSING TIME
===================================================================================================================
524633 2014-09-19T07:11:00 dc-delegate 0 166 0.00000 BTSX 0 0.001959
524632 2014-09-19T07:10:50 b.delegate.xeroc 0 166 0.00000 BTSX 0 0.000941
524631 2014-09-19T07:10:40 anchor.crazybit 0 166 0.00000 BTSX 0 0.002007
524630 2014-09-19T07:10:30 delegate1-galt 0 166 0.00000 BTSX 0 0.002048
524629 2014-09-19T07:10:20 a.delegate.xeroc 0 166 0.00000 BTSX 0 0.000939
524628 2014-09-19T07:10:10 delegate2.adam 0 166 0.00000 BTSX 0 0.002081
524627 2014-09-19T07:10:00 immortal.bitdelegate 0 166 0.00000 BTSX 0 0.001859
524626 2014-09-19T07:09:50 www.minebitshares-com 0 166 0.00000 BTSX 0 0.001804
524625 2014-09-19T07:09:40 delegate.webber 0 166 0.00000 BTSX 0 0.000893
524624 2014-09-19T07:09:30 mrs.agsexplorer 0 166 0.00000 BTSX 0 0.001424
524623 2014-09-19T07:09:20 delegate-baozi 0 166 0.00000 BTSX 0 0.001942
524622 2014-09-19T07:09:10 happyshares-2 0 166 0.00000 BTSX 0 0.002074
524621 2014-09-19T07:09:00 init43 0 166 0.00000 BTSX 0 0.000896
524620 2014-09-19T07:08:50 delegate.liondani 0 166 0.00000 BTSX 0 0.001869
524619 2014-09-19T07:08:40 init53 0 166 0.00000 BTSX 0 0.000943
524618 2014-09-19T07:08:30 wackou-delegate 0 166 0.00000 BTSX 0 0.000913
524617 2014-09-19T07:08:20 riverhead-del-server-1 0 166 0.00000 BTSX 0 0.014054
524616 2014-09-19T07:08:10 emski 8 1458 4.00000 BTSX 0 0.001857
524615 2014-09-19T07:08:00 mr.agsexplorer 0 166 0.00000 BTSX 0 0.000883
524614 2014-09-19T07:07:50 delegate.xeroc 0 166 0.00000 BTSX 0 0.001772
--- there are now 105 active connections to the p2p network
(wallet closed) >>> info
{
"blockchain_head_block_num": 524633,
"blockchain_head_block_age": "3 seconds old",
"blockchain_head_block_timestamp": "2014-09-19T07:11:00",
"blockchain_average_delegate_participation": "100.00 %",
"blockchain_confirmation_requirement": 1,
"blockchain_accumulated_fees": "324,604.86432 BTSX",
"blockchain_delegate_pay_rate": "2.68357 BTSX",
"blockchain_share_supply": "1,999,872,545.34366 BTSX",
"blockchain_blocks_left_in_round": 62,
"blockchain_next_round_time": "at least 10 minutes in the future",
"blockchain_next_round_timestamp": "2014-09-19T07:21:20",
"blockchain_random_seed": "c1d44518e765cb16437ac0080b45e678e14547ab",
"client_data_dir": "/home/emski/bitsharesSeed/bitsharesx/programs/client/v0.4.15-RC1",
"client_version": "v0.4.15-RC1",
"network_num_connections": 105,
"network_num_connections_max": 400,
"ntp_time": "2014-09-19T07:11:03",
"ntp_time_error": 0.0051399999999999996,
"wallet_open": false,
"wallet_unlocked": null,
"wallet_unlocked_until": null,
"wallet_unlocked_until_timestamp": null,
"wallet_last_scanned_block_timestamp": null,
"wallet_scan_progress": null,
"wallet_block_production_enabled": null,
"wallet_next_block_production_time": null,
"wallet_next_block_production_timestamp": null
}
As you can see there is significant difference in latency reported by both versions.
I'll delay the update until it is confirmed OK.
UPDATE: It seems however this is only due to synchronization. I haven't seen such latency after that. I'll monitor it for a while before updating.
-
running 0.4.16-RC1, output here :
HEIGHT TIMESTAMP SIGNING DELEGATE # TXS SIZE LATENCY PROCESSING TIME
===================================================================================================
524847 2014-09-19T07:46:40 emski.bitdelegate 1 382 0 0.012233
524846 2014-09-19T07:46:30 happyshares-2 0 166 0 0.003324
524845 2014-09-19T07:46:20 ak 0 166 0 0.003351
524844 2014-09-19T07:46:10 dac.bts500 0 166 0 0.003295
524843 2014-09-19T07:46:00 hear.me.roar.lion 0 166 0 0.003651
524842 2014-09-19T07:45:50 b.delegate.xeroc 0 166 0 0.003418
524841 2014-09-19T07:45:40 www.minebitshares-com 1 410 0 0.009221
524840 2014-09-19T07:45:30 delegate.xeldal 0 166 0 0.00341
524839 2014-09-19T07:45:20 delegate.xeroc 0 166 0 0.003283
524838 2014-09-19T07:45:10 delegate.liondani 0 166 0 0.003366
524837 2014-09-19T07:45:00 bitcoiners 0 166 0 0.003826
524836 2014-09-19T07:44:50 google.helloworld 0 166 0 0.003383
524835 2014-09-19T07:44:40 dele-puppy 0 166 0 0.003302
524834 2014-09-19T07:44:30 cny.bts500 0 166 0 0.003373
524833 2014-09-19T07:44:20 dac.coolspeed 0 166 0 0.003685
524832 2014-09-19T07:44:10 delegate1-galt 0 166 0 0.003353
524831 2014-09-19T07:44:00 delegate-watchman 0 166 0 0.00333
524830 2014-09-19T07:43:50 sun.delegate.service 0 166 0 0.003278
524829 2014-09-19T07:43:40 spartako2 1 794 0 0.017383
524828 2014-09-19T07:43:30 init70 0 166 0 0.003457
seems not systemic, monitoring
-
IIRC the latency is not an objective measure, it's measured relative to your client. This means you need to be online and synced in order for your client to record correct latency information, blocks produced while you were offline will have high (incorrect) latencies .
-
IIRC the latency is not an objective measure, it's measured relative to your client. This means you need to be online and synced in order for your client to record correct latency information, blocks produced while you were offline will have high (incorrect) latencies .
Yes I'm aware of that. However I haven't noticed the same behavior in the old client. Even though this behavior is technically correct it is new.
-
IIRC the latency is not an objective measure, it's measured relative to your client. This means you need to be online and synced in order for your client to record correct latency information, blocks produced while you were offline will have high (incorrect) latencies .
Yes I'm aware of that. However I haven't noticed the same behavior in the old client. Even though this behavior is technically correct it is new.
emski if your a volunteer like me (not actually on the dev team) your doing a great job either way. +5%
-
I have checked out v0.4.16-RC1 and I get the following compiler error:
source/bitsharesx/programs/utils/web_update_utility/update_utility.hpp:5:26: fatal error: WebUpdates.hpp: No such file or directory
#include <WebUpdates.hpp>
Did someone forget to check that file in?
-
I have checked out v0.4.16-RC1 and I get the following compiler error:
source/bitsharesx/programs/utils/web_update_utility/update_utility.hpp:5:26: fatal error: WebUpdates.hpp: No such file or directory
#include <WebUpdates.hpp>
Did someone forget to check that file in?
I have the same error reports as yours
-
Sub module update
-
Sub module update
I already did that - no luck.
git submodule update
-
Sub module update
I already did that - no luck.
git submodule update
try git submodule init
-
Aah so I forgot to specify the target with:
make BitSharesX
When I just make everything, the web_update_utility_automoc target fails to build.
-
Found the problem. Had to
rm CMakeCache.txt
cmake .
now it compiles.
-
Getting connections seems to be a lot slower.
I've started a delegate and it had 2 connections for the last 10 minutes.
I manually added all the seed nodes I could find but I still have only 2 connections.
I tried to restart - no luck.
Older version on the same machine finds connections much faster (15 connections 20 seconds after start).
-
Getting connections seems to be a lot slower.
I've started a delegate and it had 2 connections for the last 10 minutes.
I manually added all the seed nodes I could find but I still have only 2 connections.
I tried to restart - no luck.
Older version on the same machine finds connections much faster (15 connections 20 seconds after start).
Can you run the old version now and still get the 15 connections after 20 seconds? I'd like to establish if the difference is in the client or in the current state of the network (e.g. less public nodes to connect to versus nodes behind firewalls).
-
Getting connections seems to be a lot slower.
I've started a delegate and it had 2 connections for the last 10 minutes.
I manually added all the seed nodes I could find but I still have only 2 connections.
I tried to restart - no luck.
Older version on the same machine finds connections much faster (15 connections 20 seconds after start).
Can you run the old version now and still get the 15 connections after 20 seconds? I'd like to establish if the difference is in the client or in the current state of the network (e.g. less public nodes to connect to versus nodes behind firewalls).
I ran both versions at the same time simultaneously.
I'll try again though.
UPDATE: I'm running again both versions. The results seem to be comparable - 10 minutes after the start 4-6 connections for both versions.
The strange thing is that the seed node that was running for at least an hour has only 25 connections. However this might not be related to the version.
-
Getting connections seems to be a lot slower.
I've started a delegate and it had 2 connections for the last 10 minutes.
I manually added all the seed nodes I could find but I still have only 2 connections.
I tried to restart - no luck.
Older version on the same machine finds connections much faster (15 connections 20 seconds after start).
Can you run the old version now and still get the 15 connections after 20 seconds? I'd like to establish if the difference is in the client or in the current state of the network (e.g. less public nodes to connect to versus nodes behind firewalls).
I ran both versions at the same time simultaneously.
I'll try again though.
UPDATE: I'm running again both versions. The results seem to be comparable - 10 minutes after the start 4-6 connections for both versions.
The strange thing is that the seed node that was running for at least an hour has only 25 connections. However this might not be related to the version.
Not a seed node or a delegate + still running 0.4.15 (as no exe is available yet for 0.4.16, but):
>> get_info
....
"blockchain_head_block_age": "8 minutes old",
"blockchain_average_delegate_participation": "68.71 %",
........
>> network_get_connection_count
8
[EDIT] restarting the client seems to help. For now.
-
Looks like I spoke too soon, but I don't think my problem is really related to this version in particular.
I decided to test running it with "--accept-incoming-connections false", but ended up losing most connections and missing some blocks because of it. Would be nice if it were possible to run the client like that for security reasons, but every time I've tested I end up losing most of my connections and getting out of sync.