From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from ar.aichi-u.ac.jp ([202.250.160.40]) by ur; Sat Jun  4 17:36:08 EDT 2016
Received: from [192.168.0.249] ([115.36.102.252]) by ar; Sun Jun  5 06:35:56 JST 2016
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: [9front] State of the 9front mailing list archives
From: arisawa <arisawa@ar.aichi-u.ac.jp>
In-Reply-To: <a6c3ed64e027cc6c68c4fd9110616c5e@meiling.znet>
Date: Sun, 5 Jun 2016 06:35:30 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <92DCC772-99B8-4FF3-B435-195736BACD1B@ar.aichi-u.ac.jp>
References: <acc41739e9fdec695f36b5976275415b@felloff.net> <D6AA6E32-A60B-406F-90C6-0540DC844FC7@stanleylieber.com> <a6c3ed64e027cc6c68c4fd9110616c5e@meiling.znet>
To: 9front@9front.org
X-Mailer: Apple Mail (2.2104)
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: managed optimized standard pipelining cloud database-aware element enhancement 

Hello,

this is my case
term% time ls -l /n/lists/9fans >/tmp/foo
0.35u 0.08s 405.16r 	 ls -l /n/lists/9fans
term%=20

I have been considering this type of problems: large data in server.
grid computing might be the only solution.

Kenji Arisawa

> 2016/06/04 15:31=E3=80=81BurnZeZ@feline.systems =E3=81=AE=E3=83=A1=E3=83=
=BC=E3=83=AB=EF=BC=9A
>=20
>=20
> On Fri Jun  3 14:46:01 EDT 2016, sl@stanleylieber.com wrote:
>> In my previous mail I was responding more to the same discussion that =
gets held over and over on IRC by the same people about how accessing =
the mailing list archive is awkward and slow.
>=20
> That's expected with latency and any protocol that requires a lot of =
back and forth.
>=20
>=20
> meiling% 9fs 9front >[2]/dev/null
> meiling% time ls -l /n/9front/lists/9fans >/tmp/foo
> 0.90u 0.08s 120.38r 	 ls -l /n/9front/lists/9fans
> meiling% wc -l /tmp/foo
>  93845 /tmp/foo
> meiling% echo 93845 / 120.38 | hoc
> 779.573018774 # files per second
>=20
> meiling% ip/ping -n 5 9front.org
> sending 5 64 byte messages 1000 ms apart to icmp!9front.org!1
> 0: rtt 49053 =C2=B5s, avg rtt 49053 =C2=B5s, ttl =3D 245
> 1: rtt 47224 =C2=B5s, avg rtt 48138 =C2=B5s, ttl =3D 245
> 2: rtt 47660 =C2=B5s, avg rtt 47979 =C2=B5s, ttl =3D 245
> 3: rtt 47340 =C2=B5s, avg rtt 47819 =C2=B5s, ttl =3D 245
> 4: rtt 47084 =C2=B5s, avg rtt 47672 =C2=B5s, ttl =3D 245
> meiling% echo 120.38 / 0.04672 | hoc
> 2576.62671233 # number of possible round trips
> meiling% echo 93845 / 2576 | hoc
> 36.4305124224 # estimated files per round trip
>=20
> # /tmp/cache is an arbitrary directory I store some crap
> meiling% time ls -l /tmp/cache >/tmp/bar
> 0.07u 0.01s 0.09r 	 ls -l /tmp/cache
> meiling% wc -l /tmp/bar
>   6161 /tmp/bar
> meiling% echo 6161 / 0.09  | hoc
> 68455.5555556 # files per second, locally
>=20
>=20
> This assumes we send and receive messages, one at a time.
> It's better than I thought, but I suppose it doesn't scale well to
> directories with hundreds of thousands of files, or a higher
> latency link.
>=20
> What about increasing the speed of light?