Cooperative Linux

First of all ditch TightVNC, you're not going to get decent
performance out of that and I'd suggest moving to an X server. Not
only will it improve network items, it will improve over all
performance.

Xming is one I use that doesn't have too many issues. You can either
use XDMCP to connect in or use PuTTY with X forwarding. Again, you're
not going to get full native speeds from any GUI app as VNC has its
own repaint events (since it sends bitmaps) and Xming does a large
amount of context switches but network transfers are far more
efficient.

Sam

On 22/04/07, Brendan Simon <Brendan@...> wrote:
> I'm using coLinux and finding the GUI performance painfully slow.  I'd
> like to find some ways to improve the performance, particularly as
> coLinux supposed to execute at "native" speeds.
>
> My configuration is as follows:
>
>     * 0.8.0-devel-20070302 (2.6.17-co-0.8.0)
>     * mem=512
>     * kernel=vmlinux
>     * mem=512
>     * cofs0=c:\
>     * root=/dev/cobd0
>     * ro
>     * eth0=slirp,00:D0:1f:99:88:99,tcp:22:22/tcp:5901:5901
>
>     * Debian Etch distro installed on a real ext3 hard disk partition
>       (ie. not on windows file)
>     * TightVNC with depth 24 and running a gnome session.
>
>     * Laptop, Pentium M, 2GHz, 2GB RAM.
>
>
> Is there any way to speed things up?
> Is SLIRP just terribly slow?
> How much difference would changing the vnc depth to 16 or 8 make?  I'd
> like to avoid that if possible :)
>
> Thanks, Brendan.
>
>
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> coLinux-users mailing list
> coLinux-users@...
> https://lists.sourceforge.net/lists/listinfo/colinux-users
>

Thanks Sam.  I will take a look at Xming.

One of the things I really like about VNC is that if I loose network 
connectivity, I can reconnect and not loose my session.  X does not 
support this as it is session based (maybe things have changed?).  This 
may not be an issue if using SLIRP or other fixed network addresses ?  I 
did had this issue when using TAP and DHCP and getting different 
addresses when taking laptop to and from work.

But I still don't understand why coLinux or VNC is sooooo slow.  My 
understanding may be flawed?  Here is my thinking:

    If I have a second PC running Linux and a VNC server, and connect
    from a MSW box using a VNC server over a 100Mbps network, I get much
    much better performance than if I use MSW/Colinux.  I'd expect
    coLinux to get similar performance (or at least close).

    Assumption: given the two OSes are on the same machine I would
    expect network throughput would be better than two separate
    machines.  However, I think the using the network support
    (particulary slirp) in coLinux is as slow, if not slower, than a
    real network

    Maybe because both host OS and guess OS are so resource intensive
    that the performance hit is extremely noticeable.  If that is the
    case, then using any virtual OS would seem to useful only for
    playing and doing basic things.


Thanks, Brendan.


Sam Moffatt wrote:
> First of all ditch TightVNC, you're not going to get decent
> performance out of that and I'd suggest moving to an X server. Not
> only will it improve network items, it will improve over all
> performance.
>
> Xming is one I use that doesn't have too many issues. You can either
> use XDMCP to connect in or use PuTTY with X forwarding. Again, you're
> not going to get full native speeds from any GUI app as VNC has its
> own repaint events (since it sends bitmaps) and Xming does a large
> amount of context switches but network transfers are far more
> efficient.
>
> Sam
>
> On 22/04/07, Brendan Simon <Brendan@...> wrote:
>> I'm using coLinux and finding the GUI performance painfully slow.  I'd
>> like to find some ways to improve the performance, particularly as
>> coLinux supposed to execute at "native" speeds.
>>
>> My configuration is as follows:
>>
>>     * 0.8.0-devel-20070302 (2.6.17-co-0.8.0)
>>     * mem=512
>>     * kernel=vmlinux
>>     * mem=512
>>     * cofs0=c:\
>>     * root=/dev/cobd0
>>     * ro
>>     * eth0=slirp,00:D0:1f:99:88:99,tcp:22:22/tcp:5901:5901
>>
>>     * Debian Etch distro installed on a real ext3 hard disk partition
>>       (ie. not on windows file)
>>     * TightVNC with depth 24 and running a gnome session.
>>
>>     * Laptop, Pentium M, 2GHz, 2GB RAM.
>>
>>
>> Is there any way to speed things up?
>> Is SLIRP just terribly slow?
>> How much difference would changing the vnc depth to 16 or 8 make?  I'd
>> like to avoid that if possible :)
>>
>> Thanks, Brendan.
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------- 
>>
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> coLinux-users mailing list
>> coLinux-users@...
>> https://lists.sourceforge.net/lists/listinfo/colinux-users
>>

