References: <536FAFEA.5050404@gmail.com>
	<CA+s+GJAoLTrujeHVEUZYDR1mNUFHVsLhH9BYPntrxLKzMm_AEw@mail.gmail.com>
In-Reply-To: <CA+s+GJAoLTrujeHVEUZYDR1mNUFHVsLhH9BYPntrxLKzMm_AEw@mail.gmail.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii
Message-Id: <AE9CCC5A-0DAB-4F5A-93D6-C2CA9484C4A4@krellan.net>
From: Josh Lehan <krellan@krellan.net>
Date: Tue, 13 May 2014 10:48:19 -0700
To: Wladimir <laanwj@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] statoshi.info is now live
Precedence: list

I agree, it looks very slick.  Well done.

While on the subject of connected peers, what about the idea of adding the p=
ing time from this node to other peers?  The problem with fitting that infor=
mation into the current design is that the graphs seem to be comprised of ov=
erall statistics for this node, not per-peer statistics that can vary betwee=
n peers (such as ping time).  If a line were to be added to a graph to repre=
sent each peer's ping time, the number of lines (statistics) on the graph wo=
uld have to vary in real time as peers are added or removed, which would be a=
 challenge.

I earlier added the "ping" feature to bitcoind, and it works to measure the p=
ing time, however this feature is on-demand: it won't ping other nodes unles=
s requested.  So, something would have to send the "ping" RPC command on a r=
egular schedule, to ensure the graph is updated with new information.  Also,=
 there is currently no support for overlapping pings (although that would be=
 easy to add), so if a peer is slow enough to not respond at all to the firs=
t ping request, and a second ping request goes out in the meantime, any late=
 response from the first ping request would then be discarded.

Great graphs, and these are just brainstorms for future ideas :)

Josh Lehan

Sent from my iPad

> On May 13, 2014, at 4:43, Wladimir <laanwj@gmail.com> wrote:
>=20
> Hello Jameson,
>=20
>> On Sun, May 11, 2014 at 7:14 PM, Jameson Lopp <jameson.lopp@gmail.com> wr=
ote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>=20
>> Since it seems unlikely that we'll be able to ship an integrated stats / m=
onitoring feature in the short term, I went ahead and set up a public Statos=
hi instance and threw a nicer interface on top of it.
>>=20
>> http://statoshi.info
>=20
> Must say it looks very nice.
>=20
> One comment about the graphs: in the 'connected peers' chart you
> visualize some larger quantities (especially knownAddresses) and some
> very small ones (peer.(dis)connect). This makes the latter invisible
> due to scale.
>=20
> Some random stats may be useful as well:
>=20
> - Number of connected peers that are SPV clients or full nodes (NODE_NETWO=
RK)
> - Current block height (so that it's possible to detect stuck nodes)
> - Number of transactions in mempool
> - Number of transactions in UTXO set
> - Maybe some fee statistics,
> https://github.com/bitcoin/bitcoin/pull/3959 would be useful here
> - Number of orphan blocks/orphan transactions
>=20
> Wladimir
>=20
> --------------------------------------------------------------------------=
----
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform avail=
able
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development