From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BE0FD40A for ; Thu, 23 Jul 2015 15:04:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C3C12112 for ; Thu, 23 Jul 2015 15:04:41 +0000 (UTC) Received: by lahe2 with SMTP id e2so96974414lah.1 for ; Thu, 23 Jul 2015 08:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CYRhsUiJZSJE5ad/WgXX3LS43/mt1cmLgChJamQz1l8=; b=ur32+9Mi7yPt+mEeyQsvypiSYOYxTixe3VKYsettsb26QeGj9fFh2skGonyMFwbEZZ YBOjSBqo0ZcpKIjo5uZxLLLJwC+7jfnoi2qbhQ9q+CyGCfkUoHND8s5JL+Xq8X0QXhxi PTBTd9yxBL6nK8N/72U5ZuvCqDRJxoQtiV5DedBiVElAhRzzxktufZq3T689cNTNcztd wXa7iJi/5oVbV9jyUNx2tX1074sXgR37UixtjLanbtSRpqGwlCsxfwoGnrfNrzFIkmym qeoabYe73Xn+/h2sooGGxCPtBIfYxcp7RYSarP3GNl0rCVZM1pNyiYzVz7SePlR7U7mq duYg== MIME-Version: 1.0 X-Received: by 10.152.19.67 with SMTP id c3mr8531070lae.4.1437663879966; Thu, 23 Jul 2015 08:04:39 -0700 (PDT) Received: by 10.25.90.75 with HTTP; Thu, 23 Jul 2015 08:04:39 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Jul 2015 11:04:39 -0400 Message-ID: From: Gavin Andresen To: slurms@gmx.us Content-Type: multipart/alternative; boundary=089e0149420adf379b051b8c3432 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Bitcoin Node Speed Test X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 15:04:42 -0000 --089e0149420adf379b051b8c3432 Content-Type: text/plain; charset=UTF-8 Ahh, data... a breath of fresh air... Can you re-analyze for 8MB blocks? There is no current proposal for 20MB blocks. Also, most hashing power is now using Matt Corallo's fast block propagation network; slow 'block' propagation to merchants/end-users doesn't really matter (as long as it doesn't get anywhere near the 10-minute block time). On Thu, Jul 23, 2015 at 10:19 AM, slurms--- via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On this day, the Bitcoin network was crawled and reachable nodes surveyed > to find their maximum throughput in order to determine if it can safely > support a faster block rate. Specifically this is an attempt to prove or > disprove the common statement that 1MB blocks were only suitable slower > internet connections in 2009 when Bitcoin launched, and that connection > speeds have improved to the point of obviously supporting larger blocks. > > > The testing methodology is as follows: > > * Nodes were randomly selected from a peers.dat, 5% of the reachable > nodes in the network were contacted. > > * A random selection of blocks was downloaded from each peer. > > * There is some bias towards higher connection speeds, very slow > connections (<30KB/s) timed out in order to run the test at a reasonable > rate. > > * The connecting node was in Amsterdam with a 1GB NIC. > > > Results: > > * 37% of connected nodes failed to upload blocks faster than 1MB/s. > > * 16% of connected nodes uploaded blocks faster than 10MB/s. > > * Raw data, one line per connected node, kilobytes per second > http://pastebin.com/raw.php?i=6b4NuiVQ > > > This does not support the theory that the network has the available > bandwidth for increased block sizes, as in its current state 37% of nodes > would fail to upload a 20MB block to a single peer in under 20 seconds > (referencing a number quoted by Gavin). If the bar for suitability is > placed at taking only 1% of the block time (6 seconds) to upload one block > to one peer, then 69% of the network fails for 20MB blocks. For comparison, > only 10% fail this metric for 1MB blocks. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- -- Gavin Andresen --089e0149420adf379b051b8c3432 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ahh, data... a breath of fresh air...

C= an you re-analyze for 8MB blocks?=C2=A0 There is no current proposal for 20= MB blocks.

Also, most hashing power is now using M= att Corallo's fast block propagation network; slow 'block' prop= agation to merchants/end-users doesn't really matter (as long as it doe= sn't get anywhere near the 10-minute block time).

On Thu, Jul 23, 2015 at 10:= 19 AM, slurms--- via bitcoin-dev <bitcoin-dev@lists.li= nuxfoundation.org> wrote:
O= n this day, the Bitcoin network was crawled and reachable nodes surveyed to= find their maximum throughput in order to determine if it can safely suppo= rt a faster block rate. Specifically this is an attempt to prove or disprov= e the common statement that 1MB blocks were only suitable slower internet c= onnections in 2009 when Bitcoin launched, and that connection speeds have i= mproved to the point of obviously supporting larger blocks.


The testing methodology is as follows:

=C2=A0* Nodes were randomly selected from a peers.dat, 5% of the reachable = nodes in the network were contacted.

=C2=A0* A random selection of blocks was downloaded from each peer.

=C2=A0* There is some bias towards higher connection speeds, very slow conn= ections (<30KB/s) timed out in order to run the test at a reasonable rat= e.

=C2=A0* The connecting node was in Amsterdam with a 1GB NIC.

=C2=A0
Results:

=C2=A0* 37% of connected nodes failed to upload blocks faster than 1MB/s.
=C2=A0* 16% of connected nodes uploaded blocks faster than 10MB/s.

=C2=A0* Raw data, one line per connected node, kilobytes per second http://pastebin.com/raw.php?i=3D6b4NuiVQ


This does not support the theory that the network has the available bandwid= th for increased block sizes, as in its current state 37% of nodes would fa= il to upload a 20MB block to a single peer in under 20 seconds (referencing= a number quoted by Gavin). If the bar for suitability is placed at taking = only 1% of the block time (6 seconds) to upload one block to one peer, then= 69% of the network fails for 20MB blocks. For comparison, only 10% fail th= is metric for 1MB blocks.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev



--
--
Gavin Andresen
--089e0149420adf379b051b8c3432--