There is an X server implementation that does that but I'm not sure
how it would go performance wise, NXHost or something like that.  VNC
is handy like that but again you get a performance hit, but to a point
we expect that and its the trade off (since all your applications are
speaking X to VNC and then VNC translates this to bitmap and shunts it
over the network, speaking straight X cuts out the VNC layer).

wrt to network I/O there are some good threads historically about
makng coLinux shift the bytes faster, have to remember that even
though there is no real networking hardware involved you're still
creating and decoding a packet on the same box, so in a way you have
twice the CPU cost on top of the obvious cost in using virtual
interfaces (and the relevant context switches). The numbers really
start to add up quickly all over the place and a lot of it is
unfortunately unavoidable.

Sam

On 22/04/07, Brendan Simon <Brendan@...> wrote:
> Thanks Sam.  I will take a look at Xming.
>
> One of the things I really like about VNC is that if I loose network
> connectivity, I can reconnect and not loose my session.  X does not
> support this as it is session based (maybe things have changed?).  This
> may not be an issue if using SLIRP or other fixed network addresses ?  I
> did had this issue when using TAP and DHCP and getting different
> addresses when taking laptop to and from work.
>
> But I still don't understand why coLinux or VNC is sooooo slow.  My
> understanding may be flawed?  Here is my thinking:
>
>     If I have a second PC running Linux and a VNC server, and connect
>     from a MSW box using a VNC server over a 100Mbps network, I get much
>     much better performance than if I use MSW/Colinux.  I'd expect
>     coLinux to get similar performance (or at least close).
>
>     Assumption: given the two OSes are on the same machine I would
>     expect network throughput would be better than two separate
>     machines.  However, I think the using the network support
>     (particulary slirp) in coLinux is as slow, if not slower, than a
>     real network
>
>     Maybe because both host OS and guess OS are so resource intensive
>     that the performance hit is extremely noticeable.  If that is the
>     case, then using any virtual OS would seem to useful only for
>     playing and doing basic things.
>
>
> Thanks, Brendan.
>
>
> Sam Moffatt wrote:
> > First of all ditch TightVNC, you're not going to get decent
> > performance out of that and I'd suggest moving to an X server. Not
> > only will it improve network items, it will improve over all
> > performance.
> >
> > Xming is one I use that doesn't have too many issues. You can either
> > use XDMCP to connect in or use PuTTY with X forwarding. Again, you're
> > not going to get full native speeds from any GUI app as VNC has its
> > own repaint events (since it sends bitmaps) and Xming does a large
> > amount of context switches but network transfers are far more
> > efficient.
> >
> > Sam
> >
> > On 22/04/07, Brendan Simon <Brendan@...> wrote:
> >> I'm using coLinux and finding the GUI performance painfully slow.  I'd
> >> like to find some ways to improve the performance, particularly as
> >> coLinux supposed to execute at "native" speeds.
> >>
> >> My configuration is as follows:
> >>
> >>     * 0.8.0-devel-20070302 (2.6.17-co-0.8.0)
> >>     * mem=512
> >>     * kernel=vmlinux
> >>     * mem=512
> >>     * cofs0=c:\
> >>     * root=/dev/cobd0
> >>     * ro
> >>     * eth0=slirp,00:D0:1f:99:88:99,tcp:22:22/tcp:5901:5901
> >>
> >>     * Debian Etch distro installed on a real ext3 hard disk partition
> >>       (ie. not on windows file)
> >>     * TightVNC with depth 24 and running a gnome session.
> >>
> >>     * Laptop, Pentium M, 2GHz, 2GB RAM.
> >>
> >>
> >> Is there any way to speed things up?
> >> Is SLIRP just terribly slow?
> >> How much difference would changing the vnc depth to 16 or 8 make?  I'd
> >> like to avoid that if possible :)
> >>
> >> Thanks, Brendan.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> -------------------------------------------------------------------------
> >>
> >> This SF.net email is sponsored by DB2 Express
> >> Download DB2 Express C - the FREE version of DB2 express and take
> >> control of your XML. No limits. Just data. Click to get it now.
> >> http://sourceforge.net/powerbar/db2/
> >> _______________________________________________
> >> coLinux-users mailing list
> >> coLinux-users@...
> >> https://lists.sourceforge.net/lists/listinfo/colinux-users
> >>
>
>

Brendan Simon <Brendan@...>
writes:

> Is SLIRP just terribly slow?

slirp is just terribly slow, yes, and I don't think its speed can
really be improved.

if TAP works for you (it never did for me, but perhaps other people
are luckier?), by all means use that.  I'd hazard a guess that all the
slowness you perceive is down to the network overhead, at least as
long as you are not trying to play movies or something.

hth,
--m

Brendan Simon schrieb:
> 
> One of the things I really like about VNC is that if I loose network 
> connectivity, I can reconnect and not loose my session.  X does not 
> support this as it is session based (maybe things have changed?).  This 
> may not be an issue if using SLIRP or other fixed network addresses ?  I 
> did had this issue when using TAP and DHCP and getting different 
> addresses when taking laptop to and from work.
> 
> But I still don't understand why coLinux or VNC is sooooo slow.  My 
> understanding may be flawed?  Here is my thinking:

If you want to reconnect to a lost X Session use freenx. It keeps the
session and compresses the X11 protocol and reduces the amount of
exchanged packets between client and server. This is extremely useful
with the higher network latency on colinux.

VNC is slow as the X11 Server runs on colinux and the picture gets
transfered to windows as group of pixels. It helps to reduce amount of
possible colors but that is not really a solution. Just try Xming with
xdmcp on Windows to see the difference.

I've found VNC pathetically slow compared to X using Xming as a server
(on the Windows side). Using gentoo with the compiler optimizers
cranked up, I've been very happy with the performance of the 0.7.1,
although I've had an unresolved problem of intermittent blue screens
(with days to weeks inbetween).

On 4/22/07, Brendan Simon <Brendan@...> wrote:
> I'm using coLinux and finding the GUI performance painfully slow.  I'd
> like to find some ways to improve the performance, particularly as
> coLinux supposed to execute at "native" speeds.
>
> My configuration is as follows:
>
>     * 0.8.0-devel-20070302 (2.6.17-co-0.8.0)
>     * mem=512
>     * kernel=vmlinux
>     * mem=512
>     * cofs0=c:\
>     * root=/dev/cobd0
>     * ro
>     * eth0=slirp,00:D0:1f:99:88:99,tcp:22:22/tcp:5901:5901
>
>     * Debian Etch distro installed on a real ext3 hard disk partition
>       (ie. not on windows file)
>     * TightVNC with depth 24 and running a gnome session.
>
>     * Laptop, Pentium M, 2GHz, 2GB RAM.
>
>
> Is there any way to speed things up?
> Is SLIRP just terribly slow?
> How much difference would changing the vnc depth to 16 or 8 make?  I'd
> like to avoid that if possible :)
>
> Thanks, Brendan.
>
>
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> coLinux-users mailing list
> coLinux-users@...
> https://lists.sourceforge.net/lists/listinfo/colinux-users
>

