[linrad] Re: Testing MAP65 v0.8
Stan wrote: Hello Rick, can you point me to some specific models for managed switches, so I can read up ? This should get you started: http://www.ctrlink.com/managed_features.htm There are also some really good docs available on Cisco's site after you register. The good stuff is Cisco gear, and has a wide range of prices, depending on whether you are looking at a high-speed backbone app or just wiring closet use. Some of the stuff at Cisco is pretty reasonably priced. Ebay has better deals on used Cisco gear There are a wide variety of manufacturers out there, but again the best is Cisco IMHO, but almost anything with IGMP snooping will handle segmentation of multicast traffic. There are some pretty good deals on used gear on Ebay, some even cheaper than a do-nothing typical consumer switch in a plastic case. Rick Kunath, k9ao # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: Testing MAP65 v0.8
Rick and all, Well, it seems I'm learning more about computer networking than I ever wanted to know... ;-) Why did you use a mask of 224.0.0.0 instead of 240.0.0.0 in your multicast route statement on the Linux box? (Your: # route add -net 224.0.0.0 netmask 224.0.0.0 dev eth1 statement.) My mistake when typing it into the email message. I had it right when the tests were made. Unfortunately neither of the switches you tested with had the horsepower (i.e. were managed switches) to control the multicast traffic, though they will segment the unicast traffic. Yes, this is exactly what I discovered. You asked some more good questions, and I will follow up on them soon. In the meantime, I've realized that there is really no reason to use multicasting for the Linrad -- MAP65 connection. I could just as well unicast the UDP data stream between the two machines, using a crossover cable and explicit private-LAN (192.168.x.x) addresses on each end, and have none of the problems I've been worrying about. This solution causes the data go where I want it to go, and nowhere else. The other option that I'm beginning to think very attractive is running both Linrad and MAP65 in a single machine. TIMF2 data could go from Linrad to MAP65 over the loopback (lo) interface -- or by way of shared memory, or ??? -- Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: Testing MAP65 v0.8
Hello Rick, can you point me to some specific models for managed switches, so I can read up ? Thanks Stan,W1LE Unfortunately neither of the switches you tested with had the horsepower (i.e. were managed switches) to control the multicast traffic, though they will segment the unicast traffic. A managed switch (capable of IGMP snooping) would handle the multicast traffic also and eliminate the swamping of machine A. # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: Testing MAP65 v0.8
Rick -- Thanks for the suggestions, they are much appreciated. I have been tied up since yesterday afternoon, but hope to find time to try them out soon ... maybe even later today. I will report back here on any success or failure. -- 73, Joe, K1JT Rick Kunath wrote: Joe Taylor wrote: My earlier problem with dropped multicast packets seems to be fixed in MAP65 v0.8. However, when running the Linrad-MAP65 combination on two separate computers I still have some network-related problems. Perhaps someone on this list who knows much more than I about networking can help. My computer network looks like this: ADSL 10 Mb/s -- Computer_A DSL -- Modem -- Ethernet -- Computer_B Hub| -- Computer_C Three computers are connected to a 10 Mb/s Ethernet Hub. Have you considered replacing the hub with a 100 Mbps full-duplex Ethernet switch? There are many advantages in this over a hub. Computer_A is my XYL's machine. Computer_B runs Windows 2000 Pro, and Computer_C runs Linux (presently the Kubuntu 6.06 distribution). In addition to the connections of all three machines to the hub, a crossover cable makes a direct 100 Mb/s connection between computers B and C. The ethernet interfaces on B and C appear to be configured correctly. On Linux they appear as eth0 and eth1 (occasionally they boot up as eth0 and eth2, I don't know why???). This is configurable, generally, and should be fixed if you intend to use interface based static routes. Check here for more info on iftab (/etc/iftab): http://linux.die.net/man/5/iftab Connections to the Hub are assigned dynamic IP addresses; I assume these addresses are in the 192.168.1.x range? I assigned hard-coded addresses 192.168.10.12 and 192.168.10.13 for the direct inter-machine connection between B and C. I can use the 100 Mb/s direct line for many purposes. I can ping over it in either direction; I can ssh into Linux from Windows; I can use Cygwin/X (as described above) to display Linux X programs on the Windows screen. However, I cannot seem to persuade Windows 2000 Pro to accept multicast packets over the direct line. When I run Linrad on computer C and MAP65 on B, the multicast traffic is always received over the slow line, through the Hub. This uses most of the 10 Mb/s link's bandwidth, and my wife can't read her email when I'm on the air. This is NOT GOOD. An Ethernet switch would eliminate this, as traffic passing between two machines (B-C) does not use any bandwidth, nor is it seen, by any other machines. Internet access by machine A would be unaffected by a transfer occurring between machines B and C. Machine A would not see the traffic, nor would there be any contention for bandwidth on it's connection because of the B-C traffic. By default the multicast traffic generated by Computer_C goes to eth0. I can use the Linux route command to explicitly tell the system to use eth0: # route add -net 224.0.0.0 netmask 224.0.0.0 dev eth0 This works fine (but of course, still sends the heavy multicast traffic through the hub). If I remove this routing instruction and instead enter # route add -net 224.0.0.0 netmask 224.0.0.0 dev eth1 the multicast data are not received by MAP65 running on the other machine. If I unplug the crossover cable from the Windows machine and instead plug it into a laptop running Win/XP, the laptop receives the multicast packets without a problem. Thus, it would seem that the problem must be in my setup of the Win2k machine -- the one with two ethernet interfaces. Can anyone shed any light on this situation for me? Would there be sufficient bandwidth in a 100baseTx connection (100 Mbps full-duplex) to handle both of the networking streams, i.e. the hub and the direct stream? If so, replacing the inefficient hub with a faster switch, thus confining network traffic to only the ports of the involved machines, might solve the issue. This might allow you to eliminate the direct connection between machines B and C. As to W2k the unicast and multicast routes are handled in separate tables, check here for more info: http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/intwork/inaf_mul_hwmc.mspx?mfr=true Hope some of this is of some use :) Rick Kunath, k9ao # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED] # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To
[linrad] Re: Testing MAP65 v0.8
Rick, and all -- OK, I've a chance to make some more tests. My computer network looks like this: ADSL 10 Mb/s -- Computer_A DSL -- Modem -- Ethernet -- Computer_B Hub| -- Computer_C Three computers are connected to a 10 Mb/s Ethernet Hub. Additional information: ipconfig on Windows, ifconfig on Linux, report the following IP addresses: Computer A:172.16.28.67 Computer B(1): 172.16.28.69 Computer B(2): 192.168.10.13 Computer C(1): 172.16.28.31 Computer C(2): 192.168.10.12 Have you considered replacing the hub with a 100 Mbps full-duplex Ethernet switch? There are many advantages in this over a hub. Yes. That was my first attempt at a solution. I tried replacing the 10 Mb/s hub with a 10/100 Mb/s switch. The result was the same: when Computer C was multicasting 16-bit Linrad data at about 0.77 MB/s, Computer A was essentially unable to use the internet. The switch apparently did not prevent multicast traffic from reaching A. This was with a D-Link 10/100 Desktop Ethernet Switch. I also tried it with a Linksys model EZXS55W EtherFast 10/100 5-port Workgroup Switch. Same result. I then tried using both the hub and the switch: ADSL 10 Mb/s -- Computer A DSL -- Modem -- Ethernet Hub -- Ethernet -- Computer_B Switch | -- Computer_C Again, no change. This time I checked and confirmed that packets were arriving at A at the correct rate for them to be the multicast packets from C. Computer_A is my XYL's machine. Computer_B runs Windows 2000 Pro, and Computer_C runs Linux (presently the Kubuntu 6.06 distribution). In addition to the connections of all three machines to the hub, a crossover cable makes a direct 100 Mb/s connection between computers B and C. The ethernet interfaces on B and C appear to be configured correctly. On Linux they appear as eth0 and eth1 (occasionally they boot up as eth0 and eth2, I don't know why???). This is configurable, generally, and should be fixed if you intend to use interface based static routes. Check here for more info on iftab (/etc/iftab): http://linux.die.net/man/5/iftab RRR, thanks. Connections to the Hub are assigned dynamic IP addresses; I assume these addresses are in the 192.168.1.x range? No, see above. I was probably wrong to call them dynamic IP addresses. They are assigned by DHCP, but I believe they are always the same. I assigned hard-coded addresses 192.168.10.12 and 192.168.10.13 for the direct inter-machine connection between B and C. I can use the 100 Mb/s direct line for many purposes. I can ping over it in either direction; I can ssh into Linux from Windows; I can use Cygwin/X (as described above) to display Linux X programs on the Windows screen. However, I cannot seem to persuade Windows 2000 Pro to accept multicast packets over the direct line. When I run Linrad on computer C and MAP65 on B, the multicast traffic is always received over the slow line, through the Hub. This uses most of the 10 Mb/s link's bandwidth, and my wife can't read her email when I'm on the air. This is NOT GOOD. An Ethernet switch would eliminate this, as traffic passing between two machines (B-C) does not use any bandwidth, nor is it seen, by any other machines. Internet access by machine A would be unaffected by a transfer occurring between machines B and C. Machine A would not see the traffic, nor would there be any contention for bandwidth on it's connection because of the B-C traffic. Well, as far as I can see this does not seem to be the case. Can it be that your statement is true for normal one-to-one IP traffic, but not for multicast traffic? Or is it true for a router, but not for a switch? By default the multicast traffic generated by Computer_C goes to eth0. I can use the Linux route command to explicitly tell the system to use eth0: # route add -net 224.0.0.0 netmask 224.0.0.0 dev eth0 This works fine (but of course, still sends the heavy multicast traffic through the hub). If I remove this routing instruction and instead enter # route add -net 224.0.0.0 netmask 224.0.0.0 dev eth1 the multicast data are not received by MAP65 running on the other machine. If I unplug the crossover cable from the Windows machine and instead plug it into a laptop running Win/XP, the laptop receives the multicast packets without a problem. Thus, it would seem that the problem must be in my setup of the Win2k machine -- the one with two ethernet interfaces. Can anyone shed any light on this situation for me? Would there be sufficient bandwidth in a 100baseTx connection (100 Mbps full-duplex) to handle both of the networking streams, i.e. the hub and the direct stream? If so, replacing the inefficient hub with a faster switch, thus confining network traffic to only the ports
[linrad] Re: Testing MAP65 v0.8
Well, I found the following information about Ethernet switches: Data received on any port of a repeating hub will be repeated on all of its ports. Unicast, broadcast and multicast messages are all the same to a repeating hub. With a switching hub or switch, unicast messages are only sent to the ports involved in a conversation. However, a standard unmanaged switch without IGMP snooping will handle a multicast message just like a broadcast message: it will receive the message on one port and transmit the message onwards on all other ports. See http://ethernet.industrial-networking.com/articles/articledisplay.asp?id=936 It would appear that a direct inter-machine connection is the way to go. Now I need to understand why it works fine into my WinXP laptop, but not into the Win2k machine. Any further comments or suggestions would be welcome! -- 73, Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: Testing MAP65 v0.8
Joe Taylor wrote: My earlier problem with dropped multicast packets seems to be fixed in MAP65 v0.8. However, when running the Linrad-MAP65 combination on two separate computers I still have some network-related problems. Perhaps someone on this list who knows much more than I about networking can help. My computer network looks like this: ADSL 10 Mb/s -- Computer_A DSL -- Modem -- Ethernet -- Computer_B Hub| -- Computer_C Three computers are connected to a 10 Mb/s Ethernet Hub. Have you considered replacing the hub with a 100 Mbps full-duplex Ethernet switch? There are many advantages in this over a hub. Computer_A is my XYL's machine. Computer_B runs Windows 2000 Pro, and Computer_C runs Linux (presently the Kubuntu 6.06 distribution). In addition to the connections of all three machines to the hub, a crossover cable makes a direct 100 Mb/s connection between computers B and C. The ethernet interfaces on B and C appear to be configured correctly. On Linux they appear as eth0 and eth1 (occasionally they boot up as eth0 and eth2, I don't know why???). This is configurable, generally, and should be fixed if you intend to use interface based static routes. Check here for more info on iftab (/etc/iftab): http://linux.die.net/man/5/iftab Connections to the Hub are assigned dynamic IP addresses; I assume these addresses are in the 192.168.1.x range? I assigned hard-coded addresses 192.168.10.12 and 192.168.10.13 for the direct inter-machine connection between B and C. I can use the 100 Mb/s direct line for many purposes. I can ping over it in either direction; I can ssh into Linux from Windows; I can use Cygwin/X (as described above) to display Linux X programs on the Windows screen. However, I cannot seem to persuade Windows 2000 Pro to accept multicast packets over the direct line. When I run Linrad on computer C and MAP65 on B, the multicast traffic is always received over the slow line, through the Hub. This uses most of the 10 Mb/s link's bandwidth, and my wife can't read her email when I'm on the air. This is NOT GOOD. An Ethernet switch would eliminate this, as traffic passing between two machines (B-C) does not use any bandwidth, nor is it seen, by any other machines. Internet access by machine A would be unaffected by a transfer occurring between machines B and C. Machine A would not see the traffic, nor would there be any contention for bandwidth on it's connection because of the B-C traffic. By default the multicast traffic generated by Computer_C goes to eth0. I can use the Linux route command to explicitly tell the system to use eth0: # route add -net 224.0.0.0 netmask 224.0.0.0 dev eth0 This works fine (but of course, still sends the heavy multicast traffic through the hub). If I remove this routing instruction and instead enter # route add -net 224.0.0.0 netmask 224.0.0.0 dev eth1 the multicast data are not received by MAP65 running on the other machine. If I unplug the crossover cable from the Windows machine and instead plug it into a laptop running Win/XP, the laptop receives the multicast packets without a problem. Thus, it would seem that the problem must be in my setup of the Win2k machine -- the one with two ethernet interfaces. Can anyone shed any light on this situation for me? Would there be sufficient bandwidth in a 100baseTx connection (100 Mbps full-duplex) to handle both of the networking streams, i.e. the hub and the direct stream? If so, replacing the inefficient hub with a faster switch, thus confining network traffic to only the ports of the involved machines, might solve the issue. This might allow you to eliminate the direct connection between machines B and C. As to W2k the unicast and multicast routes are handled in separate tables, check here for more info: http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/intwork/inaf_mul_hwmc.mspx?mfr=true Hope some of this is of some use :) Rick Kunath, k9ao # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
