Github cloning really slow?

[Simon Males]

Hi,

For all day yesterday and today I've found interaction with Github really slow with cloning coming in at a rate of 10KiB/s.

I'm on M1.

Anyone else?

$ time git clone g...@github.com:sinatra/sinatra.git
Cloning into 'sinatra'...
remote: Counting objects: 12976, done.
remote: Compressing objects: 100% (5353/5353), done.
remote: Total 12976 (delta 8026), reused 12305 (delta 7434)
Receiving objects: 100% (12976/12976), 2.48 MiB | 11 KiB/s, done.
Resolving deltas: 100% (8026/8026), done.

real    6m2.970s
user    0m0.630s
sys     0m0.250s

--
Simon Males

[Patrick Haller]

On 2013-04-04 18:44, Simon Males wrote:
> For all day yesterday and today I've found interaction with Github really
> slow with cloning coming in at a rate of 10KiB/s.

Does downgrading to ipv4 improve things? M1's connectivity to he.net has
anecdotally gone to carp recently.

If perchance one wonders why HSG runs ipv4 and ipv6, it's because ipv4
is almost dead:

http://www.apnic.net/community/ipv4-exhaustion/graphical-information

[Roland Turner]

Erm "the free handout pool is empty" != "dead". I'd suggest that IPv4
will be with us for decades.

- Roland

[Scott Robinson]

On Fri, Apr 12, 2013, at 13:49, Patrick Haller wrote:
> [...]

> If perchance one wonders why HSG runs ipv4 and ipv6, it's because ipv4
> is almost dead:
>
> http://www.apnic.net/community/ipv4-exhaustion/graphical-information

Opinions vary:



--
Scott Robinson
sc...@quadhome.com

[Scott Robinson]

On Fri, Apr 12, 2013, at 13:49, Patrick Haller wrote:
> [...]

> Does downgrading to ipv4 improve things? M1's connectivity to he.net has
> anecdotally gone to carp recently.
>
> If perchance one wonders why HSG runs ipv4 and ipv6, it's because ipv4
> is almost dead:
>
> http://www.apnic.net/community/ipv4-exhaustion/graphical-information

Opinions vary:

http://internetcensus2012.bitbucket.org/paper.html

(Fat fingered the first e-mail.)

--
Scott Robinson
sc...@quadhome.com

[Patrick Haller]

On 2013-04-12 13:53, Roland Turner wrote:
> Erm "the free handout pool is empty" != "dead". I'd suggest that
> IPv4 will be with us for decades.

Sure. In some "carrier-grade" NAT reduced capacity. The crossover from
ipv4 to 6 is probably going to suck way more than it has in the past.

[Patrick Haller]

On 2013-04-12 13:58, Scott Robinson wrote:
> http://internetcensus2012.bitbucket.org/paper.html

Most of reality is empty space. Doesn't mean you can use it for some
other purpose, though. ;)

[Roland Turner]

On 12/04/2013 14:10, Patrick Haller wrote:

On 2013-04-12 13:53, Roland Turner wrote:

Erm "the free handout pool is empty" != "dead". I'd suggest that
IPv4 will be with us for decades.

Sure. In some "carrier-grade" NAT reduced capacity.

Not at all. The grand technical pipe-dream, for two decades, has been that several million organisations will be inspired to discard their existing, working investments and rush to replace IPv4 with IPv6. Not only is this pretty obviously crazy, the available evidence makes pretty clear that it's not going to happen any time soon, and possibly not within our lifetimes. What's happening instead is that hosting providers are increasingly making all of their servers reachable via both protocols while access providers are stretching their IPv4 as far as possible if that suffices (in most cases it does) or switching to IPv6+CGN if they can't (generally only true in high-growth environments).

For at least a decade or two (think: telco investment cycles) and possibly a great deal longer, the majority of Internet access circuits will use IPv4. The majority of access circuits in high-growth environments will use IPv6 of course, but this does not describe most of the world.

 The crossover from
ipv4 to 6 is probably going to suck way more than it has in the past.

There will be a growing amount of suck, yes.

- Roland

[Patrick Haller]

> There will be a growing amount of suck, yes.

So how to minimize the pain?

[Meng Weng Wong]

On 12 Apr, 2013, at 2:46 PM, Patrick Haller <patrick...@gmail.com> wrote:

>> There will be a growing amount of suck, yes.
>
> So how to minimize the pain?

http://www.amazon.com/Diffusion-Innovations-5th-ebook/dp/B000FC0NH8/

http://blogs.hbr.org/cs/2013/01/three_elements_of_a_successful_platform.html

What's the killer app for IPv6 – what can it do that IPv4 can't?

[Patrick Haller]

On 2013-04-12 14:56, Meng Weng Wong wrote:
> http://www.amazon.com/Diffusion-Innovations-5th-ebook/dp/B000FC0NH8/
> http://blogs.hbr.org/cs/2013/01/three_elements_of_a_successful_platform.html

