On Wed, Feb 10, 2010 at 7:54 PM, Venkatesh Srinivas wrote:
> Perhaps the time to talk about QTDECENT is at hand?
>
I feel like it is Groundhog Day lately when I read the list.
--
- curiosity sKilled the cat
Perhaps the time to talk about QTDECENT is at hand?
-- vs
> The problem is that Linux doesn't know we got all the attribute
> information with the dirread, and then goes and individually queries
> each file in the directory with a stat -- this happens in a serial
> fashion, so the high latency to sources just makes the problem worse.
I have had similar
On Feb 10, 2010, at 7:32 AM, Pavel Klinkovsky wrote:
>> 1) real plan9 to the same place
>> 2) qemu plan9 on Fedora to the same place
> As I wrote above, I made exactly the same test on exactly the same HW
> (and internet connection).
> 1. Native Plan9.
> 2. Native Fedora 10 with p9p.
>
>> "It's
On Jan 9, 10:13Â pm, n...@lsub.org (Francisco J Ballesteros) wrote:
> Just to confirm what Geoff said.
>
> Parallels 5 works like a charm with Plan 9.
> Also, it seems to have full ACPI support, not that this is
> important for Plan 9 yet.
Hi Francisco,
You told that Plan9 works fine on Parallels
> For what it's worth, the following is my Xen config:
> kernel = "/home/kvanals/plan9/9xeninst-pae.gz"
> memory = 32
32MB might be a bit tight - try 64.
> cpu0: spurious interrupt 102, last 0
You can stop these messages after a crash by adding *debug=1 to the
plan9.ini section of your config fi
> Also - which file server are you using?
As I wrote above I tested it with 'sources.cs.bell-labs.com'.
Pavel
> 1) real plan9 to the same place
> 2) qemu plan9 on Fedora to the same place
As I wrote above, I made exactly the same test on exactly the same HW
(and internet connection).
1. Native Plan9.
2. Native Fedora 10 with p9p.
> "It's slow, what's wrong" is perhaps a little vague.
Not precisely measure
File operation bandwidth should be roughly equivilent once the file is
open - directory reads will have a large penalty under Linux
complicated by the latency of the connection.
-Eric
Sent from my iPhone
On Feb 10, 2010, at 11:57 AM, Pavel Klinkovsky > wrote:
Maybe yes, maybe no. Wh
so you're completely disk bound? if disk activity on the windows
box is also low, your venti machine must be suffering.
It took just over 8 hours to copy 2.2Gb of data from an idle system to a
mostly idle system. The network is 1gbit.
So it's not maxing out the disk, not maxing out the cpu
Also - which file server are you using?
Sent from my iPhone
On Feb 10, 2010, at 3:54 AM, Gorka Guardiola wrote:
Maybe yes, maybe no. What is the latency to your file server?.
http://lsub.org/ls/export/opiwp9.pdf
http://lsub.org/ls/export/opiwp9tlk.pdf
--
- curiosity sKilled the cat
Hi all,
I am trying 9pfuse (p9p) on my Linux (Fedora 10), and the access to
remote directories/files is extremly slow.
Do I make something wrong?
Thanks in advance.
Pavel
Two things you can test with :
1) real plan9 to the same place
2) qemu plan9 on Fedora to the same place
"It's slo
> Maybe yes, maybe no. What is the latency to your file server?
I tested it with 'sources.cs.bell-labs.com'.
My tests are performed on the same HW.
If I boot into the native Plan9, the access is fast enough.
If I boot into the Fedora 10, the access is extremly slow...
Pavel
Maybe yes, maybe no. What is the latency to your file server?.
http://lsub.org/ls/export/opiwp9.pdf
http://lsub.org/ls/export/opiwp9tlk.pdf
--
- curiosity sKilled the cat
Hi all,
I am trying 9pfuse (p9p) on my Linux (Fedora 10), and the access to
remote directories/files is extremly slow.
Do I make something wrong?
Thanks in advance.
Pavel
15 matches
Mail list logo
