From: Brendan S. <Br...@Br...> - 2007-04-22 10:50:04
|
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. |
From: Sam M. <pa...@gm...> - 2007-04-22 11:01:45
|
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 <Br...@br...> 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 > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-users > |
From: Brendan S. <Br...@Br...> - 2007-04-22 13:09:25
|
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 <Br...@br...> 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 >> coL...@li... >> https://lists.sourceforge.net/lists/listinfo/colinux-users >> |
From: Sam M. <pa...@gm...> - 2007-04-22 15:23:27
|
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 <Br...@br...> 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 <Br...@br...> 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 > >> coL...@li... > >> https://lists.sourceforge.net/lists/listinfo/colinux-users > >> > > |
From: Holger K. <hol...@gm...> - 2007-04-22 18:10:22
|
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. |
From: George P B. <geo...@gm...> - 2007-04-23 17:30:22
|
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 |
From: Brendan S. <Br...@Br...> - 2007-04-24 00:16:50
|
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. > |
From: <ka...@gm...> - 2007-04-24 15:09:15
|
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 <gm...@cm...> 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 |
From: <ka...@gm...> - 2007-04-25 15:39:52
|
En 24/04/2007 17:58:11, Holger Krull <hol...@gm...> 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? |
From: Holger K. <hol...@gm...> - 2007-04-25 16:14:52
|
Joaquín Seijó schrieb: > En 24/04/2007 17:58:11, Holger Krull <hol...@gm...> 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. |
From: Michael L. <gm...@cm...> - 2007-04-22 16:32:06
|
Brendan Simon <Br...@Br...> 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 |
From: Mark W. <mar...@gm...> - 2007-04-22 20:19:34
|
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 <Br...@br...> 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 > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-users > |
From: Brendan S. <Br...@Br...> - 2007-04-24 04:58:43
|
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. > |
From: Brendan S. <Br...@Br...> - 2007-04-24 05:37:45
|
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. >> > > |
From: Mark W. <mar...@gm...> - 2007-04-24 13:37:42
|
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 <Br...@br...> 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 > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-users > |
From: <ka...@gm...> - 2007-04-24 13:57:09
|
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 <mar...@gm...> 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 <Br...@br...> 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 >> coL...@li... >> 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 > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-users |
From: Michael L. <gm...@cm...> - 2007-04-24 14:33:07
|
Joaquín Seijó <ka...@gm...> 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 |
From: Holger K. <hol...@gm...> - 2007-04-24 20:58:24
|
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. |
From: <ka...@gm...> - 2007-04-25 15:21:39
|
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 <jul...@gm...> escribió: > Hi > > 2007/4/24, Joaquín Seijó <ka...@gm...>: >> 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 |