public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Angel Leon <gubatron@gmail•com>
To: Matt Whitlock <bip@mattwhitlock•name>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] have there been complains about network congestion? (router crashes, slow internet when running Bitcoin nodes)
Date: Tue, 8 Apr 2014 12:36:07 -0400	[thread overview]
Message-ID: <CADZB0_Zcx7qOsb0ViTFCGs7ve5oBqx6VB0vQfEnA8cxC8LSVmA@mail.gmail.com> (raw)
In-Reply-To: <3054815.493DgUE4ho@crushinator>

[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]

only that in the real world most routers suck and people don't even know
how to configure them (reminds me of the convo about people not installing
plugins)
this is why the wheel had to be reinvented for the bittorrent world, and it
works.

http://twitter.com/gubatron


On Tue, Apr 8, 2014 at 12:30 PM, Matt Whitlock <bip@mattwhitlock•name>wrote:

> On Tuesday, 8 April 2014, at 12:13 pm, Angel Leon wrote:
> > I was wondering if we have or expect to have these issues in the future,
> > perhaps uTP could help greatly the performance of the entire network at
> > some point.
>
> Or people could simply learn to configure their routers correctly. The
> only time I ever notice that Bitcoind is saturating my upstream link is
> when I try to transfer a file using SCP from a computer on my home network
> to a computer out on the Internet somewhere. SCP sets the "maximize
> throughput" flag in the IP "type of service" field, and my router
> interprets that as meaning low priority, and so those SCP transfers get
> stalled behind Bitcoind. But mostly everything else (e.g., email, web
> browsing, instant messaging, SSH) shows no degration whatsoever regardless
> of what Bitcoind is doing. The key is to move the packet queue from the
> cable modem into the router, where intelligent decisions about packet
> priority and reordering can be enacted.
>
> µTP pretty much reinvents the wheel, and it does so in userspace, where
> the overhead is greater. There's no need for it if proper QoS is in effect.
>

[-- Attachment #2: Type: text/html, Size: 1978 bytes --]

  reply	other threads:[~2014-04-08 16:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-08 16:13 Angel Leon
2014-04-08 16:30 ` Matt Whitlock
2014-04-08 16:36   ` Angel Leon [this message]
2014-04-08 16:44 ` Gregory Maxwell
2014-04-08 16:48 ` Wladimir
2014-04-08 17:33   ` Angel Leon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADZB0_Zcx7qOsb0ViTFCGs7ve5oBqx6VB0vQfEnA8cxC8LSVmA@mail.gmail.com \
    --to=gubatron@gmail$(echo .)com \
    --cc=bip@mattwhitlock$(echo .)name \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox