It seems this interesting patch:
http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00041.html
hasn't been applied to CVS for some reason.
Has it been accidentally skipped or is it not applicable to CVS?
Best regards.
Miguel.
_
Hi,
I have already made a patch. Try this.
http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00041.html
Regards,
Kazu
Sent: Wednesday, April 12, 2006 3:19 AM Helmut Auer wrote:
> Hello
>> In my case, the guest CPU is idle. The host CPU utilization is only 5
>> or 10 percent when runnin
I was confused by the comments around the delaying of acks. Delaying
these acks didn't make intuitive sense to me and is inconsistent with
RFC 2581, which states:
... a TCP receiver MUST NOT excessively delay
acknowledgments. Specifically, an ACK SHOULD be generated for at
least every s
Yes... I sent a follow-up note after I looked at the latest vl.c with a
newer patch applied. much simpler.
As for the delay acks, I've seen this and removed the delay for testing
before. I read in the comment (not sure if it was Fabrice or the slirp
author) about how the delay was 1 of 3 meth
Thanks, Leo. It appears your patch or something similar has made it
into 0.8.0. I have already merged the select loops, but it didn't
help as much as I hoped, maybe 10%. A much bigger improvement was
made by fixing the badly hacked slirp DELACK behavior. Believe it or
not, slirp delays all TCP
Hi Ken,
please disregard my last mail on this... here's a current patch against
today's CVS. I didn't realize that vl.c already converted from poll()
to select(), so the patch logic is much easier and cleaner.
Check it out... I tested it minimally and it seems to work - only tested
it on Li
Hi Ken,
I'm attaching a pretty old patch I made (from the 0.7.1 days), which did
a quick and dirty merge of the select's. It's not something that is
clean and it will need adapting to 0.8.0... but, I figure you could draw
some quick hints on how to merge the 2. Basically it fills the select
Hello
In my case, the guest CPU is idle. The host CPU utilization is only 5
or 10 percent when running "find / -print > /dev/null" on the guest.
So I don't think guest interrupt latency is the issue for me in this
case.
In my environment the performance of about 300 KB is the good case, tha
Paul, thanks for the note.
In my case, the guest CPU is idle. The host CPU utilization is only 5
or 10 percent when running "find / -print > /dev/null" on the guest.
So I don't think guest interrupt latency is the issue for me in this
case.
My first guess is that qemu is asleep when the NFS res
On Tuesday 11 April 2006 18:20, Kenneth Duda wrote:
> I am also having severe performance problems using NFS-over-TCP on
> qemu-0.8 with a Linux host and guest. I will be looking at this
> today. My current theory is that the whole machine is going idle
> before qemu decides to poll kernel ring b
I am also having severe performance problems using NFS-over-TCP on
qemu-0.8 with a Linux host and guest. I will be looking at this
today. My current theory is that the whole machine is going idle
before qemu decides to poll kernel ring buffers holding packets the
guest is transmitting, but if any
Hello,
I tried the cvs version from about a week ago with the latest kqemu driver, but
the network problem still exists. I am using:
qemu -net nic -net tap,ifname=my-tap
under Win2k with a Gentoo guest. The network throughput is about 20 MB ( per
Minute ! ).
When I use qemu 0.7.2 with the tap pa
Tuesday, March 07, 2006 6:44 AM Helmut Auer wrote:
> [EMAIL PROTECTED] schrieb:
>> Hello,
>> I just upgraded to qemu 0.8.0 including vlan/tap patch and I noticed that
the network speed is much slower than under 0.7.2 with tap patch ( 300KB/s
vs 1MB/s ).
>> Any hints what I can do to sped this up
[EMAIL PROTECTED] schrieb:
Hello,
I just upgraded to qemu 0.8.0 including vlan/tap patch and I noticed that the
network speed is much slower than under 0.7.2 with tap patch ( 300KB/s vs 1MB/s
).
Any hints what I can do to sped this up ?
Helmut
No ideas what can cause this ? I just checked it
Hello,
I just upgraded to qemu 0.8.0 including vlan/tap patch and I noticed that the
network speed is much slower than under 0.7.2 with tap patch ( 300KB/s vs 1MB/s
).
Any hints what I can do to sped this up ?
Helmut
___
Qemu-devel mailing list
Qe
Hello!
Did you find out why qemu's networking is so slow?
Is that a general issue or is it just happening when running qemu on
windows?
What has actually been changed in version 0.7.2? (The changelog says
that improvements were made in user-mode-networking)
I guess the best way is to understand
Jonas Maebe wrote:
On 26 aug 2005, at 15:57, [EMAIL PROTECTED] wrote:
QEMU is working better from hour to hour :-)
Now I am looking for a way to get my data from the linux client to
the Win2K host. When I use the integrated smb I get a transfer rate
from about 15 KB :-(
the tftp is about
[EMAIL PROTECTED] wrote:
Hi, QEMU is working better from hour to hour :-) Now I am looking for
a way to get my data from the linux client to the Win2K host. When I
use the integrated smb I get a transfer rate from about 15 KB :-( the
tftp is about 600 KBps and using WinSCP over the "redired" ssh
you can only open dos/fat32 partitions on raw images.
I usually keep one partition dos available for my linux guests,
so I can easily exchange data offline using this dos partition.
On 8/26/05, Helmut Auer <[EMAIL PROTECTED]> wrote:
> Hi Christian,
>
> >winimage.
> >There's also the possibility
Hi Christian,
winimage.
There's also the possibility to mount the img as a volume.
But there's a catch: both qemu and winimage want the
exclusivity of the image file. :(
I already tried WinImage ( V6 and v7 ). Both are telling me: Unable to
open ...
Which foramt should I use for the disk ?
winimage.
There's also the possibility to mount the img as a volume.
But there's a catch: both qemu and winimage want the
exclusivity of the image file. :(
On 8/26/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hi,
> QEMU is working better from hour to hour :-)
> Now I am looking for a way to
On 26 aug 2005, at 15:57, [EMAIL PROTECTED] wrote:
QEMU is working better from hour to hour :-)
Now I am looking for a way to get my data from the linux client to
the Win2K host. When I use the integrated smb I get a transfer rate
from about 15 KB :-(
the tftp is about 600 KBps and using Wi
Hi,
QEMU is working better from hour to hour :-)
Now I am looking for a way to get my data from the linux client to the Win2K
host. When I use the integrated smb I get a transfer rate from about 15 KB :-(
the tftp is about 600 KBps and using WinSCP over the "redired" ssh connection
lead to 60 KBp
23 matches
Mail list logo