Brendan Simon wrote:
> But I still don't understand why coLinux or VNC is sooooo slow.  My 
> understanding may be flawed?  Here is my thinking:
>
>     If I have a second PC running Linux and a VNC server, and connect
>     from a MSW box using a VNC server over a 100Mbps network, I get much
>     much better performance than if I use MSW/Colinux.  I'd expect
>     coLinux to get similar performance (or at least close).
>
>     Assumption: given the two OSes are on the same machine I would
>     expect network throughput would be better than two separate
>     machines.  However, I think the using the network support
>     (particulary slirp) in coLinux is as slow, if not slower, than a
>     real network
>
>     Maybe because both host OS and guess OS are so resource intensive
>     that the performance hit is extremely noticeable.  If that is the
>     case, then using any virtual OS would seem to useful only for
>     playing and doing basic things.
>
>   
  There are some scenarios, such as VNC and X usage where the throughput
of SLiRP and coLinux's Networking in general just aren't up to it.  This
is a known issue and believe it or not this has been improving.  The
speed of coLinux networking in 0.7.1 is way, way, way better than it was
in 0.6.x

  coLinux project is attacking the network performance issue as best we
can, with the tools and resources that we have.  As someone else pointed
out there have been some really good discussions in the past about
changes/tweaks, etc to default networking settings that done
carefully/correctly can drastically improve the performance (see the
archives for details)

  In addition to that we are addressing the VNC/X issue by working on an
experimental (at this time) virtual video device driver that would (in
theory) allow QEMU & VMWare like video for coLinux and which would
provide better performance than the current solutions which all involve
using the network to get video.

  Having said this, the easiest & fastest mechanism that we (several
core developers & core community members) have found to work for both
Internet & network-based X/VNC display is to use eth0=SliRP for Internet
and eth1=tap for X/VNC.  That is to say that SLiRP is used to allow an
virtually 0 configuration internet connection, even when switching
interfaces, moving around as is common with laptops.  While having a
static configuration with the TAP device for X/VNC.

HTH,

George

Thanks for the help George.  This sounds like the best solution 
currently available for X/VNC with laptops :)
Is there a wiki/faq entry on how to setup this scenario?

The virtual video device sounds very interesting and would bring coLinux 
up to par with K/QEMU with respect to GUI performance.  I've seen a 
colleague use QEMU and it looked great with the X display.  AFAICT, 
K/QEMU does not require a special kernel where as coLinux requires a 
special coLinux built kernel, so I presume coLinux is slightly faster 
than K/QEMU otherwise there would be no point, right ????

Cheers, Brendan.


George P Boutwell wrote:
> Brendan Simon wrote:
>   
>   There are some scenarios, such as VNC and X usage where the throughput
> of SLiRP and coLinux's Networking in general just aren't up to it.  This
> is a known issue and believe it or not this has been improving.  The
> speed of coLinux networking in 0.7.1 is way, way, way better than it was
> in 0.6.x
>
>   coLinux project is attacking the network performance issue as best we
> can, with the tools and resources that we have.  As someone else pointed
> out there have been some really good discussions in the past about
> changes/tweaks, etc to default networking settings that done
> carefully/correctly can drastically improve the performance (see the
> archives for details)
>
>   In addition to that we are addressing the VNC/X issue by working on an
> experimental (at this time) virtual video device driver that would (in
> theory) allow QEMU & VMWare like video for coLinux and which would
> provide better performance than the current solutions which all involve
> using the network to get video.
>
>   Having said this, the easiest & fastest mechanism that we (several
> core developers & core community members) have found to work for both
> Internet & network-based X/VNC display is to use eth0=SliRP for Internet
> and eth1=tap for X/VNC.  That is to say that SLiRP is used to allow an
> virtually 0 configuration internet connection, even when switching
> interfaces, moving around as is common with laptops.  While having a
> static configuration with the TAP device for X/VNC.
>

I will have a go at the dual slirp/tap solution.

I tried Xming with slirp and things like xeyes and xcalc seem to work 
very well indeed, however, my GNOME session took forever to fire up.  I 
mean a very very long time.  I couldn't believe it to tell you the 
truth.  VNC was much faster.  All I can think of is that the X protocol 
is not very efficient for things like GNOME and it ends up being better 
to use VNC (over slow network connections such as SLIRP).

I suspect TAP will be much better and hopefully that will make GNOME 
more usable :)

Cheers, Brendan.


George P Boutwell wrote:
> Brendan Simon wrote:
>   
>> But I still don't understand why coLinux or VNC is sooooo slow.
> Having said this, the easiest & fastest mechanism that we (several
> core developers & core community members) have found to work for both
> Internet & network-based X/VNC display is to use eth0=SliRP for Internet
> and eth1=tap for X/VNC.  That is to say that SLiRP is used to allow an
> virtually 0 configuration internet connection, even when switching
> interfaces, moving around as is common with laptops.  While having a
> static configuration with the TAP device for X/VNC.
>

Found the setup on the wiki :)
    
http://colinux.wikia.com/wiki/UserConfigs#Networking_with_SLIRP_.28for_Internet.29_and_TAP_.28for_X_server.29

I can confirm that this works a million times (approximately) better 
than slirp.  This was with Xming/XDMCP.  I suspect VNC over TAP will be 
pretty good too.

My next step was to try out K/QEMU but now I can put that on hold unless 
something else comes up ;-)  USB ???

Thanks, Brendan.


Brendan Simon wrote:
> I will have a go at the dual slirp/tap solution.
>
> I tried Xming with slirp and things like xeyes and xcalc seem to work 
> very well indeed, however, my GNOME session took forever to fire up.  
> I mean a very very long time.  I couldn't believe it to tell you the 
> truth.  VNC was much faster.  All I can think of is that the X 
> protocol is not very efficient for things like GNOME and it ends up 
> being better to use VNC (over slow network connections such as SLIRP).
>
> I suspect TAP will be much better and hopefully that will make GNOME 
> more usable :)
>
> Cheers, Brendan.
>
>
> George P Boutwell wrote:
>> Brendan Simon wrote:
>>  
>>> But I still don't understand why coLinux or VNC is sooooo slow.
>> Having said this, the easiest & fastest mechanism that we (several
>> core developers & core community members) have found to work for both
>> Internet & network-based X/VNC display is to use eth0=SliRP for Internet
>> and eth1=tap for X/VNC.  That is to say that SLiRP is used to allow an
>> virtually 0 configuration internet connection, even when switching
>> interfaces, moving around as is common with laptops.  While having a
>> static configuration with the TAP device for X/VNC.
>>   
>
>

Another vote for Tap. I've never used Slirp; perhaps that's why I
didn't have the problems with Cygwin/X and Xming.

On 4/24/07, Brendan Simon <Brendan@...> wrote:
> I will have a go at the dual slirp/tap solution.
>
> I tried Xming with slirp and things like xeyes and xcalc seem to work
> very well indeed, however, my GNOME session took forever to fire up.  I
> mean a very very long time.  I couldn't believe it to tell you the
> truth.  VNC was much faster.  All I can think of is that the X protocol
> is not very efficient for things like GNOME and it ends up being better
> to use VNC (over slow network connections such as SLIRP).
>
> I suspect TAP will be much better and hopefully that will make GNOME
> more usable :)
>
> Cheers, Brendan.
>
>
> George P Boutwell wrote:
> > Brendan Simon wrote:
> >
> >> But I still don't understand why coLinux or VNC is sooooo slow.
> > Having said this, the easiest & fastest mechanism that we (several
> > core developers & core community members) have found to work for both
> > Internet & network-based X/VNC display is to use eth0=SliRP for Internet
> > and eth1=tap for X/VNC.  That is to say that SLiRP is used to allow an
> > virtually 0 configuration internet connection, even when switching
> > interfaces, moving around as is common with laptops.  While having a
> > static configuration with the TAP device for X/VNC.
> >
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> coLinux-users mailing list
> coLinux-users@...
> https://lists.sourceforge.net/lists/listinfo/colinux-users
>

