From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WkH54-00015c-JK for bitcoin-development@lists.sourceforge.net; Tue, 13 May 2014 18:05:34 +0000 X-ACL-Warn: Received: from transmat.krellan.net ([70.36.220.56] helo=tardis.krellan.net) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WkH53-000523-0h for bitcoin-development@lists.sourceforge.net; Tue, 13 May 2014 18:05:34 +0000 Received: from [IPv6:2001:470:1f05:12fe:1075:1eb1:7ae9:881] (unknown [IPv6:2001:470:1f05:12fe:1075:1eb1:7ae9:881]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tardis.krellan.net (Postfix) with ESMTPSA id 2760A400C07; Tue, 13 May 2014 10:48:22 -0700 (PDT) References: <536FAFEA.5050404@gmail.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (11D201) From: Josh Lehan Date: Tue, 13 May 2014 10:48:19 -0700 To: Wladimir X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.3 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) [URIs: statoshi.info] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WkH53-000523-0h Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] statoshi.info is now live X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 18:05:34 -0000 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 wrote: >=20 > Hello Jameson, >=20 >> On Sun, May 11, 2014 at 7:14 PM, Jameson Lopp 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