1
General Discussion / Re: Site problem
« on: July 17, 2017, 02:41:47 pm »
This should be resolved, pls reply if you find any other errors.
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Hi @roadscape and all, i am about to submit a worker proposal that includes work in the new explorer: http://bitshares-explorer.io:9009/#/dashboard.
the worker is mainly for bitshares core development, the explorer development is just 1 of the tasks i was planning to work on. i started to work in a block explorer when the community claimed for it by different channels. it is not my intention to compete with cryptofresh for a worker or anything like that. i really like cryptofresh and it is probably the bitshares company standard. if it is updated and open source my explorer project will never started.
in the other hand i will love to continue with bitshares-explorer.io. we can maybe find a solution working together somehow.
let me know.
I remember you have got about 4 million BTS from your last worker,
can you tell us what's the 4 M BTS pay for?
It has been fixed, thanks
Hallo Roadscape, I am using Cryptofresh every day to analyze bitshares adoption. I realy need a couple of tool:
1) The total bts fee paid to the network on a daily basis (whit a graph)
2) A better graph were is possible to where you can vary the time frame and set a some mobile mean (at least just a weekly mobile mean)
Total fee paid to the network expressed in bts (and if it is possible in bitcoin) is crucial to better understand the real network adoption.
Thanks in Advance
Paolo Rebuffo
we need more posts like this! Let's stop arguing between ourselves when we all want the same thing, and recognize people such as Ronny that devote an incredible amount of energy to making this project successful. I agree with btswolf that the project wouldn't be the same without him.
Go Ronny!
I've already said that you guys are, as usual, overreacting to something that 1. should not have been news to you and 2. is being misrepresented.
I have Z E R O doubt bytemaster fully believes in his original vision for what BitShares should become. The problem may well be in his ability to communicate that vision effectively to the masses, but that's a marketing function, not that of a technical guru.
The problem in a nutshell isn't that BM has lost his passion for BitShares, it's that "BitShares" has lost its dedication to the mission. So as Stan says BM is simply looking for another way to fund his passion, and my hats off to him for the way in which he is doing that.
I tested it and confirm the issue to do with low resources - ie low cpu power or bandwidth.It's strange that it occurs on exactly same block: 2821722.
I replaced the blockchain folder on one node with a full backup, then it runs well. And the other node is catching up as well.
Trying to reproduce.
//Update:
Reproduced.
Most probably you're correct. Lots of these kind of entries in the log:Code: [Select]2016-04-21T12:03:29 p2p:message read_loop fetch_next_batch_of_ ] sync: sending a request for the next items after 002b0e5a206413b5f17ee209705b51b3cb90fa4c to peer 188.165.233.53:54674, (full request is ["002b0e48227e963b3fa7ebede652334b696e59d8","002b0e528f2ba15ab707c3646bb8b07a0007615f","002b0e571c3f3d9a9c7713ddacd69531c615ebe3","002b0e5966422ef475e20ef2c96acdaec7d51127","002b0e5a206413b5f17ee209705b51b3cb90fa4c"]) node.cpp:2427
2016-04-21T12:03:30 p2p:terminate_inactive_connections_loop terminate_inactive_c ] Disconnecting peer 188.165.233.53:54674 because they didn't respond to my request for sync item ids after ["002b0e48227e963b3fa7ebede652334b696e59d8","002b0e528f2ba15ab707c3646bb8b07a0007615f","002b0e571cf3d9a9c7713ddacd69531c615ebe3","002b0e5966422ef475e20ef2c96acdaec7d51127","002b0e5a206413b5f17ee209705b51b3cb90fa4c"] node.cpp:1403
I think it can be optimized. In the code :Code: [Select]// set the ignored request time out to 1 second. When we request a block
The timeout applies even when syncing (batch fetching), but 1 second is perhaps too short for that?
// or transaction from a peer, this timeout determines how long we wait for them
// to reply before we give up and ask another peer for the item.
// Ideally this should be significantly shorter than the block interval, because
// we'd like to realize the block isn't coming and fetch it from a different
// peer before the next block comes in. At the current target of 3 second blocks,
// 1 second seems reasonable. When we get closer to our eventual target of 1 second
// blocks, this will need to be re-evaluated (i.e., can we set the timeout to 500ms
// and still handle normal network & processing delays without excessive disconnects)
fc::microseconds active_ignored_request_timeout = fc::seconds(1);
Further thinking: why it happens magically on block 2821722 ?
@cube @arhag @pc @theoretical @bytemaster
That sounds promising. Does it exist? This seems like a fairly straight forward request - like the first thing that blockchain would have been used for. So an application should exist, true?