Another vote here! i use three taps: one for SAMBA, one for X and one for  
ESD (will try later with its sucessor, pulseaudio) and it works perfectly,  
have tried once with VNC over tap but it didn't compared IMO with X. Also  
is worth to mention again the NX platform, which i haven't tried but  
should make things even faster.
With this setup i can have (after KDM login) the KDE kicker on one side of  
the screen and the windows taskbar on the other, watch videos w/o glitches  
and redirect the sound to the windows host or to another machine that has  
its sound output to an amplifier to have the movies with surround sound.
Try giving all colinux/X/ESD daemons ABOVE NORMAL priority! that helps too

Joaquín

En 24/04/2007 10:37:41, Mark Woodruff <markgwoodruff@...> escribió:

> Another vote for Tap. I've never used Slirp; perhaps that's why I
> didn't have the problems with Cygwin/X and Xming.
>
> On 4/24/07, Brendan Simon <Brendan@...> wrote:
>> I will have a go at the dual slirp/tap solution.
>>
>> I tried Xming with slirp and things like xeyes and xcalc seem to work
>> very well indeed, however, my GNOME session took forever to fire up.  I
>> mean a very very long time.  I couldn't believe it to tell you the
>> truth.  VNC was much faster.  All I can think of is that the X protocol
>> is not very efficient for things like GNOME and it ends up being better
>> to use VNC (over slow network connections such as SLIRP).
>>
>> I suspect TAP will be much better and hopefully that will make GNOME
>> more usable :)
>>
>> Cheers, Brendan.
>>
>>
>> George P Boutwell wrote:
>> > Brendan Simon wrote:
>> >
>> >> But I still don't understand why coLinux or VNC is sooooo slow.
>> > Having said this, the easiest & fastest mechanism that we (several
>> > core developers & core community members) have found to work for both
>> > Internet & network-based X/VNC display is to use eth0=SliRP for  
>> Internet
>> > and eth1=tap for X/VNC.  That is to say that SLiRP is used to allow an
>> > virtually 0 configuration internet connection, even when switching
>> > interfaces, moving around as is common with laptops.  While having a
>> > static configuration with the TAP device for X/VNC.
>> >
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> coLinux-users mailing list
>> coLinux-users@...
>> https://lists.sourceforge.net/lists/listinfo/colinux-users
>>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> coLinux-users mailing list
> coLinux-users@...
> https://lists.sourceforge.net/lists/listinfo/colinux-users

Joaquín Seijó <kankito@...>
writes:

> i use three taps: one for SAMBA, one for X and one for  
> ESD.

what does this buy you compared to running all those over one TAP
device?

just curious,
--m

It's easier to set MTUs and other custom parameters for each app when they  
have a dedicated tap, plus (don't know this is true however, if tap  
behaves exactly like a 10Mbps ethernet then it is) it avoids the  
possibility of running out of bandwith. I think the downside is that it  
takes a few more cpu cycles though

Finally, it's a clearer setup for me, and i just like it :D, but i have to  
make better tests yet

J

On 24/04/2007 11:11:44, Michael Livshin <gmane@...> wrote:
>> i use three taps: one for SAMBA, one for X and one for
>> ESD.
>
> what does this buy you compared to running all those over one TAP
> device?
>
> just curious,
> --m

Joaquín Seijó schrieb:
> It's easier to set MTUs and other custom parameters for each app when they  
> have a dedicated tap, plus (don't know this is true however, if tap  
> behaves exactly like a 10Mbps ethernet then it is) it avoids the  

That 10Mps is just a label. In reality the interface is faster.

The machine is a Pentium 4 2.66. The host is XP SP2 and i use  
Topologilinux in colinux mode (i think it's colinux 6, i don't remember  
exactly). Topologilinux 6 is based on Slackware 10.1 so it uses x.org and  
kde from that release.

Windows setup:

The real ethernet is 192.168.1.1 - it is bridged wih pcap
The taps are on different subnets, as follows:
#1 -	"SMB"	- 192.168.2.1
#2 -	"X"	- 192.168.3.1
#3 -	"ESD"	- 192.168.4.1