> What's the killer app for IPv6 ? what can it do that IPv4 can't?

Wrong evaluation metric. The internet's a community/ecosystem and IPv4
is pollution. Yes, we can all continue to drive cars and to use coal to
generate electricity, but it hurts us all and is wrong to do when
alternatives exist.

There will always be people who say "the alternatives are too costly for
me." It's just that we should work hard to not be one of those people.

[Roland Turner]

On 12/04/2013 14:56, Meng Weng Wong wrote:

> What's the killer app for IPv6 – what can it do that IPv4 can't?

The only serious one currently known is the provision to content
providers of IPv4-equivalent location/tracking/etc. for users stuck
behind CGN. When they are behind 4:4 CGN, nothing can be done, but when
they are behind 6:4 CGN the content provider can offer the access
provider IPv6-peering for mutual benefit (finer-grained data for the
content provider, reduced CGN cost for the access provider). This is in
effect what Google IPv6 programme ("creating a mechanical chicken") is
about.

The "obvious" answer (connecting new customers to the Internet when
insufficient public IPv4 space is available) actually isn't an answer to
the question because once an ISP is faced with the need to do CGN
anyway, 4:4 remains an actual option, at least from the ISP's
perspective. Of course, the hope is that the willingness of large
content providers to provide IPv6-peering to ISPs in this situation and
the corresponding drop in CGN cost will tend to tilt this decision
towards 6:4 more often than not.

- Roland

[Roland Turner]

On 12/04/2013 15:15, Patrick Haller wrote:

> Wrong evaluation metric. The internet's a community/ecosystem and IPv4
> is pollution. Yes, we can all continue to drive cars and to use coal to
> generate electricity, but it hurts us all and is wrong to do when
> alternatives exist.

It doesn't hurt us all, quite the contrary in fact.

For the incumbent telcos in most markets in which on-request-allocation
IPv4 address space exhaustion is most acute, the costs associated with
CGN are viewed as a great benefit - at least to them - because they
drive up the costs of business for challengers and thereby greatly
increase the likelihood that they'll be sufficiently distressed to need
"help" (acquisition by the incumbent at a steep discount) at some point
in the future.

> There will always be people who say "the alternatives are too costly for
> me." It's just that we should work hard to not be one of those people.

I'd suggest focussing instead on approaches that actually have some
likelihood of success, which is more or less what's behind the question
that Meng asked. Finding ways to make IPv6 a competitive weapon for -
rather than against - the ISPs who don't have enough IPv4 space is the
best way to do this.

- Roland

[Tay Ray Chuan]

On Thu, Apr 4, 2013 at 6:44 PM, Simon Males <si...@sime.net.au> wrote:
> For all day yesterday and today I've found interaction with Github really
> slow with cloning coming in at a rate of 10KiB/s.
>
> I'm on M1.
>
> Anyone else?
>
> $ time git clone g...@github.com:sinatra/sinatra.git
> Cloning into 'sinatra'...
> remote: Counting objects: 12976, done.
> remote: Compressing objects: 100% (5353/5353), done.
> remote: Total 12976 (delta 8026), reused 12305 (delta 7434)
> Receiving objects: 100% (12976/12976), 2.48 MiB | 11 KiB/s, done.
> Resolving deltas: 100% (8026/8026), done.

It looks like you are cloning a public repo. You could try public
https:// and git:// urls, they might be faster because they are sans
SSH protocol which has its own overhead.

--
Cheers,
Ray Chuan

[Martin Bähr]

On Fri, Apr 12, 2013 at 02:42:23PM +0800, Roland Turner wrote:
> > The crossover from
> >ipv4 to 6 is probably going to suck way more than it has in the past.
> There will be a growing amount of suck, yes.

incidently, just today someone complained about problems caused by ipv6.
(these are not transition problems however i think)

summarized from a story in german by Goesta Smekal on the list of the
linux user group austria:
"a year ago ipv6 hits were about 15%, this month they are already more
than 90%. many hits go to "/". interesting is that most hits are from
amazon netblocks with curl as useragent. those are unlikely to be
engaged vhost owners that like to use the commandline.
the problem with the large address space is that mod_evasive doesn't
help. there are to many."

greetings, martin.
--
eKita - the online platform for your entire academic life
--
chief engineer eKita.co
pike programmer caudium.net societyserver.org
foresight developer community.gotpike.org foresightlinux.org
unix sysadmin pike.lysator.liu.se realss.com
Martin B�hr working in china http://societyserver.org/mbaehr/

[Patrick Haller]

On 2013-04-12 16:48, Martin B?hr wrote:
> interesting is that most hits are from amazon netblocks with curl as useragent.

Yeah, you can pretty quickly scan ipv4-usable with AWS. Jared Mauch
recently did this looking for open DNS resolvers.

Not so tractable for ipv6, but maybe they're being smart about it. ;)