From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Wed, 28 Apr 2010 10:03:44 -0400
To: 9fans@9fans.net
Message-ID: <235779203f52d9d4860147a935963068@kw.quanstro.net>
In-Reply-To: <77D22F21-3D8E-40F6-9813-E0ED32EFEAAB@fastmail.fm>
References: <5fa9fbfe115a9cd5a81d0feefe413192@quintile.net>
	<95FD9082-DC2A-44F9-BB4C-B221DB7A48FD@fastmail.fm>
	<146005b4714b9e85c63d294ec9aa60dc@kw.quanstro.net>
	<77D22F21-3D8E-40F6-9813-E0ED32EFEAAB@fastmail.fm>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] A simple experiment
Topicbox-Message-UUID: 10cd9fa8-ead6-11e9-9d60-3106f5b1d025

> Yeah, if I understand right that is what I meant. Good to know, but
> I'm back to the drawing board on why 9p is sometimes so very much
> slower than transferring the equivalent files in a tar file over http.

rtt.

> Maybe fcp should be used with a large number of threads? :s

the only limitation of the fcp approach is that it is built on a reliable
protocol, so it's impossible to control the number of inflight requests
based on missed packets.

perhaps the real key to a 9p2015 that solves this problem would be
building it on unreliable transport.

by the way, i was trying to generate aan numbers.  but fcp
just breaks aan.  aan is currently transferring about 10bytes/sec.

- erik