they are passed to colinux in the same order

Their counterparts in colinux are:
eth0: 192.168.1.2
eth1: 192.168.2.2
eth2: 192.168.3.2
eth3: 192.168.4.2

X server is Hummingbird Exceed (last version with GLX extensions so you  
can do OpenGL, it looks quite good), and i have Cygwin ESD, but i don't  
use it for now as this machine hasn't got its sound output connected. So i  
use another machine (192.168.2.3) as the esd output. For some reason i  
couldn't get Cygwin ESD to work over the ethernet so i had to use JEsd  
(http://www.jcraft.com/jesd/) there.

Linux setup:

SAMBA shares a 300G, XFS formatted hdd as the data store (this is why i  
started using colinux - i couldn't access my data from windows before  
that). One share for the TAP #1 with rw perms, and one share for the LAN  
(192.168.1.xxx) with ro perms.

As for X and esd, the variables DISPLAY and ESPEAKER are set accordingly.

Default runlevel is 4. I use KDM for login.

For playback: xmms / Xine.

The end result is each application having its own adapter for  
communication. To switch the linux esd output between the host and the  
remote machine i export ESPEAKER=espeaker and have a sed-based script  
changing the IP in /etc/hosts. This is better than changing an exported  
variable as you don't need to relogin for it to have effect.

I'm playing with different MTUs and other network parameters now to see  
what is best for each application, but this is a slow job and still don't  
have definitive results. But for the daily work it's all good! I can use  
all the adapters at once and AFAICT it haves very decent performance (yes  
with video, sound and file transfers).

Hope it helps, if you need more details ask me. I'm at work now and this  
is all i can remember from here, for more i'll have to check my system up,  
and tell you what switches i use for each app exactly.

Joaquín


En 25/04/2007 05:18:06, Julien Langlois <julien.langlois@...>  
escribió:

> Hi
>
> 2007/4/24, Joaquín Seijó <kankito@...>:
>> With this setup i can have (after KDM login) the KDE kicker on one side  
>> of
>> the screen and the windows taskbar on the other, watch videos w/o  
>> glitches
>> and redirect the sound to the windows host or to another machine that  
>> has
>> its sound output to an amplifier to have the movies with surround sound.
>
> Could you detail your configuration please ? I've latency sound
> problem .... I can't listen sound without 2 seconds latency ... And
> the video render don't allow me to watch video correctly :(
>
> Thanks
>
>    Julien Langlois

En 24/04/2007 17:58:11, Holger Krull <holger.krull@...> escribió:

>> It's easier to set MTUs and other custom parameters for each app when  
>> they
>> have a dedicated tap, plus (don't know this is true however, if tap
>> behaves exactly like a 10Mbps ethernet then it is) it avoids the
>
> That 10Mps is just a label. In reality the interface is faster.

I still had better results with this setup, but as i said i'm just  
starting to research and test, i even don't know of the internals of the  
tap interface so i can't argue here on which choice is better.

How much faster is the interface in reality?

Joaquín Seijó schrieb:
> En 24/04/2007 17:58:11, Holger Krull <holger.krull@...> escribió:
> 
>>> It's easier to set MTUs and other custom parameters for each app when  
>>> they
>>> have a dedicated tap, plus (don't know this is true however, if tap
>>> behaves exactly like a 10Mbps ethernet then it is) it avoids the
>> That 10Mps is just a label. In reality the interface is faster.
> 
> I still had better results with this setup, but as i said i'm just  
> starting to research and test, i even don't know of the internals of the  
> tap interface so i can't argue here on which choice is better.
> 
> How much faster is the interface in reality?

I assume the speed of the virtual network only depends on the speed of
the cpu. I never tested pure virtual speed, only when bridged with a
ethernet card. On a Gigabit card from realtek the transfer speed to
another computer was about 20 MByte per second (measured with netio,
both cpus 2 GHz Athlon XP).
I expect the speed to the windows host without bridging to be higher.