From: gboutwel <gbo...@pr...> - 2004-08-14 23:57:03
|
> I am using colinux 0.6.1 over kernel 2.4.26. The original distribution = Only advice I can give is to try the more recent snapshots. Especially the 20040710 snapshot. It will involve and upgrade to an 2.6 kernel and all that that may entail for the distro of your your choice. It probalby take rebulding the kernel with NFS settings, but it might not. But network performance has been something that has been worked and has gotten comments about it betting better in recent snapshots. > If somebody has an idea why the NFS service is so slow, please, do not = > hesitate to contact me. If after trying the recent snapshots, you still have problems we can perhaps look at them to see fi there is more we can do. Additionally, If you find that we could enable something more in the kernels for recent snapshots to make NFS support better, let us know. George ---------------------------- Love to laugh? Good Clean Jokes at Praize http://www.praize.com/jokes/ |
From: Claude L. (QB/EMC) <cla...@er...> - 2004-08-16 22:56:28
|
Hi George, Thanks for your reply. I will give a try to the new release as soon as = possible. However, I have made some NFS troubleshooting and I have finally been = able to go a bit further with the jumpstart and I have been able to = narrow down the problem. The NFS performance problem seems to be = produced by the IP fragmentation. The default NFS block size on Linux is set to 4096 bytes (4K). When I = set the rootopts value to 1024, the jumpstart process goes a lot = better. This parameter set the rsize (read block size) option of the = NFS mount request of the root filesystem coming from the jumpstart = client. Unfortunately, all the other NFS mounted filesystems are not = using this parameter and suffer from the fragmentation problem. So, the = jumpstart fails later. Basically, there is no fragmentation at 1024 but, at 4096, the = fragmentation is very important. To verify that the fragmentation is = responsible of the bad NFS performance, I have tested ping of 4K to a = remote system from colinux: PING 142.133.81.2 (142.133.81.2) 4096(4124) bytes of data. 4104 bytes from 142.133.81.2: icmp_seq=3D9 ttl=3D255 time=3D82.4 ms 4104 bytes from 142.133.81.2: icmp_seq=3D14 ttl=3D255 time=3D4.17 ms 4104 bytes from 142.133.81.2: icmp_seq=3D22 ttl=3D255 time=3D4.04 ms 4104 bytes from 142.133.81.2: icmp_seq=3D24 ttl=3D255 time=3D5.05 ms 4104 bytes from 142.133.81.2: icmp_seq=3D25 ttl=3D255 time=3D4.15 ms 4104 bytes from 142.133.81.2: icmp_seq=3D32 ttl=3D255 time=3D21.0 ms 4104 bytes from 142.133.81.2: icmp_seq=3D34 ttl=3D255 time=3D4.16 ms 4104 bytes from 142.133.81.2: icmp_seq=3D78 ttl=3D255 time=3D4.17 ms --- 142.133.81.2 ping statistics --- 121 packets transmitted, 8 received, 93% packet loss, time 120805ms rtt min/avg/max/mdev =3D 4.048/16.165/82.463/25.656 ms, pipe 2 The ping test shows the 93% of packet drops... It looks like the = colinux network adapter suffers from an IP fragmentation/reassembly = performance problem. Please, can you try the same ping on a later colinux version (ping -s = 4096 <remote_ip_address>) if you have time and if you can ? So, we = could already know if this problem is addressed with the new releases. Thanks, Claude LeFran=E7ois=20 cla...@er... -----Original Message----- From: col...@li... [mailto:col...@li...]On Behalf Of gboutwel Sent: Saturday, August 14, 2004 7:57 PM To: col...@li... Subject: Re: [coLinux-users] NFS performance and colinux > I am using colinux 0.6.1 over kernel 2.4.26. The original = distribution =3D Only advice I can give is to try the more recent snapshots.=20 Especially the 20040710 snapshot. It will involve and upgrade to an 2.6 kernel and all that that may entail for the distro of your your choice. It probalby take rebulding the kernel with NFS settings, but it might not. But network performance has been something that has been worked and has gotten comments about it betting better in recent snapshots. > If somebody has an idea why the NFS service is so slow, please, do not =3D > hesitate to contact me. If after trying the recent snapshots, you still have problems we can perhaps look at them to see fi there is more we can do. Additionally, If you find that we could enable something more in the kernels for recent snapshots to make NFS support better, let us know. George |
From: Nuno L. <lu...@nl...> - 2004-08-16 23:48:04
|
192.168.1.1 is my router in the internal network, not the host OS. colinux root # ping -s 4096 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 4096(4124) bytes of data. 4104 bytes from 192.168.1.1: icmp_seq=3D1 ttl=3D64 time=3D4.50 ms 4104 bytes from 192.168.1.1: icmp_seq=3D2 ttl=3D64 time=3D3.53 ms 4104 bytes from 192.168.1.1: icmp_seq=3D3 ttl=3D64 time=3D3.48 ms 4104 bytes from 192.168.1.1: icmp_seq=3D4 ttl=3D64 time=3D4.11 ms 4104 bytes from 192.168.1.1: icmp_seq=3D5 ttl=3D64 time=3D3.61 ms 4104 bytes from 192.168.1.1: icmp_seq=3D6 ttl=3D64 time=3D3.33 ms 4104 bytes from 192.168.1.1: icmp_seq=3D7 ttl=3D64 time=3D3.72 ms 4104 bytes from 192.168.1.1: icmp_seq=3D8 ttl=3D64 time=3D3.44 ms 4104 bytes from 192.168.1.1: icmp_seq=3D9 ttl=3D64 time=3D3.36 ms 4104 bytes from 192.168.1.1: icmp_seq=3D10 ttl=3D64 time=3D3.63 ms [....] --- 192.168.1.1 ping statistics --- 120 packets transmitted, 120 received, 0% packet loss, time 120280ms rtt min/avg/max/mdev =3D 3.280/3.761/9.236/0.951 ms And a really remote host: colinux root # ping -s 4096 www.colinux.org PING www.colinux.org (66.35.250.210) 4096(4124) bytes of data. 4104 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=3D1 ttl=3D= 45=20 time=3D599 ms 4104 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=3D2 ttl=3D= 45=20 time=3D595 ms 4104 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=3D3 ttl=3D= 45=20 time=3D595 ms 4104 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=3D4 ttl=3D= 45=20 time=3D594 ms 4104 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=3D5 ttl=3D= 45=20 time=3D596 ms 4104 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=3D6 ttl=3D= 45=20 time=3D595 ms 4104 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=3D7 ttl=3D= 45=20 time=3D595 ms 4104 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=3D8 ttl=3D= 45=20 time=3D595 ms 4104 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=3D9 ttl=3D= 45=20 time=3D625 ms 4104 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=3D10=20 ttl=3D45 time=3D597 ms [....] --- www.colinux.org ping statistics --- 31 packets transmitted, 30 received, 3% packet loss, time 30386ms rtt min/avg/max/mdev =3D 593.580/598.933/654.012/11.610 ms I used a special build using the latest source, on a 2.6.8.1 kernel. colinux root # uname -a Linux colinux 2.6.8.1-co-0.6.2 #1 Sun Aug 15 04:33:48 WEST 2004 i686=20 Intel(R) Pentium(R) 4 CPU 1.70GHz GenuineIntel GNU/Linux Regards, ~Nuno Lucas Claude LeFrancois (QB/EMC), dando pulos de alegria, escreveu : > Hi George, >=20 > Thanks for your reply. I will give a try to the new release as soon as = possible. >=20 > However, I have made some NFS troubleshooting and I have finally been a= ble to go a bit further with the jumpstart and I have been able to narrow= down the problem. The NFS performance problem seems to be produced by th= e IP fragmentation. >=20 > The default NFS block size on Linux is set to 4096 bytes (4K). When I s= et the rootopts value to 1024, the jumpstart process goes a lot better. T= his parameter set the rsize (read block size) option of the NFS mount req= uest of the root filesystem coming from the jumpstart client. Unfortunate= ly, all the other NFS mounted filesystems are not using this parameter an= d suffer from the fragmentation problem. So, the jumpstart fails later. >=20 > Basically, there is no fragmentation at 1024 but, at 4096, the fragment= ation is very important. To verify that the fragmentation is responsible = of the bad NFS performance, I have tested ping of 4K to a remote system f= rom colinux: >=20 > PING 142.133.81.2 (142.133.81.2) 4096(4124) bytes of data. > 4104 bytes from 142.133.81.2: icmp_seq=3D9 ttl=3D255 time=3D82.4 ms > 4104 bytes from 142.133.81.2: icmp_seq=3D14 ttl=3D255 time=3D4.17 ms > 4104 bytes from 142.133.81.2: icmp_seq=3D22 ttl=3D255 time=3D4.04 ms > 4104 bytes from 142.133.81.2: icmp_seq=3D24 ttl=3D255 time=3D5.05 ms > 4104 bytes from 142.133.81.2: icmp_seq=3D25 ttl=3D255 time=3D4.15 ms > 4104 bytes from 142.133.81.2: icmp_seq=3D32 ttl=3D255 time=3D21.0 ms > 4104 bytes from 142.133.81.2: icmp_seq=3D34 ttl=3D255 time=3D4.16 ms > 4104 bytes from 142.133.81.2: icmp_seq=3D78 ttl=3D255 time=3D4.17 ms >=20 > --- 142.133.81.2 ping statistics --- > 121 packets transmitted, 8 received, 93% packet loss, time 120805ms > rtt min/avg/max/mdev =3D 4.048/16.165/82.463/25.656 ms, pipe 2 >=20 > The ping test shows the 93% of packet drops... It looks like the colinu= x network adapter suffers from an IP fragmentation/reassembly performance= problem. >=20 > Please, can you try the same ping on a later colinux version (ping -s 4= 096 <remote_ip_address>) if you have time and if you can ? So, we could a= lready know if this problem is addressed with the new releases. >=20 > Thanks, >=20 > Claude LeFran=E7ois=20 > cla...@er... |
From: Claude L. (QB/EMC) <cla...@er...> - 2004-08-17 15:24:42
|
Thanks for the info, Nuno. I will try a more recent build asap. One question: are you using bridged networking ? The IP fragmentation problem was produced under the bridged networking = configuration under Win2K. Regards, Claude. Claude LeFran=E7ois=20 cla...@er... -----Original Message----- From: Nuno Lucas [mailto:lu...@nl...] Sent: Monday, August 16, 2004 7:44 PM To: Claude LeFrancois (QB/EMC) Cc: col...@li... Subject: Re: [coLinux-users] NFS performance and colinux 192.168.1.1 is my router in the internal network, not the host OS. colinux root # ping -s 4096 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 4096(4124) bytes of data. 4104 bytes from 192.168.1.1: icmp_seq=3D1 ttl=3D64 time=3D4.50 ms 4104 bytes from 192.168.1.1: icmp_seq=3D2 ttl=3D64 time=3D3.53 ms 4104 bytes from 192.168.1.1: icmp_seq=3D3 ttl=3D64 time=3D3.48 ms 4104 bytes from 192.168.1.1: icmp_seq=3D4 ttl=3D64 time=3D4.11 ms 4104 bytes from 192.168.1.1: icmp_seq=3D5 ttl=3D64 time=3D3.61 ms 4104 bytes from 192.168.1.1: icmp_seq=3D6 ttl=3D64 time=3D3.33 ms 4104 bytes from 192.168.1.1: icmp_seq=3D7 ttl=3D64 time=3D3.72 ms 4104 bytes from 192.168.1.1: icmp_seq=3D8 ttl=3D64 time=3D3.44 ms 4104 bytes from 192.168.1.1: icmp_seq=3D9 ttl=3D64 time=3D3.36 ms 4104 bytes from 192.168.1.1: icmp_seq=3D10 ttl=3D64 time=3D3.63 ms [....] --- 192.168.1.1 ping statistics --- 120 packets transmitted, 120 received, 0% packet loss, time 120280ms rtt min/avg/max/mdev =3D 3.280/3.761/9.236/0.951 ms And a really remote host: colinux root # ping -s 4096 www.colinux.org PING www.colinux.org (66.35.250.210) 4096(4124) bytes of data. 4104 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=3D1 = ttl=3D45=20 time=3D599 ms 4104 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=3D2 = ttl=3D45=20 time=3D595 ms 4104 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=3D3 = ttl=3D45=20 time=3D595 ms 4104 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=3D4 = ttl=3D45=20 time=3D594 ms 4104 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=3D5 = ttl=3D45=20 time=3D596 ms 4104 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=3D6 = ttl=3D45=20 time=3D595 ms 4104 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=3D7 = ttl=3D45=20 time=3D595 ms 4104 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=3D8 = ttl=3D45=20 time=3D595 ms 4104 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=3D9 = ttl=3D45=20 time=3D625 ms 4104 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=3D10=20 ttl=3D45 time=3D597 ms [....] --- www.colinux.org ping statistics --- 31 packets transmitted, 30 received, 3% packet loss, time 30386ms rtt min/avg/max/mdev =3D 593.580/598.933/654.012/11.610 ms I used a special build using the latest source, on a 2.6.8.1 kernel. colinux root # uname -a Linux colinux 2.6.8.1-co-0.6.2 #1 Sun Aug 15 04:33:48 WEST 2004 i686=20 Intel(R) Pentium(R) 4 CPU 1.70GHz GenuineIntel GNU/Linux Regards, ~Nuno Lucas Claude LeFrancois (QB/EMC), dando pulos de alegria, escreveu : > Hi George, >=20 > Thanks for your reply. I will give a try to the new release as soon = as possible. >=20 > However, I have made some NFS troubleshooting and I have finally been = able to go a bit further with the jumpstart and I have been able to = narrow down the problem. The NFS performance problem seems to be = produced by the IP fragmentation. >=20 > The default NFS block size on Linux is set to 4096 bytes (4K). When I = set the rootopts value to 1024, the jumpstart process goes a lot = better. This parameter set the rsize (read block size) option of the = NFS mount request of the root filesystem coming from the jumpstart = client. Unfortunately, all the other NFS mounted filesystems are not = using this parameter and suffer from the fragmentation problem. So, the = jumpstart fails later. >=20 > Basically, there is no fragmentation at 1024 but, at 4096, the = fragmentation is very important. To verify that the fragmentation is = responsible of the bad NFS performance, I have tested ping of 4K to a = remote system from colinux: >=20 > PING 142.133.81.2 (142.133.81.2) 4096(4124) bytes of data. > 4104 bytes from 142.133.81.2: icmp_seq=3D9 ttl=3D255 time=3D82.4 ms > 4104 bytes from 142.133.81.2: icmp_seq=3D14 ttl=3D255 time=3D4.17 ms > 4104 bytes from 142.133.81.2: icmp_seq=3D22 ttl=3D255 time=3D4.04 ms > 4104 bytes from 142.133.81.2: icmp_seq=3D24 ttl=3D255 time=3D5.05 ms > 4104 bytes from 142.133.81.2: icmp_seq=3D25 ttl=3D255 time=3D4.15 ms > 4104 bytes from 142.133.81.2: icmp_seq=3D32 ttl=3D255 time=3D21.0 ms > 4104 bytes from 142.133.81.2: icmp_seq=3D34 ttl=3D255 time=3D4.16 ms > 4104 bytes from 142.133.81.2: icmp_seq=3D78 ttl=3D255 time=3D4.17 ms >=20 > --- 142.133.81.2 ping statistics --- > 121 packets transmitted, 8 received, 93% packet loss, time 120805ms > rtt min/avg/max/mdev =3D 4.048/16.165/82.463/25.656 ms, pipe 2 >=20 > The ping test shows the 93% of packet drops... It looks like the = colinux network adapter suffers from an IP fragmentation/reassembly = performance problem. >=20 > Please, can you try the same ping on a later colinux version (ping -s = 4096 <remote_ip_address>) if you have time and if you can ? So, we = could already know if this problem is addressed with the new releases. >=20 > Thanks, >=20 > Claude LeFran=E7ois=20 > cla...@er... |
From: Nuno L. <lu...@nl...> - 2004-08-17 15:51:29
|
Claude LeFrancois (QB/EMC), dando pulos de alegria, escreveu : > Thanks for the info, Nuno. > > I will try a more recent build asap. > > One question: are you using bridged networking ? I'm using the tap adapter, bridged by WinXP with my network card. > > The IP fragmentation problem was produced under the bridged networking configuration under Win2K. Not sure about that (I made no tests), but it seems the tap-win32 adapter is somewhat faster and reliable than the bridged adapter. Also, the code was revised lately to accomodate larger packets transfers. I made some basic tests to measure the network performance. This tests are not reliable, just a simple timed copy between systems of a 34 MB file. Using samba: lan --> colinux : ~2.0 MB/s colinux --> lan : ~1.5 MB/s xp --> colinux : ~0.5 MB/s colinux <-- xp : (didn't had a easy way of testing this) lan <--> xp : ~3.3 MB/s Using nfsd/portmap on my router: lan --> colinux : ~2.5 MB/s I started nfsd with default parameters (sync), in a Gentoo machine, just for this test. Regards, ~Nuno Lucas |
From: gboutwel <gbo...@pr...> - 2004-08-18 13:32:04
|
> > One question: are you using bridged networking ? > > I'm using the tap adapter, bridged by WinXP with my network card. I use both. On the PCAP bridging there is, also, 0% loss of packets using latest sources. > Not sure about that (I made no tests), but it seems the tap-win32 > adapter is somewhat faster and reliable than the bridged adapter. Also, > the code was revised lately to accomodate larger packets transfers. Yeah, most the tests that Dan has done shows TAP to be the faster interface. George ------------------------------------------ Praize? Enter In... http://www.praize.com/ |
From: Claude L. (QB/EMC) <cla...@er...> - 2004-08-18 21:45:52
|
Hi George, I have installed snapshot-20040710. I have made the modification to the x= ml file to attach to my Broadcom interface. I have booted my Fedora Core = 1 distribution with the 2.6.7 kernel without a problem. This snapshot doe= s not contain the nfsd support. So, I have recompiled the colinux kernel = with the appropriate settings. I have also learned that the NFS daemon se= rvice has changed in the 2.6 kernels. So, I had to make a little adaptati= on (mount -t nfsd nfsd /proc/fs/nfs). Finally, I got my colinux working f= ine. :) However, my Solaris jumpstart does not work yet. I hit the same problem. = It seems the IP fragmentation problem is still there but I have noticed a= n good improvement. It looks like the jumpstart client (the Solaris box) = sends a bunch of large NFS read packets at the same time. Colinux is not = able to reply to all of them in time and the jumpstart client sends ICMP = packets with TTL exceeded to colinux. At this moment the jumpstart client= gives "NFS server not responding". The only way I have to improve this s= ituation is to set the block size to 1024 which avoids the fragmentation.= The bad stuff is that only the root fs benefits from this settings all t= he other NFS mounts from the client are 4K blocks. The jumpstart client is point-to-point connected with my laptop using a c= ross-over cable. To solve this situation, I see two options: 1. Hard code the NFS packet size to 1024 in the kernel 2. Try the new feature: NFS over TCP But, the fragmentation problem in colinux is not solved... I am a bit con= fused now. I don't know what to do at this point. I am using the bridged = networking configuration. I guess it has nothing to do with the TAP drive= rs, isn't it ? I am using win2k so there is no way to enable bridging thr= ough the TAP interface because it appears this is only supported in XP. I= absolutely need to use bridging because the jumpstart client initiates t= he jumpstart process by a RARP request. Then, I cannot use NAT because th= ese packets won't be redirected to my colinux distribution unless a port = forwarding mechanism exists. My system is a HP NC8000 laptop. It has 512 MB RAM and 1.5 GHz Pentium M = CPU. The network interface is a Broadcom NetXtreme Gigabit adapter. I hav= e already disabled TCP checksums and flow control on this interface. Any suggestions are really welcome ! Here is the output of my latest ping test: PING 192.168.0.101 (192.168.0.101) 4096(4124) bytes of data. 4104 bytes from 192.168.0.101: icmp_seq=3D1 ttl=3D255 time=3D2.24 ms 4104 bytes from 192.168.0.101: icmp_seq=3D2 ttl=3D255 time=3D2.10 ms 4104 bytes from 192.168.0.101: icmp_seq=3D3 ttl=3D255 time=3D2.23 ms 4104 bytes from 192.168.0.101: icmp_seq=3D7 ttl=3D255 time=3D2.09 ms 4104 bytes from 192.168.0.101: icmp_seq=3D8 ttl=3D255 time=3D2.22 ms 4104 bytes from 192.168.0.101: icmp_seq=3D10 ttl=3D255 time=3D2.10 ms 4104 bytes from 192.168.0.101: icmp_seq=3D12 ttl=3D255 time=3D2.23 ms 4104 bytes from 192.168.0.101: icmp_seq=3D13 ttl=3D255 time=3D2.22 ms 4104 bytes from 192.168.0.101: icmp_seq=3D15 ttl=3D255 time=3D2.22 ms 4104 bytes from 192.168.0.101: icmp_seq=3D17 ttl=3D255 time=3D2.06 ms 4104 bytes from 192.168.0.101: icmp_seq=3D20 ttl=3D255 time=3D2.23 ms 4104 bytes from 192.168.0.101: icmp_seq=3D23 ttl=3D255 time=3D2.22 ms 4104 bytes from 192.168.0.101: icmp_seq=3D24 ttl=3D255 time=3D2.23 ms 4104 bytes from 192.168.0.101: icmp_seq=3D26 ttl=3D255 time=3D2.09 ms 4104 bytes from 192.168.0.101: icmp_seq=3D27 ttl=3D255 time=3D2.11 ms 4104 bytes from 192.168.0.101: icmp_seq=3D30 ttl=3D255 time=3D2.22 ms 4104 bytes from 192.168.0.101: icmp_seq=3D32 ttl=3D255 time=3D1.97 ms 4104 bytes from 192.168.0.101: icmp_seq=3D33 ttl=3D255 time=3D2.09 ms 4104 bytes from 192.168.0.101: icmp_seq=3D34 ttl=3D255 time=3D2.07 ms --- 192.168.0.101 ping statistics --- 35 packets transmitted, 19 received, 45% packet loss, time 34196ms rtt min/avg/max/mdev =3D 1.974/2.158/2.242/0.087 ms, pipe 2 Thanks, Claude. Claude LeFran=E7ois=20 cla...@er... -----Original Message----- From: col...@li... [mailto:col...@li...]On Behalf Of gboutwel Sent: Wednesday, August 18, 2004 9:32 AM To: col...@li... Cc: Claude LeFrancois (QB/EMC) Subject: Re: [coLinux-users] NFS performance and colinux > > One question: are you using bridged networking ? > > I'm using the tap adapter, bridged by WinXP with my network card. I use both. On the PCAP bridging there is, also, 0% loss of packets using latest sources. > Not sure about that (I made no tests), but it seems the tap-win32 > adapter is somewhat faster and reliable than the bridged adapter. Also, > the code was revised lately to accomodate larger packets transfers. Yeah, most the tests that Dan has done shows TAP to be the faster interface. George ------------------------------------------ Praize? Enter In... http://www.praize.com/ ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ coLinux-users mailing list coL...@li... https://lists.sourceforge.net/lists/listinfo/colinux-users |
From: Claude L. (QB/EMC) <cla...@er...> - 2004-08-20 13:36:48
|
Hi George, I have tested successfully option 1 from the list provided in my = previous message. So, I have been able to make a Solaris jumpstart from = a Windows 2000 based system using coLinux 0.6.2 (snapshot-20040710) ! I = have recompiled the 2.6.7 colinux kernel with the "NFS over TCP" = feature enabled. It works like a charm. The installation speed is very good. It's quite = the same speed than a native Linux system. Of course, the IP = fragmentation/reassembly problem I have observed using the bridged = network configuration under win2k is not solved but at least there is a = workaround. As far as I can see, there is no more = fragmentation/reassembly problem using the new NFS feature because I = think each NFS packet subject to fragmentation is replaced by a "RPC = continuation" packet. If a part of a packet is missing, I guess only = the missing element will re-transmit instead of the whole NFS stream in = a normal world. This is due to the TCP nature and design. So, the "NFS = over TCP" feature improves NFS reliability for connections under "bad" = networking conditions. Thanks, Claude. Claude LeFran=E7ois=20 cla...@er... -----Original Message----- From: Claude LeFrancois (QB/EMC)=20 Sent: Wednesday, August 18, 2004 5:46 PM To: 'gboutwel' Cc: col...@li... Subject: RE: [coLinux-users] NFS performance and colinux Hi George, I have installed snapshot-20040710. I have made the modification to the = xml file to attach to my Broadcom interface. I have booted my Fedora = Core 1 distribution with the 2.6.7 kernel without a problem. This = snapshot does not contain the nfsd support. So, I have recompiled the = colinux kernel with the appropriate settings. I have also learned that = the NFS daemon service has changed in the 2.6 kernels. So, I had to = make a little adaptation (mount -t nfsd nfsd /proc/fs/nfs). Finally, I = got my colinux working fine. :) However, my Solaris jumpstart does not work yet. I hit the same = problem. It seems the IP fragmentation problem is still there but I = have noticed an good improvement. It looks like the jumpstart client = (the Solaris box) sends a bunch of large NFS read packets at the same = time. Colinux is not able to reply to all of them in time and the = jumpstart client sends ICMP packets with TTL exceeded to colinux. At = this moment the jumpstart client gives "NFS server not responding". The = only way I have to improve this situation is to set the block size to = 1024 which avoids the fragmentation. The bad stuff is that only the = root fs benefits from this settings all the other NFS mounts from the = client are 4K blocks. The jumpstart client is point-to-point connected with my laptop using a = cross-over cable. To solve this situation, I see two options: 1. Hard code the NFS packet size to 1024 in the kernel 2. Try the new feature: NFS over TCP But, the fragmentation problem in colinux is not solved... I am a bit = confused now. I don't know what to do at this point. I am using the = bridged networking configuration. I guess it has nothing to do with the = TAP drivers, isn't it ? I am using win2k so there is no way to enable = bridging through the TAP interface because it appears this is only = supported in XP. I absolutely need to use bridging because the = jumpstart client initiates the jumpstart process by a RARP request. = Then, I cannot use NAT because these packets won't be redirected to my = colinux distribution unless a port forwarding mechanism exists. My system is a HP NC8000 laptop. It has 512 MB RAM and 1.5 GHz Pentium = M CPU. The network interface is a Broadcom NetXtreme Gigabit adapter. I = have already disabled TCP checksums and flow control on this interface. Any suggestions are really welcome ! Here is the output of my latest ping test: PING 192.168.0.101 (192.168.0.101) 4096(4124) bytes of data. 4104 bytes from 192.168.0.101: icmp_seq=3D1 ttl=3D255 time=3D2.24 ms 4104 bytes from 192.168.0.101: icmp_seq=3D2 ttl=3D255 time=3D2.10 ms 4104 bytes from 192.168.0.101: icmp_seq=3D3 ttl=3D255 time=3D2.23 ms 4104 bytes from 192.168.0.101: icmp_seq=3D7 ttl=3D255 time=3D2.09 ms 4104 bytes from 192.168.0.101: icmp_seq=3D8 ttl=3D255 time=3D2.22 ms 4104 bytes from 192.168.0.101: icmp_seq=3D10 ttl=3D255 time=3D2.10 ms 4104 bytes from 192.168.0.101: icmp_seq=3D12 ttl=3D255 time=3D2.23 ms 4104 bytes from 192.168.0.101: icmp_seq=3D13 ttl=3D255 time=3D2.22 ms 4104 bytes from 192.168.0.101: icmp_seq=3D15 ttl=3D255 time=3D2.22 ms 4104 bytes from 192.168.0.101: icmp_seq=3D17 ttl=3D255 time=3D2.06 ms 4104 bytes from 192.168.0.101: icmp_seq=3D20 ttl=3D255 time=3D2.23 ms 4104 bytes from 192.168.0.101: icmp_seq=3D23 ttl=3D255 time=3D2.22 ms 4104 bytes from 192.168.0.101: icmp_seq=3D24 ttl=3D255 time=3D2.23 ms 4104 bytes from 192.168.0.101: icmp_seq=3D26 ttl=3D255 time=3D2.09 ms 4104 bytes from 192.168.0.101: icmp_seq=3D27 ttl=3D255 time=3D2.11 ms 4104 bytes from 192.168.0.101: icmp_seq=3D30 ttl=3D255 time=3D2.22 ms 4104 bytes from 192.168.0.101: icmp_seq=3D32 ttl=3D255 time=3D1.97 ms 4104 bytes from 192.168.0.101: icmp_seq=3D33 ttl=3D255 time=3D2.09 ms 4104 bytes from 192.168.0.101: icmp_seq=3D34 ttl=3D255 time=3D2.07 ms --- 192.168.0.101 ping statistics --- 35 packets transmitted, 19 received, 45% packet loss, time 34196ms rtt min/avg/max/mdev =3D 1.974/2.158/2.242/0.087 ms, pipe 2 Thanks, Claude. Claude LeFran=E7ois=20 cla...@er... -----Original Message----- From: col...@li... [mailto:col...@li...]On Behalf Of gboutwel Sent: Wednesday, August 18, 2004 9:32 AM To: col...@li... Cc: Claude LeFrancois (QB/EMC) Subject: Re: [coLinux-users] NFS performance and colinux > > One question: are you using bridged networking ? > > I'm using the tap adapter, bridged by WinXP with my network card. I use both. On the PCAP bridging there is, also, 0% loss of packets using latest sources. > Not sure about that (I made no tests), but it seems the tap-win32 > adapter is somewhat faster and reliable than the bridged adapter. Also, > the code was revised lately to accomodate larger packets transfers. Yeah, most the tests that Dan has done shows TAP to be the faster interface. George ------------------------------------------ Praize? Enter In... http://www.praize.com/ ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ coLinux-users mailing list coL...@li... https://lists.sourceforge.net/lists/listinfo/colinux-users |
From: mohan <Mo...@va...> - 2004-08-26 07:51:39
|
Dear all, Is there any documentation guide on 2.6.7 kernel (debian/fedora) using = colinux 2.6.7 with x-server. Appreciate if someone in this group can = assist me in getting it to work for me.=20 Appreciate you help. Mohan -----Original Message----- From: col...@li... = [mailto:col...@li...] On Behalf Of Claude = LeFrancois (QB/EMC) Sent: Tuesday, August 24, 2004 1:38 AM To: 'col...@li...' Subject: FW: [coLinux-users] NFS performance and colinux Hi George, I have tested successfully option 1 from the list provided in my = previous message. So, I have been able to make a Solaris jumpstart from = a Windows 2000 based system using coLinux 0.6.2 (snapshot-20040710) ! I = have recompiled the 2.6.7 colinux kernel with the "NFS over TCP" feature = enabled. It works like a charm. The installation speed is very good. It's quite = the same speed than a native Linux system. Of course, the IP = fragmentation/reassembly problem I have observed using the bridged = network configuration under win2k is not solved but at least there is a = workaround. As far as I can see, there is no more = fragmentation/reassembly problem using the new NFS feature because I = think each NFS packet subject to fragmentation is replaced by a "RPC = continuation" packet. If a part of a packet is missing, I guess only the = missing element will re-transmit instead of the whole NFS stream in a = normal world. This is due to the TCP nature and design. So, the "NFS = over TCP" feature improves NFS reliability for connections under "bad" = networking conditions. Thanks, Claude. Claude LeFran=E7ois=20 cla...@er... -----Original Message----- From: Claude LeFrancois (QB/EMC)=20 Sent: Wednesday, August 18, 2004 5:46 PM To: 'gboutwel' Cc: col...@li... Subject: RE: [coLinux-users] NFS performance and colinux Hi George, I have installed snapshot-20040710. I have made the modification to the = xml file to attach to my Broadcom interface. I have booted my Fedora = Core 1 distribution with the 2.6.7 kernel without a problem. This = snapshot does not contain the nfsd support. So, I have recompiled the = colinux kernel with the appropriate settings. I have also learned that = the NFS daemon service has changed in the 2.6 kernels. So, I had to make = a little adaptation (mount -t nfsd nfsd /proc/fs/nfs). Finally, I got my = colinux working fine. :) However, my Solaris jumpstart does not work yet. I hit the same problem. = It seems the IP fragmentation problem is still there but I have noticed = an good improvement. It looks like the jumpstart client (the Solaris = box) sends a bunch of large NFS read packets at the same time. Colinux = is not able to reply to all of them in time and the jumpstart client = sends ICMP packets with TTL exceeded to colinux. At this moment the = jumpstart client gives "NFS server not responding". The only way I have = to improve this situation is to set the block size to 1024 which avoids = the fragmentation. The bad stuff is that only the root fs benefits from = this settings all the other NFS mounts from the client are 4K blocks. The jumpstart client is point-to-point connected with my laptop using a = cross-over cable. To solve this situation, I see two options: 1. Hard code the NFS packet size to 1024 in the kernel 2. Try the new feature: NFS over TCP But, the fragmentation problem in colinux is not solved... I am a bit = confused now. I don't know what to do at this point. I am using the = bridged networking configuration. I guess it has nothing to do with the = TAP drivers, isn't it ? I am using win2k so there is no way to enable = bridging through the TAP interface because it appears this is only = supported in XP. I absolutely need to use bridging because the jumpstart = client initiates the jumpstart process by a RARP request. Then, I cannot = use NAT because these packets won't be redirected to my colinux = distribution unless a port forwarding mechanism exists. My system is a HP NC8000 laptop. It has 512 MB RAM and 1.5 GHz Pentium M = CPU. The network interface is a Broadcom NetXtreme Gigabit adapter. I = have already disabled TCP checksums and flow control on this interface. Any suggestions are really welcome ! Here is the output of my latest ping test: PING 192.168.0.101 (192.168.0.101) 4096(4124) bytes of data. 4104 bytes from 192.168.0.101: icmp_seq=3D1 ttl=3D255 time=3D2.24 ms 4104 bytes from 192.168.0.101: icmp_seq=3D2 ttl=3D255 time=3D2.10 ms 4104 bytes from 192.168.0.101: icmp_seq=3D3 ttl=3D255 time=3D2.23 ms 4104 bytes from 192.168.0.101: icmp_seq=3D7 ttl=3D255 time=3D2.09 ms 4104 bytes from 192.168.0.101: icmp_seq=3D8 ttl=3D255 time=3D2.22 ms 4104 bytes from 192.168.0.101: icmp_seq=3D10 ttl=3D255 time=3D2.10 ms 4104 bytes from 192.168.0.101: icmp_seq=3D12 ttl=3D255 time=3D2.23 ms 4104 bytes from 192.168.0.101: icmp_seq=3D13 ttl=3D255 time=3D2.22 ms 4104 bytes from 192.168.0.101: icmp_seq=3D15 ttl=3D255 time=3D2.22 ms 4104 bytes from 192.168.0.101: icmp_seq=3D17 ttl=3D255 time=3D2.06 ms 4104 bytes from 192.168.0.101: icmp_seq=3D20 ttl=3D255 time=3D2.23 ms 4104 bytes from 192.168.0.101: icmp_seq=3D23 ttl=3D255 time=3D2.22 ms 4104 bytes from 192.168.0.101: icmp_seq=3D24 ttl=3D255 time=3D2.23 ms 4104 bytes from 192.168.0.101: icmp_seq=3D26 ttl=3D255 time=3D2.09 ms 4104 bytes from 192.168.0.101: icmp_seq=3D27 ttl=3D255 time=3D2.11 ms 4104 bytes from 192.168.0.101: icmp_seq=3D30 ttl=3D255 time=3D2.22 ms 4104 bytes from 192.168.0.101: icmp_seq=3D32 ttl=3D255 time=3D1.97 ms 4104 bytes from 192.168.0.101: icmp_seq=3D33 ttl=3D255 time=3D2.09 ms 4104 bytes from 192.168.0.101: icmp_seq=3D34 ttl=3D255 time=3D2.07 ms --- 192.168.0.101 ping statistics --- 35 packets transmitted, 19 received, 45% packet loss, time 34196ms rtt min/avg/max/mdev =3D 1.974/2.158/2.242/0.087 ms, pipe 2 Thanks, Claude. Claude LeFran=E7ois=20 cla...@er... -----Original Message----- From: col...@li... [mailto:col...@li...]On Behalf Of gboutwel Sent: Wednesday, August 18, 2004 9:32 AM To: col...@li... Cc: Claude LeFrancois (QB/EMC) Subject: Re: [coLinux-users] NFS performance and colinux > > One question: are you using bridged networking ? > > I'm using the tap adapter, bridged by WinXP with my network card. I use both. On the PCAP bridging there is, also, 0% loss of packets using latest sources. > Not sure about that (I made no tests), but it seems the tap-win32 > adapter is somewhat faster and reliable than the bridged adapter. Also, > the code was revised lately to accomodate larger packets transfers. Yeah, most the tests that Dan has done shows TAP to be the faster interface. George ------------------------------------------ Praize? Enter In... http://www.praize.com/ ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ coLinux-users mailing list coL...@li... https://lists.sourceforge.net/lists/listinfo/colinux-users ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ coLinux-users mailing list coL...@li... https://lists.sourceforge.net/lists/listinfo/colinux-users |
From: <ti...@fu...> - 2004-08-26 08:16:39
|
This is general what I do to get X and colinux working. - Install cygwin with X (or full cygwin, takes a bit longer) - Open cygwin shell and start the X server with 'X <options>' I use the following options -ac No authentication required -multiwindow Use windows desktop as window manager, works fine and faster than using extra X window manager -clipboard Clipboard is not enabled by default -nodecoration I'm not sure if this makes any sense with -multiwindow -xkblayout fi I'm from Finland.. -xkblayout pc105 Supposedly helps to get some keys working -xkbvariant nodeadkeys -xkbrules xfree86 If you google "cygwin X" then you can find better description of some of these parameters. However, not for -ac, because it is 'standard' X server parameter, for that, and another option -query, you need to consult "man X" perhaps, on system that has that man page. Or google. I also add & to the end so that I can use the cygwin shell for other things. In the colinux side, you just install the X programs and run them with DISPLAY=192.168.1.1:0.0, for example: DISPLAY=192.168.1.1:0.0 xterm & You will need -ac, or -query. With -query 192.168.1.1 you will probably need to install gdm or similar display manager to colinux system. That IMHO is quite waste while -ac -multiwindow works just fine and you don't have to install lots of packages just to get X working. > Is there any documentation guide on 2.6.7 kernel (debian/fedora) using > colinux 2.6.7 with x-server. Appreciate if someone in this group can > assist me in getting it to work for me. -- timo |
From: Vijay V. <vi...@hp...> - 2004-08-31 21:09:46
|
I have installed colinux (with Fedora core 1) on two of my desktops at home (essentially I got one working, and copied hard-disk image overm and changed the IP settings). I am able to reach both the virtual machines from either hostmachine (ping), however, I am unable to ping between the virtual machines. For example, say the host machines have IP addresses 192.168.0.199, 192.168.0.198 and the virtual machines have 192.168.0.150, 192.168.0.151. I am able to ping from 199 & 198 to 150 and 151. But I am not able to ping between 150 & 151 itself. Any ideas on what might be the issue here? TIA Vijay ----- Original Message ----- From: <ti...@fu...> To: "mohan" <Mo...@va...> Cc: "Claude LeFrancois (QB/EMC)" <cla...@er...>; <col...@li...> Sent: Thursday, August 26, 2004 3:16 AM Subject: RE: [coLinux-users] NFS performance and colinux > > This is general what I do to get X and colinux working. > - Install cygwin with X (or full cygwin, takes a bit longer) > - Open cygwin shell and start the X server with 'X <options>' > > I use the following options > -ac No authentication required > -multiwindow Use windows desktop as window manager, works fine > and faster than using extra X window manager > -clipboard Clipboard is not enabled by default > -nodecoration I'm not sure if this makes any sense with -multiwindow > -xkblayout fi I'm from Finland.. > -xkblayout pc105 Supposedly helps to get some keys working > -xkbvariant nodeadkeys > -xkbrules xfree86 > > If you google "cygwin X" then you can find better description of some of > these parameters. However, not for -ac, because it is 'standard' X server > parameter, for that, and another option -query, you need to consult "man > X" perhaps, on system that has that man page. Or google. > > I also add & to the end so that I can use the cygwin shell for other > things. > > In the colinux side, you just install the X programs and run them > with DISPLAY=192.168.1.1:0.0, for example: > > DISPLAY=192.168.1.1:0.0 xterm & > > You will need -ac, or -query. With -query 192.168.1.1 you will probably > need to install gdm or similar display manager to colinux system. That > IMHO is quite waste while -ac -multiwindow works just fine and you don't > have to install lots of packages just to get X working. > > > Is there any documentation guide on 2.6.7 kernel (debian/fedora) using > > colinux 2.6.7 with x-server. Appreciate if someone in this group can > > assist me in getting it to work for me. > > > -- > timo > > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > _______________________________________________ > coLinux-users mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-users > |