Re: poor ethernet performance?
You can hijack the MAC address after the CAM table (not ARP cache) times out for the switches. However, you can't just listen to their traffic unless you're on a span port (and span ports don't always work correctly). VLANing has a number of goals, of which you are listing only one. Another is to permit any net to appear on any switch within the switch fabric. VLANs are usually used in a form that spans multiple switches, not just using VLANs on a single switch. At an installation I put together in India, we used VLANs to allow us to better use IP addresses in a strange physical layout. When we were building out our New Site Architecture at Cisco in San Jose, we used VLANs to cut down the number of routing components necessary and further to take advantage of Layer 3 short-cutting in a number of spots around the buildings. On Wed, 21 Jul 1999 00:33:31 PDT, Sendmail channeled Matthew Dillon saying: The switch routes traffic based on its ARP cache. While you cannot easily monitor another port's traffic, you can take over its MAC address and steal its traffic. Cisco VLANs perform a different function. Remember that a logical ethern et segment is typically routed by a single network route. For example, a class C or a subnetted class C. The catalyst allows you to throw machines into different VLAN buckets which, in addition to the better security, allows you to assign separate subnets to each bucket. The switch itself doesn't care, but this can reduce global ARP traffic significantly. Catalysts can have hundreds of ports stuffed into them. (ex-of Cisco Systems) | Kenton A. Hoover | [EMAIL PROTECTED] | | Private Citizen || | San Francisco, California || |= http://www.shockwave.org/~shibumi | | A non-vegetarian anti-abortionist is a contradiction in terms. | | -- Phyllis Schlafly| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
You can hijack the MAC address after the CAM table (not ARP cache) times out for the switches. However, you can't just listen to their traffic unless you're on a span port (and span ports don't always work correctly). VLANing has a number of goals, of which you are listing only one. Another is to permit any net to appear on any switch within the switch fabric. VLANs are usually used in a form that spans multiple switches, not just using VLANs on a single switch. At an installation I put together in India, we used VLANs to allow us to better use IP addresses in a strange physical layout. When we were building out our New Site Architecture at Cisco in San Jose, we used VLANs to cut down the number of routing components necessary and further to take advantage of Layer 3 short-cutting in a number of spots around the buildings. On Wed, 21 Jul 1999 00:33:31 PDT, Sendmail channeled Matthew Dillon saying: The switch routes traffic based on its ARP cache. While you cannot easily monitor another port's traffic, you can take over its MAC address and steal its traffic. Cisco VLANs perform a different function. Remember that a logical ethern et segment is typically routed by a single network route. For example, a class C or a subnetted class C. The catalyst allows you to throw machines into different VLAN buckets which, in addition to the better security, allows you to assign separate subnets to each bucket. The switch itself doesn't care, but this can reduce global ARP traffic significantly. Catalysts can have hundreds of ports stuffed into them. (ex-of Cisco Systems) | Kenton A. Hoover | shib...@marchordie.org | | Private Citizen || | San Francisco, California || |= http://www.shockwave.org/~shibumi | | A non-vegetarian anti-abortionist is a contradiction in terms. | | -- Phyllis Schlafly| To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
Perhaps I'm missing something obvious, but since switches forward packets selectively per port, I would think it would be hard to sniff packets on any port, w/o administrative access to the switch to tell it to mirror data to a different port. ie, if I'm plugged into port 1, I can't see traffic on a switch on port 2 except for broadcast traffic... On Tue, 20 Jul 1999, Modred wrote: On Tue, 20 Jul 1999, Vincent Poy wrote: No idea but it seems like the people who sold the Cisco switches atleast claimed that each port is supposed to be secure to prevent packet sniffing by people on the other ports... Perhaps they were touting 'VLANs'? I can see seperate/many, logical networks configured across one/few physical ports via a VLAN being relatively secure (VLANs can consist of a single port, and each VLAN is it's own subnet). (Is this freebsd-net-ish?) Later, --mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
:Perhaps I'm missing something obvious, but since switches forward packets :selectively per port, I would think it would be hard to sniff packets on :any port, w/o administrative access to the switch to tell it to mirror :data to a different port. : :ie, if I'm plugged into port 1, I can't see traffic on a switch on port 2 :except for broadcast traffic... The switch routes traffic based on its ARP cache. While you cannot easily monitor another port's traffic, you can take over its MAC address and steal its traffic. Cisco VLANs perform a different function. Remember that a logical ethernet segment is typically routed by a single network route. For example, a class C or a subnetted class C. The catalyst allows you to throw machines into different VLAN buckets which, in addition to the better security, allows you to assign separate subnets to each bucket. The switch itself doesn't care, but this can reduce global ARP traffic significantly. Catalysts can have hundreds of ports stuffed into them. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Wed, 21 Jul 1999, Matthew Dillon wrote: :Perhaps I'm missing something obvious, but since switches forward packets :selectively per port, I would think it would be hard to sniff packets on :any port, w/o administrative access to the switch to tell it to mirror :data to a different port. : :ie, if I'm plugged into port 1, I can't see traffic on a switch on port 2 :except for broadcast traffic... The switch routes traffic based on its ARP cache. While you cannot easily monitor another port's traffic, you can take over its MAC address and steal its traffic. No idea, all I know is that people on our LAN without changing MAC addresses can see all traffic going on the LAN. Even from our FreeBSD box with trafshow, we can see traffic that is destined for the global net from the modem dialups. Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
No idea, all I know is that people on our LAN without changing MAC addresses can see all traffic going on the LAN. Even from our FreeBSD box with trafshow, we can see traffic that is destined for the global net from the modem dialups. Then either there is a hub between your net and the switch, or the switch is badly misconfigured. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
Then either there is a hub between your net and the switch, or the switch is badly misconfigured. Well, the switch came out of the box and just had the default setup It just has a IP assigned to it... And there is no hub between the net and the switch since all the modem pools are each on their own port. If the switch "just has the default setup" I would recommend that somebody sit down and read the manual and try to *understand* what is happening - probably also try to experiment a bit with the switch configuration. Because what you're seeing is definitely not normal. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Wed, 21 Jul 1999, Matthew Dillon wrote: :Perhaps I'm missing something obvious, but since switches forward packets :selectively per port, I would think it would be hard to sniff packets on :any port, w/o administrative access to the switch to tell it to mirror :data to a different port. : :ie, if I'm plugged into port 1, I can't see traffic on a switch on port 2 :except for broadcast traffic... The switch routes traffic based on its ARP cache. While you cannot easily monitor another port's traffic, you can take over its MAC address and steal its traffic. Well, this is wy past the trivial part. It certainly seems that you would have to have a lot of information from another source to be able to do this. I guess I'll I'm saying is that if you have a switch sitting there, and you're plugged into it, you're not going to be able to just fire up tcpdump and see much more than ethernet broadcasts, and IP broadcast traffic, and of course, traffic from and to your port... At least, not w/o what appears to be mucho work. And back to your regularly scheduled -hackers... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Wed, 21 Jul 1999 [EMAIL PROTECTED] wrote: Then either there is a hub between your net and the switch, or the switch is badly misconfigured. Well, the switch came out of the box and just had the default setup It just has a IP assigned to it... And there is no hub between the net and the switch since all the modem pools are each on their own port. If the switch "just has the default setup" I would recommend that somebody sit down and read the manual and try to *understand* what is happening - probably also try to experiment a bit with the switch configuration. Because what you're seeing is definitely not normal. Well, the manual doesn't guarantee security either The only thing the switch seems to do is give dedicated bandwidth to each port but no one knows if it's a true switch since someone did mention a CableTron switch being nothing but a bundled of hub ports inside grouped together. Also, the management feature isn't suppose to affect data from being seen on all the ports. Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
If the switch "just has the default setup" I would recommend that somebody sit down and read the manual and try to *understand* what is happening - probably also try to experiment a bit with the switch configuration. Because what you're seeing is definitely not normal. Well, the manual doesn't guarantee security either This is true, and was well pointed out by Jan B. Koum. But most of the time the switch will nicely isolate traffic for you. However, if you are connected to what Cisco calls a "group switch module" (on a Cisco switch, of course) you need to be aware of what this really is. A Cisco "group switch" module is in reality a number of hubs (3 or 4) on one card. All ports in the same group will see the same traffic, of course. The only thing the switch seems to do is give dedicated bandwidth to each port but no one knows if it's a true switch since someone did mention a CableTron switch being nothing but a bundled of hub ports inside grouped together. You need to make up your mind. Do you have a Cisco Catalyst switch or a Cabletron switch? Since earlier in this thread you said "we don't know which port goes to what on the Catalyst" I assumed that you were indeed using a Cisco Catalyst. Since I don't know anything about Cabletron, I'll let others speak about that. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Tue, 20 Jul 1999, Jaye Mathisen wrote: Perhaps I'm missing something obvious, but since switches forward packets selectively per port, I would think it would be hard to sniff packets on any port, w/o administrative access to the switch to tell it to mirror data to a different port. You can definitely do it with ARP games. I was playing with this and I ran into an interesting phenomena -- perhaps someone more familiar with the workings of switches could explain. What I was doing was having one machine send out bogus ARPs to all the machines on the network except the victim, telling them the victim was at a nonexistent MAC address. The switch would broadcast packets for this MAC address because it didn't know where it was. I would then rewrite the MAC address in the ethernet header and put the packet back on the wire so the victim would get it. Interesting part was, not only did traffic for my bogus MAC get broadcast, apparently so did ALL traffic. !! This brought the 100Mbit switch to its knees. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Wed, 21 Jul 1999, Modred wrote: On Wed, 21 Jul 1999, Vincent Poy wrote: Speaking about Layer 2 and layer 3. Does the Cisco Catalyst 2924XL and the HP ProCurve 2424M and 4000M switches fall under Layer 3 or just layer 2? Cisco, yes... HP, no clue (perhaps you could check their website). 2900XL Architecture Notes: http://www.cisco.com/warp/public/cc/cisco/mkt/switch/cat/2900xl \ /tech/malbu_wp.htmhttp://www.cisco.com/warp/public/cc/cisco/mkt/ \ switch/cat/2900xl/tech/malbu_wp.htm 2900XL Management Guide: http://www.cisco.com/univercd/cc/td/doc/product/lan/c2900xl/ \ 29_35sa6/index.htm IOW, RTFM. I did, it gets interesting though since if it was a true Level 3 switch, it sure seems to perform more like a Level 2. Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
Perhaps I'm missing something obvious, but since switches forward packets selectively per port, I would think it would be hard to sniff packets on any port, w/o administrative access to the switch to tell it to mirror data to a different port. ie, if I'm plugged into port 1, I can't see traffic on a switch on port 2 except for broadcast traffic... On Tue, 20 Jul 1999, Modred wrote: On Tue, 20 Jul 1999, Vincent Poy wrote: No idea but it seems like the people who sold the Cisco switches atleast claimed that each port is supposed to be secure to prevent packet sniffing by people on the other ports... Perhaps they were touting 'VLANs'? I can see seperate/many, logical networks configured across one/few physical ports via a VLAN being relatively secure (VLANs can consist of a single port, and each VLAN is it's own subnet). (Is this freebsd-net-ish?) Later, --mike To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
:Perhaps I'm missing something obvious, but since switches forward packets :selectively per port, I would think it would be hard to sniff packets on :any port, w/o administrative access to the switch to tell it to mirror :data to a different port. : :ie, if I'm plugged into port 1, I can't see traffic on a switch on port 2 :except for broadcast traffic... The switch routes traffic based on its ARP cache. While you cannot easily monitor another port's traffic, you can take over its MAC address and steal its traffic. Cisco VLANs perform a different function. Remember that a logical ethernet segment is typically routed by a single network route. For example, a class C or a subnetted class C. The catalyst allows you to throw machines into different VLAN buckets which, in addition to the better security, allows you to assign separate subnets to each bucket. The switch itself doesn't care, but this can reduce global ARP traffic significantly. Catalysts can have hundreds of ports stuffed into them. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Wed, 21 Jul 1999, Matthew Dillon wrote: :Perhaps I'm missing something obvious, but since switches forward packets :selectively per port, I would think it would be hard to sniff packets on :any port, w/o administrative access to the switch to tell it to mirror :data to a different port. : :ie, if I'm plugged into port 1, I can't see traffic on a switch on port 2 :except for broadcast traffic... The switch routes traffic based on its ARP cache. While you cannot easily monitor another port's traffic, you can take over its MAC address and steal its traffic. No idea, all I know is that people on our LAN without changing MAC addresses can see all traffic going on the LAN. Even from our FreeBSD box with trafshow, we can see traffic that is destined for the global net from the modem dialups. Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
No idea, all I know is that people on our LAN without changing MAC addresses can see all traffic going on the LAN. Even from our FreeBSD box with trafshow, we can see traffic that is destined for the global net from the modem dialups. Then either there is a hub between your net and the switch, or the switch is badly misconfigured. Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Wed, 21 Jul 1999 sth...@nethelp.no wrote: No idea, all I know is that people on our LAN without changing MAC addresses can see all traffic going on the LAN. Even from our FreeBSD box with trafshow, we can see traffic that is destined for the global net from the modem dialups. Then either there is a hub between your net and the switch, or the switch is badly misconfigured. Well, the switch came out of the box and just had the default setup It just has a IP assigned to it... And there is no hub between the net and the switch since all the modem pools are each on their own port. Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
Then either there is a hub between your net and the switch, or the switch is badly misconfigured. Well, the switch came out of the box and just had the default setup It just has a IP assigned to it... And there is no hub between the net and the switch since all the modem pools are each on their own port. If the switch just has the default setup I would recommend that somebody sit down and read the manual and try to *understand* what is happening - probably also try to experiment a bit with the switch configuration. Because what you're seeing is definitely not normal. Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Wed, 21 Jul 1999, Matthew Dillon wrote: :Perhaps I'm missing something obvious, but since switches forward packets :selectively per port, I would think it would be hard to sniff packets on :any port, w/o administrative access to the switch to tell it to mirror :data to a different port. : :ie, if I'm plugged into port 1, I can't see traffic on a switch on port 2 :except for broadcast traffic... The switch routes traffic based on its ARP cache. While you cannot easily monitor another port's traffic, you can take over its MAC address and steal its traffic. Well, this is wy past the trivial part. It certainly seems that you would have to have a lot of information from another source to be able to do this. I guess I'll I'm saying is that if you have a switch sitting there, and you're plugged into it, you're not going to be able to just fire up tcpdump and see much more than ethernet broadcasts, and IP broadcast traffic, and of course, traffic from and to your port... At least, not w/o what appears to be mucho work. And back to your regularly scheduled -hackers... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Wed, 21 Jul 1999 sth...@nethelp.no wrote: Then either there is a hub between your net and the switch, or the switch is badly misconfigured. Well, the switch came out of the box and just had the default setup It just has a IP assigned to it... And there is no hub between the net and the switch since all the modem pools are each on their own port. If the switch just has the default setup I would recommend that somebody sit down and read the manual and try to *understand* what is happening - probably also try to experiment a bit with the switch configuration. Because what you're seeing is definitely not normal. Well, the manual doesn't guarantee security either The only thing the switch seems to do is give dedicated bandwidth to each port but no one knows if it's a true switch since someone did mention a CableTron switch being nothing but a bundled of hub ports inside grouped together. Also, the management feature isn't suppose to affect data from being seen on all the ports. Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
If the switch just has the default setup I would recommend that somebody sit down and read the manual and try to *understand* what is happening - probably also try to experiment a bit with the switch configuration. Because what you're seeing is definitely not normal. Well, the manual doesn't guarantee security either This is true, and was well pointed out by Jan B. Koum. But most of the time the switch will nicely isolate traffic for you. However, if you are connected to what Cisco calls a group switch module (on a Cisco switch, of course) you need to be aware of what this really is. A Cisco group switch module is in reality a number of hubs (3 or 4) on one card. All ports in the same group will see the same traffic, of course. The only thing the switch seems to do is give dedicated bandwidth to each port but no one knows if it's a true switch since someone did mention a CableTron switch being nothing but a bundled of hub ports inside grouped together. You need to make up your mind. Do you have a Cisco Catalyst switch or a Cabletron switch? Since earlier in this thread you said we don't know which port goes to what on the Catalyst I assumed that you were indeed using a Cisco Catalyst. Since I don't know anything about Cabletron, I'll let others speak about that. Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
Vincent Poy wrote: Well, the manual doesn't guarantee security either The only thing the switch seems to do is give dedicated bandwidth to each port but no one knows if it's a true switch since someone did mention a CableTron switch being nothing but a bundled of hub ports inside grouped together. Also, the management feature isn't suppose to affect data from being seen on all the ports. Can this be moved off -hackers?, onto perhaps FreeBSD-Hubs? g Or even, back to ye'olde -chat? :-) -Kp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
:Unmanaged layer 2 switches do that, but the intelligent layer 3 switches :certainly don't. Layer 3 switches can be configured to consider 2 physically :adjacent ports to be on completely different networks; they will not even :share broadcast traffic. If you shop carefully, you can even buy switches :where you can configure VLANs based on user authentication, any given :physical port can join a VLAN based on a user login program rather than :port number or MAC or IP address. : :Wes Peters Softweyr LLC :http://softweyr.com/ w...@softweyr.com I would *never* *ever* configure a switch with dynamic VLANs. Not even if my life depended on it. It would be impossible to track down problems. It's hard enough keeping the network topology straight with statically configured VLANs. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Wed, 21 Jul 1999, Wes Peters wrote: Matthew Dillon wrote: :Perhaps I'm missing something obvious, but since switches forward packets :selectively per port, I would think it would be hard to sniff packets on :any port, w/o administrative access to the switch to tell it to mirror :data to a different port. : :ie, if I'm plugged into port 1, I can't see traffic on a switch on port 2 :except for broadcast traffic... The switch routes traffic based on its ARP cache. While you cannot easily monitor another port's traffic, you can take over its MAC address and steal its traffic. Unmanaged layer 2 switches do that, but the intelligent layer 3 switches certainly don't. Layer 3 switches can be configured to consider 2 physically adjacent ports to be on completely different networks; they will not even share broadcast traffic. If you shop carefully, you can even buy switches where you can configure VLANs based on user authentication, any given physical port can join a VLAN based on a user login program rather than port number or MAC or IP address. Speaking about Layer 2 and layer 3. Does the Cisco Catalyst 2924XL and the HP ProCurve 2424M and 4000M switches fall under Layer 3 or just layer 2? Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Tue, 20 Jul 1999, Jaye Mathisen wrote: Perhaps I'm missing something obvious, but since switches forward packets selectively per port, I would think it would be hard to sniff packets on any port, w/o administrative access to the switch to tell it to mirror data to a different port. You can definitely do it with ARP games. I was playing with this and I ran into an interesting phenomena -- perhaps someone more familiar with the workings of switches could explain. What I was doing was having one machine send out bogus ARPs to all the machines on the network except the victim, telling them the victim was at a nonexistent MAC address. The switch would broadcast packets for this MAC address because it didn't know where it was. I would then rewrite the MAC address in the ethernet header and put the packet back on the wire so the victim would get it. Interesting part was, not only did traffic for my bogus MAC get broadcast, apparently so did ALL traffic. !! This brought the 100Mbit switch to its knees. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
That's a option too... Only problem is that can take forever. :-) Yeah, I've noticed the 'sync-up time' takes quite awhile on a Catalyst running 100Mbps. that is due to the spanning tree algorithm being run. takes about 30 seconds. you can disable this with spantree portfast applied to the port. be careful. ;) jmb To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Wed, 21 Jul 1999, Vincent Poy wrote: Speaking about Layer 2 and layer 3. Does the Cisco Catalyst 2924XL and the HP ProCurve 2424M and 4000M switches fall under Layer 3 or just layer 2? Cisco, yes... HP, no clue (perhaps you could check their website). 2900XL Architecture Notes: http://www.cisco.com/warp/public/cc/cisco/mkt/switch/cat/2900xl \ /tech/malbu_wp.htmhttp://www.cisco.com/warp/public/cc/cisco/mkt/ \ switch/cat/2900xl/tech/malbu_wp.htm 2900XL Management Guide: http://www.cisco.com/univercd/cc/td/doc/product/lan/c2900xl/ \ 29_35sa6/index.htm IOW, RTFM. Later, --mike To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Wed, 21 Jul 1999, Modred wrote: On Wed, 21 Jul 1999, Vincent Poy wrote: Speaking about Layer 2 and layer 3. Does the Cisco Catalyst 2924XL and the HP ProCurve 2424M and 4000M switches fall under Layer 3 or just layer 2? Cisco, yes... HP, no clue (perhaps you could check their website). 2900XL Architecture Notes: http://www.cisco.com/warp/public/cc/cisco/mkt/switch/cat/2900xl \ /tech/malbu_wp.htmhttp://www.cisco.com/warp/public/cc/cisco/mkt/ \ switch/cat/2900xl/tech/malbu_wp.htm 2900XL Management Guide: http://www.cisco.com/univercd/cc/td/doc/product/lan/c2900xl/ \ 29_35sa6/index.htm IOW, RTFM. I did, it gets interesting though since if it was a true Level 3 switch, it sure seems to perform more like a Level 2. Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
Vincent Poy wrote: On Wed, 21 Jul 1999, Modred wrote: On Wed, 21 Jul 1999, Vincent Poy wrote: Speaking about Layer 2 and layer 3. Does the Cisco Catalyst 2924XL and the HP ProCurve 2424M and 4000M switches fall under Layer 3 or just layer 2? Cisco, yes... HP, no clue (perhaps you could check their website). IOW, RTFM. Wouldn't that be RTFW? ;^) I did, it gets interesting though since if it was a true Level 3 switch, it sure seems to perform more like a Level 2. Snort Wait'll you see IP routing at 12,000,000 packets per second. ;^) Layer 3 switches are not inherently slower than Layer 2, if they're built right. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Mon, 19 Jul 1999, Modred wrote: On Sat, 17 Jul 1999, Vincent Poy wrote: BITCHMODE By reading the man page? The manpage doesn't really say anything about how to use ttcp... I don't think manpage useage is -hackers-esque. I know. There is no ttcp binary anywhere on either my -CURRENT, 3.2-RELEASE and 3.1-RELEASE systems. Ever hear of ports? Or is 'how to use the ports collection' suddenly -hackers material? That, and .sig files that contain more relevant bits than the sender's posts... I know there is ports. But you are missing the boat. There is a ttcp manpage by default and that has nothing to do with ttcp in the ports. In fact, ttcp wasn't in the ports tree until the last few months. Oh, and I'd appreciate it if you could refrain from quoting this entire message to simply say, 'Interesting'... Thanks. I don't post one word replies. And if you wanted to flame, atleast learn to do it privately... Not to mention that atleast my posts were FreeBSD related, yours is like 180 degrees off-topic. /BITCHMODE Later, --mike Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Mon, 19 Jul 1999, Modred wrote: I'm not sure if it shows the mac address of the cisco's port or the actual device connected to it... You see the MAC of the switch's port. It's been too long since I've played on a Catalyst... but what does 'sh arp' display? Any arp - port - host correlations? Good luck... :) Even if it did show the arp of the actual host, it's useless if it doesn't show the IP of the device connected to it since how will one know what device is what. That's a option too... Only problem is that can take forever. :-) Yeah, I've noticed the 'sync-up time' takes quite awhile on a Catalyst running 100Mbps. It's pretty fast... Just it seems like the switch by default isn't like as secure as they say it is. People on other ports can't still sniff packets on the LAN. Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
You see the MAC of the switch's port. It's been too long since I've played on a Catalyst... but what does 'sh arp' display? Any arp - port - host correlations? Good luck... :) Even if it did show the arp of the actual host, it's useless if it doesn't show the IP of the device connected to it since how will one know what device is what. As long as the hosts are using TCP/IP to communicate, you should be able to get the IP to MAC address mapping from the ARP table of any host (or router) connected to the same segment. You may have to look at the ARP tables from several hosts (or use a broadcast ping) to get all the mappings. Isn't this rather obvious? Yeah, I've noticed the 'sync-up time' takes quite awhile on a Catalyst running 100Mbps. It's pretty fast... Just it seems like the switch by default isn't like as secure as they say it is. People on other ports can't still sniff packets on the LAN. Ciscos have a 30 second delay when you connect something to a switch port. This is given by the spanning tree protocol. If you want this to go faster, turn off the spanning tree protocol on that port (OK if you can guarantee no loops in the network from that port). Not sure what you mean by "the switch by default isn't like as secure as they say it is". A switch is a bridge, and will isolate traffic between ports. However, broadcast (and in many cases multicast) traffic will be sent on all ports. Also, if the MAC address tables on the switch fills up, any traffic from a *new* MAC address will be sent on all ports. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Tue, 20 Jul 1999 [EMAIL PROTECTED] wrote: You see the MAC of the switch's port. It's been too long since I've played on a Catalyst... but what does 'sh arp' display? Any arp - port - host correlations? Good luck... :) Even if it did show the arp of the actual host, it's useless if it doesn't show the IP of the device connected to it since how will one know what device is what. As long as the hosts are using TCP/IP to communicate, you should be able to get the IP to MAC address mapping from the ARP table of any host (or router) connected to the same segment. You may have to look at the ARP tables from several hosts (or use a broadcast ping) to get all the mappings. Isn't this rather obvious? That would only work if the machines are on the hub but if each device is on a dedicated port on the switch of it's own, it's not supposed to see the other machines... Atleast we can't see the other machines MAC with netstat -r in FreeBSD. Yeah, I've noticed the 'sync-up time' takes quite awhile on a Catalyst running 100Mbps. It's pretty fast... Just it seems like the switch by default isn't like as secure as they say it is. People on other ports can't still sniff packets on the LAN. Ciscos have a 30 second delay when you connect something to a switch port. This is given by the spanning tree protocol. If you want this to go faster, turn off the spanning tree protocol on that port (OK if you can guarantee no loops in the network from that port). I think this is true with any switch that has the STP feature. Not sure what you mean by "the switch by default isn't like as secure as they say it is". A switch is a bridge, and will isolate traffic between ports. However, broadcast (and in many cases multicast) traffic will be sent on all ports. Also, if the MAC address tables on the switch fills up, any traffic from a *new* MAC address will be sent on all ports. No idea but it seems like the people who sold the Cisco switches atleast claimed that each port is supposed to be secure to prevent packet sniffing by people on the other ports... Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Tue, 20 Jul 1999, Vincent Poy wrote: No idea but it seems like the people who sold the Cisco switches atleast claimed that each port is supposed to be secure to prevent packet sniffing by people on the other ports... Perhaps they were touting 'VLANs'? I can see seperate/many, logical networks configured across one/few physical ports via a VLAN being relatively secure (VLANs can consist of a single port, and each VLAN is it's own subnet). (Is this freebsd-net-ish?) Later, --mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Mon, 19 Jul 1999, Modred wrote: On Sat, 17 Jul 1999, Vincent Poy wrote: BITCHMODE By reading the man page? The manpage doesn't really say anything about how to use ttcp... I don't think manpage useage is -hackers-esque. I know. There is no ttcp binary anywhere on either my -CURRENT, 3.2-RELEASE and 3.1-RELEASE systems. Ever hear of ports? Or is 'how to use the ports collection' suddenly -hackers material? That, and .sig files that contain more relevant bits than the sender's posts... I know there is ports. But you are missing the boat. There is a ttcp manpage by default and that has nothing to do with ttcp in the ports. In fact, ttcp wasn't in the ports tree until the last few months. Oh, and I'd appreciate it if you could refrain from quoting this entire message to simply say, 'Interesting'... Thanks. I don't post one word replies. And if you wanted to flame, atleast learn to do it privately... Not to mention that atleast my posts were FreeBSD related, yours is like 180 degrees off-topic. /BITCHMODE Later, --mike Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Mon, 19 Jul 1999, Modred wrote: I'm not sure if it shows the mac address of the cisco's port or the actual device connected to it... You see the MAC of the switch's port. It's been too long since I've played on a Catalyst... but what does 'sh arp' display? Any arp - port - host correlations? Good luck... :) Even if it did show the arp of the actual host, it's useless if it doesn't show the IP of the device connected to it since how will one know what device is what. That's a option too... Only problem is that can take forever. :-) Yeah, I've noticed the 'sync-up time' takes quite awhile on a Catalyst running 100Mbps. It's pretty fast... Just it seems like the switch by default isn't like as secure as they say it is. People on other ports can't still sniff packets on the LAN. Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
You see the MAC of the switch's port. It's been too long since I've played on a Catalyst... but what does 'sh arp' display? Any arp - port - host correlations? Good luck... :) Even if it did show the arp of the actual host, it's useless if it doesn't show the IP of the device connected to it since how will one know what device is what. As long as the hosts are using TCP/IP to communicate, you should be able to get the IP to MAC address mapping from the ARP table of any host (or router) connected to the same segment. You may have to look at the ARP tables from several hosts (or use a broadcast ping) to get all the mappings. Isn't this rather obvious? Yeah, I've noticed the 'sync-up time' takes quite awhile on a Catalyst running 100Mbps. It's pretty fast... Just it seems like the switch by default isn't like as secure as they say it is. People on other ports can't still sniff packets on the LAN. Ciscos have a 30 second delay when you connect something to a switch port. This is given by the spanning tree protocol. If you want this to go faster, turn off the spanning tree protocol on that port (OK if you can guarantee no loops in the network from that port). Not sure what you mean by the switch by default isn't like as secure as they say it is. A switch is a bridge, and will isolate traffic between ports. However, broadcast (and in many cases multicast) traffic will be sent on all ports. Also, if the MAC address tables on the switch fills up, any traffic from a *new* MAC address will be sent on all ports. Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Tue, 20 Jul 1999 sth...@nethelp.no wrote: You see the MAC of the switch's port. It's been too long since I've played on a Catalyst... but what does 'sh arp' display? Any arp - port - host correlations? Good luck... :) Even if it did show the arp of the actual host, it's useless if it doesn't show the IP of the device connected to it since how will one know what device is what. As long as the hosts are using TCP/IP to communicate, you should be able to get the IP to MAC address mapping from the ARP table of any host (or router) connected to the same segment. You may have to look at the ARP tables from several hosts (or use a broadcast ping) to get all the mappings. Isn't this rather obvious? That would only work if the machines are on the hub but if each device is on a dedicated port on the switch of it's own, it's not supposed to see the other machines... Atleast we can't see the other machines MAC with netstat -r in FreeBSD. Yeah, I've noticed the 'sync-up time' takes quite awhile on a Catalyst running 100Mbps. It's pretty fast... Just it seems like the switch by default isn't like as secure as they say it is. People on other ports can't still sniff packets on the LAN. Ciscos have a 30 second delay when you connect something to a switch port. This is given by the spanning tree protocol. If you want this to go faster, turn off the spanning tree protocol on that port (OK if you can guarantee no loops in the network from that port). I think this is true with any switch that has the STP feature. Not sure what you mean by the switch by default isn't like as secure as they say it is. A switch is a bridge, and will isolate traffic between ports. However, broadcast (and in many cases multicast) traffic will be sent on all ports. Also, if the MAC address tables on the switch fills up, any traffic from a *new* MAC address will be sent on all ports. No idea but it seems like the people who sold the Cisco switches atleast claimed that each port is supposed to be secure to prevent packet sniffing by people on the other ports... Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Tue, 20 Jul 1999, Vincent Poy wrote: No idea but it seems like the people who sold the Cisco switches atleast claimed that each port is supposed to be secure to prevent packet sniffing by people on the other ports... Perhaps they were touting 'VLANs'? I can see seperate/many, logical networks configured across one/few physical ports via a VLAN being relatively secure (VLANs can consist of a single port, and each VLAN is it's own subnet). (Is this freebsd-net-ish?) Later, --mike To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Tue, 20 Jul 1999, Modred wrote: On Tue, 20 Jul 1999, Vincent Poy wrote: No idea but it seems like the people who sold the Cisco switches atleast claimed that each port is supposed to be secure to prevent packet sniffing by people on the other ports... Perhaps they were touting 'VLANs'? I can see seperate/many, logical networks configured across one/few physical ports via a VLAN being relatively secure (VLANs can consist of a single port, and each VLAN is it's own subnet). VLAN could be it... (Is this freebsd-net-ish?) Ofcourse, remember the original discussion is ethernet performance between two FreeBSD boxes. Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
At 11:40 AM 18/07/99 -0700, you wrote: Tim Baird wrote: I hope everyone is benefitting by these simple facts *chuckle* "Simple facts.." You sound like my physics professor. I for one am benefitting very much from the discussion. I got hired at my current job as a software person, but I have a background in hardware so I try and make it into the NOC every excuse I get (promotability, don't you know). It always helps if sound like I have a vague idea what I'm talking about. :) I'll take that as a compliment ;) I just made up my first ethernet cables the other day, and learned an interesting tidbit that I'm sure is beyond elementary to most of you, but may benefit someone else. What I was told is that the reason Cat 5 cable is so much more efficient is that each of the 4 pairs of wire is twisted at a different rate. This helps reduce the possibility of frequency synchronization for the EM fields the pairs create. Your description (what you were told) here is incorrectthe number of twists in a cable had **NO** effect on the spectral content of the cunducted signal or resulting radiated/induced signal.to do so would require the conductors to have a nonlinear conduction characteristic which they most assuredly do not (for all practical purposes). The design of the cable is such that adjacent pairs have as little effectively parallel length as possible. Obviously, the currents in the wires share the same axis, so the magnetic coupling is only reduced by the fact that interfering magnetic fields will tend to induce a common mode current in adjacent pairs...particulary since both conductors in the receiving cable pair --on average-- are exposed equally, the idea in "randomizing" the twists is to reduce the capacitive coupling as much as possible. Capacitive coupling is a more localized effect, and thrives when conductors share a common plane in close proximity...this is why capacitors are designed as two metal plates very close together..the electric field between the plates (conductors) is much higher than if they were perpendicular...or not nicely parallel. I hope this clarifies the situation :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999 [EMAIL PROTECTED] wrote: Please read the documentation. This is hard since the actual machines and switches are almost 6000 miles away from me and the last time I checked, it didn't come with manuals. I know my way around the Cisco routers but the switches is still a mystery... All of the Cisco documentation is available on WWW. Use it! I known it is but I was talking about the printed copy... Start at http://www.cisco.com/, follow the "Technical documents" and then the "Documentation home page" link. The manual for your switch is available, that's where I found the "show mac-address-table" command. Atleast the Cisco documentation is good... The Ascend documentation sucks big time since none of the stuff in the manual matches the actual OS on the system. Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999, Jonathan M. Bresler wrote: I guess I forgot about the overhead. I've tested between two FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL Switch Full Duplex and never seen anything close to the speeds. using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp cards (all from memory), i routinely get TCP_STREAM to pushd 94Mbps. i use these machines for stressing every else we have at work. Hmmm, has anyone tried a full duplex test before? Since it seems like the bottleneck is really the speed of the disks.. Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Mon, 19 Jul 1999, Reinier Bezuidenhout wrote: Hi ... We have previously done many network performance tests for our products running on FreeBSD ... We have found that when ever there is disk accessing involved, it is not a good idea to look at the transfer figures. We did tests with ftp and is was slow (compared to only memory generated data e.g. ttcp) yeah, I guess all tests should be done without requiring the use of the disk. 1. If you want to test the network speed ... use ttcp or something that generates the data and doesn't read it from disk. ttcp works. The only problem is when I tried it in both directions, at once. the total becomes 11.xMbytes/sec total as opposed to 9.4Mbytes/sec when doing it in one direction only. 2. When doing full-duplex and using fxp cards, stay away from X-over cables ... use a full-duplex switch etc. ... the fxp cards are not made to work with X-over cables (as far as I know - ala Intel spec) note ... only for full-duplex tests. Does anyone actually use X-over cables for 100Mbps Full Duplex since 3Com said CrossOver cables are not rated for 100Mbps or something even though it's Cat5. Actually, in the older Intel docs for the Pro100B, it does say to connect using X-over cable to the switch. We have done tests in full-duplex with non Intel cards (because we did not have a switch at that time :)) and with max size packets we got around 188.00 Mbps using the de0 driver. Pretty interesting. How did you do the full duplex tests? Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] On Sun, 18 Jul 1999, Jonathan M. Bresler wrote: I guess I forgot about the overhead. I've tested between two FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL Switch Full Duplex and never seen anything close to the speeds. using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp cards (all from memory), i routinely get TCP_STREAM to pushd 94Mbps. i use these machines for stressing every else we have at work. Hmmm, has anyone tried a full duplex test before? Since it seems like the bottleneck is really the speed of the disks.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
Hi .. 1. If you want to test the network speed ... use ttcp or something that generates the data and doesn't read it from disk. ttcp works. The only problem is when I tried it in both directions, at once. the total becomes 11.xMbytes/sec total as opposed to 9.4Mbytes/sec when doing it in one direction only. If the devices are set at full-duplex then you are looking at something else ... the standard size for ttcp packets is 8k ... maybe the switch etc. that you are connected to doesn't handle fragmented packets very well. But ... what it rather seems like .. is that the devices are not in full-duplex mode generating a lot of collisions. After a test with transfers in both directions .. check the number of collisions with "netstat -in". If the number of collisions is not high .. - wait a moment ... are you using ttcp with tcp or udp option ... if you are using tcp (the default) then when transfering data you have acks going in both directions which could cause collisions on a full-duplex line ... try the same with the -u option for UDP. Check our setup below ... I'll explain some things there. Also check with "netstat -sn" to see if there are any other counters that increase with the full-duplex transfers. 2. When doing full-duplex and using fxp cards, stay away from X-over cables ... use a full-duplex switch etc. ... the fxp cards are not made to work with X-over cables (as far as I know - ala Intel spec) note ... only for full-duplex tests. Does anyone actually use X-over cables for 100Mbps Full Duplex since 3Com said CrossOver cables are not rated for 100Mbps or something even though it's Cat5. Actually, in the older Intel docs for the Pro100B, it does say to connect using X-over cable to the switch. Yes ... to a switch maybe ... but not fxp to fxp ... when transfering small packets .. you get a lot of "device timeouts". We have done tests in full-duplex with non Intel cards (because we did not have a switch at that time :)) and with max size packets we got around 188.00 Mbps using the de0 driver. Pretty interesting. How did you do the full duplex tests? I'll describe the setup briefly ... :) We had 3 machines two PII-400 as the generators and a PII-400 as the machine in the middle ... So we have a setup that looks like this ... - -- - | Gen 1 |-| Router |-| Gen 2 | - -- - Now .. here is a trick ... add entries manually in the Router's tables to simulate machines on each side that "does not exist". The reason for this is that we don't want the machines on the side to be generating AND excepting packets ... we just want them to generate packets at max network rate and nothing else. We then start a ttcp on both sides to the "non existing" machines. This means the router will be forwaring packets it receives without any machines having to be there because of the entries in the routing table. (we did this because we did not have another two fast machines at that time, but we did check the packets to make sure everything goes through and are not dropped etc. - it was some time ago :) ) We start ttcp with the following command ttcp -t -s -u -p 7000 -n nice large number -l 1472 10.0.0.1 the size of 1472 generates nice 1514 size UDP packets :) We then let the test run ... and check the throughput ... We used CAT5 X-over cables ... Hopw this helps Reinier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Mon, 19 Jul 1999, Reinier Bezuidenhout wrote: Hi .. 1. If you want to test the network speed ... use ttcp or something that generates the data and doesn't read it from disk. ttcp works. The only problem is when I tried it in both directions, at once. the total becomes 11.xMbytes/sec total as opposed to 9.4Mbytes/sec when doing it in one direction only. If the devices are set at full-duplex then you are looking at something else ... the standard size for ttcp packets is 8k ... maybe the switch etc. that you are connected to doesn't handle fragmented packets very well. Hmmm, the thing is we replaced the cables with pre-made ones that go directly from the machines to the Cisco Catalyst 2924XL switch. Ofcourse, the switch is on 10/100 Auto-negotiation. But ... what it rather seems like .. is that the devices are not in full-duplex mode generating a lot of collisions. After a test with transfers in both directions .. check the number of collisions with "netstat -in". If the number of collisions is not high .. - wait a moment ... are you using ttcp with tcp or udp option ... if you are using tcp (the default) then when transfering data you have acks going in both directions which could cause collisions on a full-duplex line ... try the same with the -u option for UDP. Check our setup below ... I'll explain some things there. I was using ttcp in two separate instances, one for send and one for receive between the same two machines. I did ttcp -r -s and the other end was ttcp -s -r. Also check with "netstat -sn" to see if there are any other counters that increase with the full-duplex transfers. Will do that. 2. When doing full-duplex and using fxp cards, stay away from X-over cables ... use a full-duplex switch etc. ... the fxp cards are not made to work with X-over cables (as far as I know - ala Intel spec) note ... only for full-duplex tests. Does anyone actually use X-over cables for 100Mbps Full Duplex since 3Com said CrossOver cables are not rated for 100Mbps or something even though it's Cat5. Actually, in the older Intel docs for the Pro100B, it does say to connect using X-over cable to the switch. Yes ... to a switch maybe ... but not fxp to fxp ... when transfering small packets .. you get a lot of "device timeouts". I thought from a fxp to a fxp, you will need a x-over since a straight-wire won't work. We have done tests in full-duplex with non Intel cards (because we did not have a switch at that time :)) and with max size packets we got around 188.00 Mbps using the de0 driver. Pretty interesting. How did you do the full duplex tests? I'll describe the setup briefly ... :) We had 3 machines two PII-400 as the generators and a PII-400 as the machine in the middle ... So we have a setup that looks like this ... - -- - | Gen 1 |-| Router |-| Gen 2 | - -- - Now .. here is a trick ... add entries manually in the Router's tables to simulate machines on each side that "does not exist". The reason for this is that we don't want the machines on the side to be generating AND excepting packets ... we just want them to generate packets at max network rate and nothing else. We then start a ttcp on both sides to the "non existing" machines. This means the router will be forwaring packets it receives without any machines having to be there because of the entries in the routing table. (we did this because we did not have another two fast machines at that time, but we did check the packets to make sure everything goes through and are not dropped etc. - it was some time ago :) ) We start ttcp with the following command ttcp -t -s -u -p 7000 -n nice large number -l 1472 10.0.0.1 the size of 1472 generates nice 1514 size UDP packets :) We then let the test run ... and check the throughput ... We used CAT5 X-over cables ... Hopw this helps Ah, I guess you didn't test it on a actual network that's connected to the world and also it was a direct connection between the machines rather than through a switch that can be congested. Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
At 11:40 AM 18/07/99 -0700, you wrote: Tim Baird wrote: I hope everyone is benefitting by these simple facts *chuckle* Simple facts.. You sound like my physics professor. I for one am benefitting very much from the discussion. I got hired at my current job as a software person, but I have a background in hardware so I try and make it into the NOC every excuse I get (promotability, don't you know). It always helps if sound like I have a vague idea what I'm talking about. :) I'll take that as a compliment ;) I just made up my first ethernet cables the other day, and learned an interesting tidbit that I'm sure is beyond elementary to most of you, but may benefit someone else. What I was told is that the reason Cat 5 cable is so much more efficient is that each of the 4 pairs of wire is twisted at a different rate. This helps reduce the possibility of frequency synchronization for the EM fields the pairs create. Your description (what you were told) here is incorrectthe number of twists in a cable had **NO** effect on the spectral content of the cunducted signal or resulting radiated/induced signal.to do so would require the conductors to have a nonlinear conduction characteristic which they most assuredly do not (for all practical purposes). The design of the cable is such that adjacent pairs have as little effectively parallel length as possible. Obviously, the currents in the wires share the same axis, so the magnetic coupling is only reduced by the fact that interfering magnetic fields will tend to induce a common mode current in adjacent pairs...particulary since both conductors in the receiving cable pair --on average-- are exposed equally, the idea in randomizing the twists is to reduce the capacitive coupling as much as possible. Capacitive coupling is a more localized effect, and thrives when conductors share a common plane in close proximity...this is why capacitors are designed as two metal plates very close together..the electric field between the plates (conductors) is much higher than if they were perpendicular...or not nicely parallel. I hope this clarifies the situation :) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999 sth...@nethelp.no wrote: Please read the documentation. This is hard since the actual machines and switches are almost 6000 miles away from me and the last time I checked, it didn't come with manuals. I know my way around the Cisco routers but the switches is still a mystery... All of the Cisco documentation is available on WWW. Use it! I known it is but I was talking about the printed copy... Start at http://www.cisco.com/, follow the Technical documents and then the Documentation home page link. The manual for your switch is available, that's where I found the show mac-address-table command. Atleast the Cisco documentation is good... The Ascend documentation sucks big time since none of the stuff in the manual matches the actual OS on the system. Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999, Jonathan M. Bresler wrote: I guess I forgot about the overhead. I've tested between two FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL Switch Full Duplex and never seen anything close to the speeds. using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp cards (all from memory), i routinely get TCP_STREAM to pushd 94Mbps. i use these machines for stressing every else we have at work. Hmmm, has anyone tried a full duplex test before? Since it seems like the bottleneck is really the speed of the disks.. Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
Hi ... We have previously done many network performance tests for our products running on FreeBSD ... We have found that when ever there is disk accessing involved, it is not a good idea to look at the transfer figures. We did tests with ftp and is was slow (compared to only memory generated data e.g. ttcp) 1. If you want to test the network speed ... use ttcp or something that generates the data and doesn't read it from disk. 2. When doing full-duplex and using fxp cards, stay away from X-over cables ... use a full-duplex switch etc. ... the fxp cards are not made to work with X-over cables (as far as I know - ala Intel spec) note ... only for full-duplex tests. We have done tests in full-duplex with non Intel cards (because we did not have a switch at that time :)) and with max size packets we got around 188.00 Mbps using the de0 driver. Cheers Reinier On Sun, 18 Jul 1999, Jonathan M. Bresler wrote: I guess I forgot about the overhead. I've tested between two FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL Switch Full Duplex and never seen anything close to the speeds. using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp cards (all from memory), i routinely get TCP_STREAM to pushd 94Mbps. i use these machines for stressing every else we have at work. Hmmm, has anyone tried a full duplex test before? Since it seems like the bottleneck is really the speed of the disks.. Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Mon, 19 Jul 1999, Reinier Bezuidenhout wrote: Hi ... We have previously done many network performance tests for our products running on FreeBSD ... We have found that when ever there is disk accessing involved, it is not a good idea to look at the transfer figures. We did tests with ftp and is was slow (compared to only memory generated data e.g. ttcp) yeah, I guess all tests should be done without requiring the use of the disk. 1. If you want to test the network speed ... use ttcp or something that generates the data and doesn't read it from disk. ttcp works. The only problem is when I tried it in both directions, at once. the total becomes 11.xMbytes/sec total as opposed to 9.4Mbytes/sec when doing it in one direction only. 2. When doing full-duplex and using fxp cards, stay away from X-over cables ... use a full-duplex switch etc. ... the fxp cards are not made to work with X-over cables (as far as I know - ala Intel spec) note ... only for full-duplex tests. Does anyone actually use X-over cables for 100Mbps Full Duplex since 3Com said CrossOver cables are not rated for 100Mbps or something even though it's Cat5. Actually, in the older Intel docs for the Pro100B, it does say to connect using X-over cable to the switch. We have done tests in full-duplex with non Intel cards (because we did not have a switch at that time :)) and with max size packets we got around 188.00 Mbps using the de0 driver. Pretty interesting. How did you do the full duplex tests? Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] On Sun, 18 Jul 1999, Jonathan M. Bresler wrote: I guess I forgot about the overhead. I've tested between two FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL Switch Full Duplex and never seen anything close to the speeds. using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp cards (all from memory), i routinely get TCP_STREAM to pushd 94Mbps. i use these machines for stressing every else we have at work. Hmmm, has anyone tried a full duplex test before? Since it seems like the bottleneck is really the speed of the disks.. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
Hi .. 1. If you want to test the network speed ... use ttcp or something that generates the data and doesn't read it from disk. ttcp works. The only problem is when I tried it in both directions, at once. the total becomes 11.xMbytes/sec total as opposed to 9.4Mbytes/sec when doing it in one direction only. If the devices are set at full-duplex then you are looking at something else ... the standard size for ttcp packets is 8k ... maybe the switch etc. that you are connected to doesn't handle fragmented packets very well. But ... what it rather seems like .. is that the devices are not in full-duplex mode generating a lot of collisions. After a test with transfers in both directions .. check the number of collisions with netstat -in. If the number of collisions is not high .. - wait a moment ... are you using ttcp with tcp or udp option ... if you are using tcp (the default) then when transfering data you have acks going in both directions which could cause collisions on a full-duplex line ... try the same with the -u option for UDP. Check our setup below ... I'll explain some things there. Also check with netstat -sn to see if there are any other counters that increase with the full-duplex transfers. 2. When doing full-duplex and using fxp cards, stay away from X-over cables ... use a full-duplex switch etc. ... the fxp cards are not made to work with X-over cables (as far as I know - ala Intel spec) note ... only for full-duplex tests. Does anyone actually use X-over cables for 100Mbps Full Duplex since 3Com said CrossOver cables are not rated for 100Mbps or something even though it's Cat5. Actually, in the older Intel docs for the Pro100B, it does say to connect using X-over cable to the switch. Yes ... to a switch maybe ... but not fxp to fxp ... when transfering small packets .. you get a lot of device timeouts. We have done tests in full-duplex with non Intel cards (because we did not have a switch at that time :)) and with max size packets we got around 188.00 Mbps using the de0 driver. Pretty interesting. How did you do the full duplex tests? I'll describe the setup briefly ... :) We had 3 machines two PII-400 as the generators and a PII-400 as the machine in the middle ... So we have a setup that looks like this ... - -- - | Gen 1 |-| Router |-| Gen 2 | - -- - Now .. here is a trick ... add entries manually in the Router's tables to simulate machines on each side that does not exist. The reason for this is that we don't want the machines on the side to be generating AND excepting packets ... we just want them to generate packets at max network rate and nothing else. We then start a ttcp on both sides to the non existing machines. This means the router will be forwaring packets it receives without any machines having to be there because of the entries in the routing table. (we did this because we did not have another two fast machines at that time, but we did check the packets to make sure everything goes through and are not dropped etc. - it was some time ago :) ) We start ttcp with the following command ttcp -t -s -u -p 7000 -n nice large number -l 1472 10.0.0.1 the size of 1472 generates nice 1514 size UDP packets :) We then let the test run ... and check the throughput ... We used CAT5 X-over cables ... Hopw this helps Reinier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
We have previously done many network performance tests for our products running on FreeBSD ... We have found that when ever there is disk accessing involved, it is not a good idea to look at the transfer figures. We did tests with ftp and is was slow (compared to only memory generated data e.g. ttcp) 1. If you want to test the network speed ... use ttcp or something that generates the data and doesn't read it from disk. absolutely right. netperf generates its own data on the fly. it does not generate any disk activity. 2. When doing full-duplex and using fxp cards, stay away from X-over cables ... use a full-duplex switch etc. ... the fxp cards are not made to work with X-over cables (as far as I know - ala Intel spec) note ... only for full-duplex tests. hmmi have used intel cards on a cross-over cable regularly without any problems whatsoever. jmb To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Mon, 19 Jul 1999, Reinier Bezuidenhout wrote: Hi .. 1. If you want to test the network speed ... use ttcp or something that generates the data and doesn't read it from disk. ttcp works. The only problem is when I tried it in both directions, at once. the total becomes 11.xMbytes/sec total as opposed to 9.4Mbytes/sec when doing it in one direction only. If the devices are set at full-duplex then you are looking at something else ... the standard size for ttcp packets is 8k ... maybe the switch etc. that you are connected to doesn't handle fragmented packets very well. Hmmm, the thing is we replaced the cables with pre-made ones that go directly from the machines to the Cisco Catalyst 2924XL switch. Ofcourse, the switch is on 10/100 Auto-negotiation. But ... what it rather seems like .. is that the devices are not in full-duplex mode generating a lot of collisions. After a test with transfers in both directions .. check the number of collisions with netstat -in. If the number of collisions is not high .. - wait a moment ... are you using ttcp with tcp or udp option ... if you are using tcp (the default) then when transfering data you have acks going in both directions which could cause collisions on a full-duplex line ... try the same with the -u option for UDP. Check our setup below ... I'll explain some things there. I was using ttcp in two separate instances, one for send and one for receive between the same two machines. I did ttcp -r -s and the other end was ttcp -s -r. Also check with netstat -sn to see if there are any other counters that increase with the full-duplex transfers. Will do that. 2. When doing full-duplex and using fxp cards, stay away from X-over cables ... use a full-duplex switch etc. ... the fxp cards are not made to work with X-over cables (as far as I know - ala Intel spec) note ... only for full-duplex tests. Does anyone actually use X-over cables for 100Mbps Full Duplex since 3Com said CrossOver cables are not rated for 100Mbps or something even though it's Cat5. Actually, in the older Intel docs for the Pro100B, it does say to connect using X-over cable to the switch. Yes ... to a switch maybe ... but not fxp to fxp ... when transfering small packets .. you get a lot of device timeouts. I thought from a fxp to a fxp, you will need a x-over since a straight-wire won't work. We have done tests in full-duplex with non Intel cards (because we did not have a switch at that time :)) and with max size packets we got around 188.00 Mbps using the de0 driver. Pretty interesting. How did you do the full duplex tests? I'll describe the setup briefly ... :) We had 3 machines two PII-400 as the generators and a PII-400 as the machine in the middle ... So we have a setup that looks like this ... - -- - | Gen 1 |-| Router |-| Gen 2 | - -- - Now .. here is a trick ... add entries manually in the Router's tables to simulate machines on each side that does not exist. The reason for this is that we don't want the machines on the side to be generating AND excepting packets ... we just want them to generate packets at max network rate and nothing else. We then start a ttcp on both sides to the non existing machines. This means the router will be forwaring packets it receives without any machines having to be there because of the entries in the routing table. (we did this because we did not have another two fast machines at that time, but we did check the packets to make sure everything goes through and are not dropped etc. - it was some time ago :) ) We start ttcp with the following command ttcp -t -s -u -p 7000 -n nice large number -l 1472 10.0.0.1 the size of 1472 generates nice 1514 size UDP packets :) We then let the test run ... and check the throughput ... We used CAT5 X-over cables ... Hopw this helps Ah, I guess you didn't test it on a actual network that's connected to the world and also it was a direct connection between the machines rather than through a switch that can be congested. Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Sat, 17 Jul 1999, Vincent Poy wrote: BITCHMODE By reading the man page? The manpage doesn't really say anything about how to use ttcp... I don't think manpage useage is -hackers-esque. There is no ttcp binary anywhere on either my -CURRENT, 3.2-RELEASE and 3.1-RELEASE systems. Ever hear of ports? Or is 'how to use the ports collection' suddenly -hackers material? That, and .sig files that contain more relevant bits than the sender's posts... Oh, and I'd appreciate it if you could refrain from quoting this entire message to simply say, 'Interesting'... Thanks. /BITCHMODE Later, --mike To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999, Vincent Poy wrote: I'm not sure if it shows the mac address of the cisco's port or the actual device connected to it... You see the MAC of the switch's port. It's been too long since I've played on a Catalyst... but what does 'sh arp' display? Any arp - port - host correlations? Good luck... :) That's a option too... Only problem is that can take forever. :-) Yeah, I've noticed the 'sync-up time' takes quite awhile on a Catalyst running 100Mbps. Later, --mike To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Sat, 17 Jul 1999, Vincent Poy wrote: Ah, you have a point there. The problem is we have so many wires, we don't know which port goes to what on the Catalyst so we had it on autodetect and FreeBSD does boot up with fxp0 showing 100Mbps Full Duplex. Cisco's can show you which mac-adresses are on which port. Probably Catalyst's can too. Or have somebody pull the cable in and out of the pc, and watch for the light go on and off on the switch :-) Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
Ah, you have a point there. The problem is we have so many wires, we don't know which port goes to what on the Catalyst so we had it on autodetect and FreeBSD does boot up with fxp0 showing 100Mbps Full Duplex. Cisco's can show you which mac-adresses are on which port. Probably Catalyst's can too. Or have somebody pull the cable in and out of the pc, and watch for the light go on and off on the switch :-) A combination of those two would probably be useful. Then make a note of the port configuration, and *keep it updated*. This is essential for a hassle-free switched Ethernet environment. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999, Leif Neland wrote: On Sat, 17 Jul 1999, Vincent Poy wrote: Ah, you have a point there. The problem is we have so many wires, we don't know which port goes to what on the Catalyst so we had it on autodetect and FreeBSD does boot up with fxp0 showing 100Mbps Full Duplex. Cisco's can show you which mac-adresses are on which port. Probably Catalyst's can too. The Catalyst is the name of the Switches made by Cisco. :-) I'm not sure if it shows the mac address of the cisco's port or the actual device connected to it... FastEthernet0/1 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc1 (bia 0090.abea.3bc1) FastEthernet0/2 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc2 (bia 0090.abea.3bc2) Seems more like the Cisco's port's arp address to me than the devices. Or have somebody pull the cable in and out of the pc, and watch for the light go on and off on the switch :-) That's a option too... Only problem is that can take forever. :-) Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
I'm not sure if it shows the mac address of the cisco's port or the actual device connected to it... FastEthernet0/1 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc1 (bia 0090.abea.3bc1) FastEthernet0/2 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc2 (bia 0090.abea.3bc2) Seems more like the Cisco's port's arp address to me than the devices. Yes, this is the MAC address of the Catalyst port. You want show mac-address-table Please read the documentation. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999 [EMAIL PROTECTED] wrote: I'm not sure if it shows the mac address of the cisco's port or the actual device connected to it... FastEthernet0/1 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc1 (bia 0090.abea.3bc1) FastEthernet0/2 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc2 (bia 0090.abea.3bc2) Seems more like the Cisco's port's arp address to me than the devices. Yes, this is the MAC address of the Catalyst port. You want show mac-address-table Please read the documentation. This is hard since the actual machines and switches are almost 6000 miles away from me and the last time I checked, it didn't come with manuals. I know my way around the Cisco routers but the switches is still a mystery... Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
Please read the documentation. This is hard since the actual machines and switches are almost 6000 miles away from me and the last time I checked, it didn't come with manuals. I know my way around the Cisco routers but the switches is still a mystery... All of the Cisco documentation is available on WWW. Use it! Start at http://www.cisco.com/, follow the "Technical documents" and then the "Documentation home page" link. The manual for your switch is available, that's where I found the "show mac-address-table" command. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
Tim Baird wrote: I hope everyone is benefitting by these simple facts *chuckle* "Simple facts.." You sound like my physics professor. I for one am benefitting very much from the discussion. I got hired at my current job as a software person, but I have a background in hardware so I try and make it into the NOC every excuse I get (promotability, don't you know). It always helps if sound like I have a vague idea what I'm talking about. :) I just made up my first ethernet cables the other day, and learned an interesting tidbit that I'm sure is beyond elementary to most of you, but may benefit someone else. What I was told is that the reason Cat 5 cable is so much more efficient is that each of the 4 pairs of wire is twisted at a different rate. This helps reduce the possibility of frequency synchronization for the EM fields the pairs create. Soaking it in, Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
I guess I forgot about the overhead. I've tested between two FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL Switch Full Duplex and never seen anything close to the speeds. using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp cards (all from memory), i routinely get TCP_STREAM to pushd 94Mbps. i use these machines for stressing every else we have at work. jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Sat, 17 Jul 1999, Vincent Poy wrote: Ah, you have a point there. The problem is we have so many wires, we don't know which port goes to what on the Catalyst so we had it on autodetect and FreeBSD does boot up with fxp0 showing 100Mbps Full Duplex. Cisco's can show you which mac-adresses are on which port. Probably Catalyst's can too. Or have somebody pull the cable in and out of the pc, and watch for the light go on and off on the switch :-) Leif To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
Ah, you have a point there. The problem is we have so many wires, we don't know which port goes to what on the Catalyst so we had it on autodetect and FreeBSD does boot up with fxp0 showing 100Mbps Full Duplex. Cisco's can show you which mac-adresses are on which port. Probably Catalyst's can too. Or have somebody pull the cable in and out of the pc, and watch for the light go on and off on the switch :-) A combination of those two would probably be useful. Then make a note of the port configuration, and *keep it updated*. This is essential for a hassle-free switched Ethernet environment. Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999, Leif Neland wrote: On Sat, 17 Jul 1999, Vincent Poy wrote: Ah, you have a point there. The problem is we have so many wires, we don't know which port goes to what on the Catalyst so we had it on autodetect and FreeBSD does boot up with fxp0 showing 100Mbps Full Duplex. Cisco's can show you which mac-adresses are on which port. Probably Catalyst's can too. The Catalyst is the name of the Switches made by Cisco. :-) I'm not sure if it shows the mac address of the cisco's port or the actual device connected to it... FastEthernet0/1 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc1 (bia 0090.abea.3bc1) FastEthernet0/2 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc2 (bia 0090.abea.3bc2) Seems more like the Cisco's port's arp address to me than the devices. Or have somebody pull the cable in and out of the pc, and watch for the light go on and off on the switch :-) That's a option too... Only problem is that can take forever. :-) Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Cable quality (was: poor ethernet performance?)
On Friday, 16 July 1999 at 19:15:31 -0700, Matthew Dillon wrote: : Actually, I was referring to *digital* Audio cables like those :used for CD Transports to Digital/Analog convertors such as Kimber Kable :would be higher grade compared to Monster Cable. You're correct about the :bit errors though. Digital is digital. Either it works or it doesn't. Anything that goes over copper isn't digital, it's digital simulated on analogue. Poor quality cables *can* cause problems. But I'm sure that most of the folklore that circulates on this subject is of the same nature as the advice to use loudspeaker cables with at least 20mm**2 cross section, preferably driven by tube-based amplifiers. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
I'm not sure if it shows the mac address of the cisco's port or the actual device connected to it... FastEthernet0/1 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc1 (bia 0090.abea.3bc1) FastEthernet0/2 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc2 (bia 0090.abea.3bc2) Seems more like the Cisco's port's arp address to me than the devices. Yes, this is the MAC address of the Catalyst port. You want show mac-address-table Please read the documentation. Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999 sth...@nethelp.no wrote: I'm not sure if it shows the mac address of the cisco's port or the actual device connected to it... FastEthernet0/1 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc1 (bia 0090.abea.3bc1) FastEthernet0/2 is up, line protocol is up Hardware is Fast Ethernet, address is 0090.abea.3bc2 (bia 0090.abea.3bc2) Seems more like the Cisco's port's arp address to me than the devices. Yes, this is the MAC address of the Catalyst port. You want show mac-address-table Please read the documentation. This is hard since the actual machines and switches are almost 6000 miles away from me and the last time I checked, it didn't come with manuals. I know my way around the Cisco routers but the switches is still a mystery... Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
Please read the documentation. This is hard since the actual machines and switches are almost 6000 miles away from me and the last time I checked, it didn't come with manuals. I know my way around the Cisco routers but the switches is still a mystery... All of the Cisco documentation is available on WWW. Use it! Start at http://www.cisco.com/, follow the Technical documents and then the Documentation home page link. The manual for your switch is available, that's where I found the show mac-address-table command. Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
Tim Baird wrote: I hope everyone is benefitting by these simple facts *chuckle* Simple facts.. You sound like my physics professor. I for one am benefitting very much from the discussion. I got hired at my current job as a software person, but I have a background in hardware so I try and make it into the NOC every excuse I get (promotability, don't you know). It always helps if sound like I have a vague idea what I'm talking about. :) I just made up my first ethernet cables the other day, and learned an interesting tidbit that I'm sure is beyond elementary to most of you, but may benefit someone else. What I was told is that the reason Cat 5 cable is so much more efficient is that each of the 4 pairs of wire is twisted at a different rate. This helps reduce the possibility of frequency synchronization for the EM fields the pairs create. Soaking it in, Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
I guess I forgot about the overhead. I've tested between two FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL Switch Full Duplex and never seen anything close to the speeds. using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp cards (all from memory), i routinely get TCP_STREAM to pushd 94Mbps. i use these machines for stressing every else we have at work. jmb To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Fri, 16 Jul 1999, Tim Baird wrote: At 08:08 PM 16/07/99 -0700, you wrote: On Fri, 16 Jul 1999, Matthew Dillon wrote: : I know, I'm just wondering how did they get more frequency out of :wire of the same size. I can understand it if the wire was a larger :guage. For twisted pair, Less power == less crosstalk. Plus the higher bandwidth transceivers use better receivers and better pre-attenuation of the signal. Cross talk is only one of the variables I think... There is balancing and ACR and how well it can keep a true 100 Ohms to the cable. Now for a brief tutorial on transmission line / gigabit ethernet.. Ensuring that the entire transmission path maintains a consistant characteristic impedance is the most difficult task in cable manufacture. It has typically the most influence on the quality of the signal transmission. Crosstalk is always present in a multi pair cable system, it is a matter of degree i.e. how much cross talk (undesirable signal) is present as a percentage of desired signal. The level of crosstalk is proportional to dv/dt the rate of change in signal voltage with respect to time. This is different than "frequency". A 1 Hz signal that approaches a square wave (or rectangle) can have HUGE crosstalk at the edges because of the large dv/dt at those points. Care must be taken to optimize the dv/dt with respect to the desired baud rate. (baud == state changes per second) As a cable length increases, losses increase, (these can be compensated for by increasing drive level ... and thus dv/dt) but a potentially worse bogey man plays a rolepropagation delay. Most of the physical problems previously indicated can be improved upon, but no one has found a way around the limits of the speed of light (most transmission line allows propagation at about 70 to 80% of c). The time is not far off where this will be by far the most significant limit on information exchange for everyday communication. STP is better to use over shorter lengths where high level of EMI compromise the common mode rejection of the reciving system. The downside is that STP typically has rotton characteristic impedance consistencynot because of the plastic jacketing etc, but because of the varying distance (radius) between the cable pairs and the sheild over the length of the cable. Going to coax is usually the choice here for standard ethernet. Gigabit ethernet obviously creates a new level of awarenes about all of these factors. From a great article at http://www.gigabit-ethernet.org/technology/whitepapers/gige_11.97/how.html.. . * Use existing 4-pair Category 5 cable. To ensure proper operation at full link lengths, the cable must conform to the requirements of ANSI/TIA/EIA-568-A (1995). * Use all four pairs in the cable to keep symbol rate at or below 125 Mbaud. * Use PAM-5 coding to increase the amount of information sent with each symbol. (similar concept to analog modem methods) * Use 4D 8-state Trellis Forward Error Correction coding to offset the impact of noise and crosstalk. (ie. reciever has the ability to correct the error without requesting retransmission) * Use pulse shaping techniques to condition the transmitted spectrum. (i.e. limit dv/dt etc) * Use state-of-the-art DSP signal equalization techniques to manage the problems of noise, echo and crosstalk interferences, and to ensure a bit error rate of 1 x 10 exp(-10). Thanks for the article and for the brief. I just have a little comment on shielded versus unshielded for both analog and digital audio cables, not sure if this applies to data cable but digital audio is data: Cables are of the "nude" (unshielded) style, which has generally been perceived to sound "faster" and less "colored" than conventional fully shielded cables. As it turns out, there is good reason to think so since properly designed, un-shielded cables are much less reactive to the signal than their fully shielded counterparts. At audio frequencies and with reasonably short lengths of cable, a shield typically does more harm than good and is otherwise necessary only for Radio Frequency transmission and/or into extremely high gain inputs such as microphone and phono pre-amps. Instead, properly braided or twisted conductors effectively reduce susceptibility to induced noise, especially inductively coupled interference (EMI) while angular crossing weakens the field effects of opposite polarity conductors on each other. The mechanism for the self-shielding/field controlling design is to divide the signal into several separate runs in a continually changing orientation such that only a small fraction of either polarity is ever in the ideal orientation to the wave front. This has most relevance to electromagnetic fields either internal or external, which especially require an optimal angular component to induce the greatest opposing current
Re: poor ethernet performance?
Now for a brief tutorial on transmission line / gigabit ethernet.. Ensuring that the entire transmission path maintains a consistant characteristic impedance is the most difficult task in cable manufacture. It has typically the most influence on the quality of the signal transmission. Crosstalk is always present in a multi pair cable system, it is a matter of degree i.e. how much cross talk (undesirable signal) is present as a percentage of desired signal. The level of crosstalk is proportional to dv/dt the rate of change in signal voltage with respect to time. This is different than "frequency". A 1 Hz signal that approaches a square wave (or rectangle) can have HUGE crosstalk at the edges because of the large dv/dt at those points. Care must be taken to optimize the dv/dt with respect to the desired baud rate. (baud == state changes per second) As a cable length increases, losses increase, (these can be compensated for by increasing drive level ... and thus dv/dt) but a potentially worse bogey man plays a rolepropagation delay. Most of the physical problems previously indicated can be improved upon, but no one has found a way around the limits of the speed of light (most transmission line allows propagation at about 70 to 80% of c). The time is not far off where this will be by far the most significant limit on information exchange for everyday communication. STP is better to use over shorter lengths where high level of EMI compromise the common mode rejection of the reciving system. The downside is that STP typically has rotton characteristic impedance consistencynot because of the plastic jacketing etc, but because of the varying distance (radius) between the cable pairs and the sheild over the length of the cable. Going to coax is usually the choice here for standard ethernet. Gigabit ethernet obviously creates a new level of awarenes about all of these factors. From a great article at http://www.gigabit-ethernet.org/technology/whitepapers/gige_11.97/how.html.. . * Use existing 4-pair Category 5 cable. To ensure proper operation at full link lengths, the cable must conform to the requirements of ANSI/TIA/EIA-568-A (1995). * Use all four pairs in the cable to keep symbol rate at or below 125 Mbaud. * Use PAM-5 coding to increase the amount of information sent with each symbol. (similar concept to analog modem methods) * Use 4D 8-state Trellis Forward Error Correction coding to offset the impact of noise and crosstalk. (ie. reciever has the ability to correct the error without requesting retransmission) * Use pulse shaping techniques to condition the transmitted spectrum. (i.e. limit dv/dt etc) * Use state-of-the-art DSP signal equalization techniques to manage the problems of noise, echo and crosstalk interferences, and to ensure a bit error rate of 1 x 10 exp(-10). Thanks for the article and for the brief. I just have a little comment on shielded versus unshielded for both analog and digital audio cables, not sure if this applies to data cable but digital audio is data: Cables are of the "nude" (unshielded) style, which has generally been perceived to sound "faster" and less "colored" than conventional fully shielded cables. AhemI am not sure what this means..It sounds a little bit like those articles that you read in that audiophile magazine "The Absolute Sound" where people claim that they can hear the difference in the acoustics of their listening room depending on where they have situated their teacup..but I digress.see below As it turns out, there is good reason to think so since properly designed, un-shielded cables are much less reactive to the signal than their fully shielded counterparts. At audio frequencies and with reasonably short lengths of cable, a shield typically does more harm than good and is otherwise necessary only for Radio Frequency transmission and/or into extremely high gain inputs such as microphone and phono pre-amps. Instead, properly braided or twisted conductors effectively reduce susceptibility to induced noise, especially inductively coupled interference (EMI) while angular crossing weakens the field effects of opposite polarity conductors on each other. The mechanism for the self-shielding/field controlling design is to divide the signal into several separate runs in a continually changing orientation such that only a small fraction of either polarity is ever in the ideal orientation to the wave front. This has most relevance to electromagnetic fields either internal or external, which especially require an optimal angular component to induce the greatest opposing current flow. This is not a very accurate description of what is happening in a twisted pair situation... There are two factors influencing the design of twisted pair transmission line. First there is the need to control the consistency of the characteristic
Re: poor ethernet performance?
I am benefiting from it for sure. I guess what I was asking originally was if the higher frequency rated cables will give it more headroom since the 100BaseTX ethernet does push CAT5 to the limit. 100BaseTX is specified to run on Cat5 cabling, and with proper Cat5 cabling you get a a BER of 10^-8 or better. As long as your cabling meets the Cat5 spec, you'll get 100 Mbps - there's no possibility of "more headroom" with cables rated to higher frequency. Note that 100BaseTX is different from 10BaseT (but similar to synchronous serial lines) in that there is always a signal present. Note also that FreeBSD can easily saturate 100 Mbps Ethernet. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
Vincent Poy wrote: Note also that FreeBSD can easily saturate 100 Mbps Ethernet. It meets the spec when shipped but the bends, curves, temperature and other factors do affect the performance. I guess a good way to test the cable is with FreeBSD since it's the only real OS I've seen that can do like real world speeds. The only thing is that has anyone really saw 12 Megabytes/sec Full Duplex under FreeBSD? There again, any network installer worth their salt will test the cable when in-situ, after the 'dust' has settled... Fastest I've seen on my setup (doing anything useful) is around 9Mb/sec going from my WinNT box (with Intel Pro 100B) to my FreeBSD -current box (also with Pro 100B). So far, transfers from FreeBSD to WinNT are _always_ slower than transfers from WinNT to FreeBSD - which considering the hardware and write-overhead etc. - you would have though the opposite should be true... I guess NT ain't a great operating system after all... no kidding? :) -Karl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999 [EMAIL PROTECTED] wrote: It meets the spec when shipped but the bends, curves, temperature and other factors do affect the performance. I guess a good way to test the cable is with FreeBSD since it's the only real OS I've seen that can do like real world speeds. The only thing is that has anyone really saw 12 Megabytes/sec Full Duplex under FreeBSD? If you mean mega = 1048576, it's impossible since this is faster than 100 Mbps whichever way you count it. If you mean mega = 100, it depends on which way you're counting. The "speed of light" for TCP, application to application, on 100 Mbps Ethernet is 100 * 1460/1538 = 94.93 Mbps. This assumes full duplex. I mean Mega as in 100. 100Mbps Ethernet should be equal to about 12500Kbytes/sec which is equal to 12.5Mbytes/sec. 94.93Megabits/sec doesn't equal to 100Megabits/sec. I've measured 94.87 Mbps myself on full duplex 100BaseTX (back to back with a crossover cable or through a switch). This is close enough to the "speed of light" that I see no point in trying to improve on it... Yeah but what's the transfer rate you get? Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999 [EMAIL PROTECTED] wrote: I mean Mega as in 100. 100Mbps Ethernet should be equal to about 12500Kbytes/sec which is equal to 12.5Mbytes/sec. 94.93Megabits/sec doesn't equal to 100Megabits/sec. 12.5 Mbytes/sec on the wire *is* 94.93 Megabits/sec application to application using TCP - that's what I'm trying to say. You'll never see 12.5 Mbytes/sec application to application - look up the Ethernet frame formats to see why (1460 bytes of TCP payload is 1538 bytes on the wire). I guess I forgot about the overhead. I've tested between two FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL Switch Full Duplex and never seen anything close to the speeds. I've measured 94.87 Mbps myself on full duplex 100BaseTX (back to back with a crossover cable or through a switch). This is close enough to the "speed of light" that I see no point in trying to improve on it... Yeah but what's the transfer rate you get? 94.87 Mbps, application to application, using ttcp. Using Mega = 100, that should be 11.86 MBytes/sec. Oh yeah, this was measured with FreeBSD, with a P-133 on the receving end, back in '96 :-) Hmmm, how did you do the measurement and how big of a file does it need? With a 122MByte file, it only does 2644Kbytes/sec. This is between two Pentium II 450 machines with Intel Pro100+ NICs. Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
Hmmm, how did you do the measurement and how big of a file does it need? As I said, I used ttcp. ttcp is a "network only" test - it can source or sink traffic itself. This is nice because you avoid other sources of problems (disk bandwidth etc). I tended to run the tests for 30 seconds to one minute. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Sv: poor ethernet performance?
- Original Message - From: Vincent Poy [EMAIL PROTECTED] To: Karl Pielorz [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, July 18, 1999 12:22 AM Subject: Re: poor ethernet performance? There again, any network installer worth their salt will test the cable when in-situ, after the 'dust' has settled... Testing after the dust has settled and while it is in use is different since conditions do change. The testers only tests for continuity, not the impedance or any other electrical properties of the cable. Depends on the tester. Our electrician had a $1500 tester, which gave a printout of several electrical properties of each installed cable; this was included in the documentation of the network, which also included nice cad-drawings of the location of every outlet. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sv: poor ethernet performance?
On Sun, 18 Jul 1999, Leif Neland wrote: There again, any network installer worth their salt will test the cable when in-situ, after the 'dust' has settled... Testing after the dust has settled and while it is in use is different since conditions do change. The testers only tests for continuity, not the impedance or any other electrical properties of the cable. Depends on the tester. Our electrician had a $1500 tester, which gave a printout of several electrical properties of each installed cable; this was included in the documentation of the network, which also included nice cad-drawings of the location of every outlet. I know that can be done... I'm just saying during the actual use of the cable, people don't constantly keep testing it. Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999 [EMAIL PROTECTED] wrote: As I said, I used ttcp. ttcp is a "network only" test - it can source or sink traffic itself. This is nice because you avoid other sources of problems (disk bandwidth etc). I tended to run the tests for 30 seconds to one minute. Oops, must have missed that one. How do I do the ttcp test? By reading the man page? The manpage doesn't really say anything about how to use ttcp... (This is no longer freebsd-hackers stuff, methinks...) ttcp -r on the receiver and ttcp -t on the sender is a good start. Proceed from there. Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
Vincent Poy wrote: Testing after the dust has settled and while it is in use is different since conditions do change. The testers only tests for continuity, not the impedance or any other electrical properties of the cable. The decent testers (such as a professional cable installing friend of mine uses) do a full range of tests, at both 10Mbs and 100Mbs speed, including cross talk, attenuation + a host of other things. The customers gets a certificate _per_ connection, listing all the details... The decent testers use proper TDR techniques to do a full range of testing, more than just "The wires conduct, and their in the right order at both ends" :-) Fastest I've seen on my setup (doing anything useful) is around 9Mb/sec going from my WinNT box (with Intel Pro 100B) to my FreeBSD -current box (also with Pro 100B). Hmmm, how large of a file do you have to transfer to see the max speed? Typically around 2Gb's... I do a lot of DVR work, so I always have large files kicking around :-) What about from FreeBSD to FreeBSD? =) Don't have two boxes to test from... I've toyed with replacing my current NT install with FreeBSD, I guess I just love Delphi too much :-) [hence need Win32 :)] + The company database runs only under Win32 so far... This is getting off-topic for -hackers - if you want to chat we should either move it somewhere more appropriate - or personal replies only :-) -Kp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Sat, 17 Jul 1999, Matthew Dillon wrote: : 2.6 MB/sec is what I would expect if you were running the test : over an ssh link on a fast cpu - the encryption eats a lot of cpu. But : a normal rcp or ftp or data transfer can easily do 9-10 MBytes/sec. : : That was actually done with ftp between two machines connected :Full Duplex to a Cisco Catalyst 2924XL switch. You've got breakage somewhere, I've run 9-10 MBytes/sec in both directions at once through a catalyst between two FreeBSD boxes at full-duplex. Not sure about the breakage but it does sound like something is wrong. We replaced all the cables with pre-made ones and it's still the same. Maybe the 100Meg file isn't large enough since it seems it starts slow then builds up in speed. Check for interface errors or collisions - this kinda sounds like the duplex hasn't been matched up. You should have no errors and no collisions at all if you are running full-duplex. Make sure the duplex and port speed on the catalyst is hardwired -- we have had no end of troubles with the autodetect junk on catalysts. It also doesn't hurt to hardware the duplex and port speed on the UNIX boxes. Ah, you have a point there. The problem is we have so many wires, we don't know which port goes to what on the Catalyst so we had it on autodetect and FreeBSD does boot up with fxp0 showing 100Mbps Full Duplex. If you still have problems there are a number of possibilities. If you are using discrete RJ45 ports try switching the cables as well as use a different catalyst port. If you are using telco cables - those big fat 50 or 100 pair cables that use centronics-like connectors on the catalyst side hat, you probably have an RJ45 punchdown block on the other end. These have to be Cat-5 punchdown blocks, not Cat-3 punchdown blocks. Try a different port on the punchdown block. Hmmm, we're not using punchdown blocks since the cables from the switches go directly to the workstation and other hubs/switches. Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
At 08:08 PM 16/07/99 -0700, you wrote: On Fri, 16 Jul 1999, Matthew Dillon wrote: :I know, I'm just wondering how did they get more frequency out of :wire of the same size. I can understand it if the wire was a larger :guage. For twisted pair, Less power == less crosstalk. Plus the higher bandwidth transceivers use better receivers and better pre-attenuation of the signal. Cross talk is only one of the variables I think... There is balancing and ACR and how well it can keep a true 100 Ohms to the cable. Now for a brief tutorial on transmission line / gigabit ethernet.. Ensuring that the entire transmission path maintains a consistant characteristic impedance is the most difficult task in cable manufacture. It has typically the most influence on the quality of the signal transmission. Crosstalk is always present in a multi pair cable system, it is a matter of degree i.e. how much cross talk (undesirable signal) is present as a percentage of desired signal. The level of crosstalk is proportional to dv/dt the rate of change in signal voltage with respect to time. This is different than frequency. A 1 Hz signal that approaches a square wave (or rectangle) can have HUGE crosstalk at the edges because of the large dv/dt at those points. Care must be taken to optimize the dv/dt with respect to the desired baud rate. (baud == state changes per second) As a cable length increases, losses increase, (these can be compensated for by increasing drive level ... and thus dv/dt) but a potentially worse bogey man plays a rolepropagation delay. Most of the physical problems previously indicated can be improved upon, but no one has found a way around the limits of the speed of light (most transmission line allows propagation at about 70 to 80% of c). The time is not far off where this will be by far the most significant limit on information exchange for everyday communication. STP is better to use over shorter lengths where high level of EMI compromise the common mode rejection of the reciving system. The downside is that STP typically has rotton characteristic impedance consistencynot because of the plastic jacketing etc, but because of the varying distance (radius) between the cable pairs and the sheild over the length of the cable. Going to coax is usually the choice here for standard ethernet. Gigabit ethernet obviously creates a new level of awarenes about all of these factors. From a great article at http://www.gigabit-ethernet.org/technology/whitepapers/gige_11.97/how.html.. . * Use existing 4-pair Category 5 cable. To ensure proper operation at full link lengths, the cable must conform to the requirements of ANSI/TIA/EIA-568-A (1995). * Use all four pairs in the cable to keep symbol rate at or below 125 Mbaud. * Use PAM-5 coding to increase the amount of information sent with each symbol. (similar concept to analog modem methods) * Use 4D 8-state Trellis Forward Error Correction coding to offset the impact of noise and crosstalk. (ie. reciever has the ability to correct the error without requesting retransmission) * Use pulse shaping techniques to condition the transmitted spectrum. (i.e. limit dv/dt etc) * Use state-of-the-art DSP signal equalization techniques to manage the problems of noise, echo and crosstalk interferences, and to ensure a bit error rate of 1 x 10 exp(-10). I'm not sure what the gigabit copper ethernet people are doing, but there are other ways as well. I wonder if any Gigabit ethernet cards exist that uses UTP because everything seems to be pointing to the fiber direction. Basic ethernet uses baseband which is quite noisy even with the preattenuation, so there was lots of room to go faster. Yep, it would have been nice if the original spec was shielded but anything shielded would have a degrade in signal... It's the insultaion whether it is PVC, Teflon or even the new air chambers introduced by Matthew Bond at Tara Labs using Regtangular Solid Core cable capable of handling 2.5Ghz. Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Fri, 16 Jul 1999, Tim Baird wrote: At 08:08 PM 16/07/99 -0700, you wrote: On Fri, 16 Jul 1999, Matthew Dillon wrote: : I know, I'm just wondering how did they get more frequency out of :wire of the same size. I can understand it if the wire was a larger :guage. For twisted pair, Less power == less crosstalk. Plus the higher bandwidth transceivers use better receivers and better pre-attenuation of the signal. Cross talk is only one of the variables I think... There is balancing and ACR and how well it can keep a true 100 Ohms to the cable. Now for a brief tutorial on transmission line / gigabit ethernet.. Ensuring that the entire transmission path maintains a consistant characteristic impedance is the most difficult task in cable manufacture. It has typically the most influence on the quality of the signal transmission. Crosstalk is always present in a multi pair cable system, it is a matter of degree i.e. how much cross talk (undesirable signal) is present as a percentage of desired signal. The level of crosstalk is proportional to dv/dt the rate of change in signal voltage with respect to time. This is different than frequency. A 1 Hz signal that approaches a square wave (or rectangle) can have HUGE crosstalk at the edges because of the large dv/dt at those points. Care must be taken to optimize the dv/dt with respect to the desired baud rate. (baud == state changes per second) As a cable length increases, losses increase, (these can be compensated for by increasing drive level ... and thus dv/dt) but a potentially worse bogey man plays a rolepropagation delay. Most of the physical problems previously indicated can be improved upon, but no one has found a way around the limits of the speed of light (most transmission line allows propagation at about 70 to 80% of c). The time is not far off where this will be by far the most significant limit on information exchange for everyday communication. STP is better to use over shorter lengths where high level of EMI compromise the common mode rejection of the reciving system. The downside is that STP typically has rotton characteristic impedance consistencynot because of the plastic jacketing etc, but because of the varying distance (radius) between the cable pairs and the sheild over the length of the cable. Going to coax is usually the choice here for standard ethernet. Gigabit ethernet obviously creates a new level of awarenes about all of these factors. From a great article at http://www.gigabit-ethernet.org/technology/whitepapers/gige_11.97/how.html.. . * Use existing 4-pair Category 5 cable. To ensure proper operation at full link lengths, the cable must conform to the requirements of ANSI/TIA/EIA-568-A (1995). * Use all four pairs in the cable to keep symbol rate at or below 125 Mbaud. * Use PAM-5 coding to increase the amount of information sent with each symbol. (similar concept to analog modem methods) * Use 4D 8-state Trellis Forward Error Correction coding to offset the impact of noise and crosstalk. (ie. reciever has the ability to correct the error without requesting retransmission) * Use pulse shaping techniques to condition the transmitted spectrum. (i.e. limit dv/dt etc) * Use state-of-the-art DSP signal equalization techniques to manage the problems of noise, echo and crosstalk interferences, and to ensure a bit error rate of 1 x 10 exp(-10). Thanks for the article and for the brief. I just have a little comment on shielded versus unshielded for both analog and digital audio cables, not sure if this applies to data cable but digital audio is data: Cables are of the nude (unshielded) style, which has generally been perceived to sound faster and less colored than conventional fully shielded cables. As it turns out, there is good reason to think so since properly designed, un-shielded cables are much less reactive to the signal than their fully shielded counterparts. At audio frequencies and with reasonably short lengths of cable, a shield typically does more harm than good and is otherwise necessary only for Radio Frequency transmission and/or into extremely high gain inputs such as microphone and phono pre-amps. Instead, properly braided or twisted conductors effectively reduce susceptibility to induced noise, especially inductively coupled interference (EMI) while angular crossing weakens the field effects of opposite polarity conductors on each other. The mechanism for the self-shielding/field controlling design is to divide the signal into several separate runs in a continually changing orientation such that only a small fraction of either polarity is ever in the ideal orientation to the wave front. This has most relevance to electromagnetic fields either internal or external, which especially require an optimal angular component to induce the greatest opposing current flow.
Re: poor ethernet performance?
Now for a brief tutorial on transmission line / gigabit ethernet.. Ensuring that the entire transmission path maintains a consistant characteristic impedance is the most difficult task in cable manufacture. It has typically the most influence on the quality of the signal transmission. Crosstalk is always present in a multi pair cable system, it is a matter of degree i.e. how much cross talk (undesirable signal) is present as a percentage of desired signal. The level of crosstalk is proportional to dv/dt the rate of change in signal voltage with respect to time. This is different than frequency. A 1 Hz signal that approaches a square wave (or rectangle) can have HUGE crosstalk at the edges because of the large dv/dt at those points. Care must be taken to optimize the dv/dt with respect to the desired baud rate. (baud == state changes per second) As a cable length increases, losses increase, (these can be compensated for by increasing drive level ... and thus dv/dt) but a potentially worse bogey man plays a rolepropagation delay. Most of the physical problems previously indicated can be improved upon, but no one has found a way around the limits of the speed of light (most transmission line allows propagation at about 70 to 80% of c). The time is not far off where this will be by far the most significant limit on information exchange for everyday communication. STP is better to use over shorter lengths where high level of EMI compromise the common mode rejection of the reciving system. The downside is that STP typically has rotton characteristic impedance consistencynot because of the plastic jacketing etc, but because of the varying distance (radius) between the cable pairs and the sheild over the length of the cable. Going to coax is usually the choice here for standard ethernet. Gigabit ethernet obviously creates a new level of awarenes about all of these factors. From a great article at http://www.gigabit-ethernet.org/technology/whitepapers/gige_11.97/how.html.. . * Use existing 4-pair Category 5 cable. To ensure proper operation at full link lengths, the cable must conform to the requirements of ANSI/TIA/EIA-568-A (1995). * Use all four pairs in the cable to keep symbol rate at or below 125 Mbaud. * Use PAM-5 coding to increase the amount of information sent with each symbol. (similar concept to analog modem methods) * Use 4D 8-state Trellis Forward Error Correction coding to offset the impact of noise and crosstalk. (ie. reciever has the ability to correct the error without requesting retransmission) * Use pulse shaping techniques to condition the transmitted spectrum. (i.e. limit dv/dt etc) * Use state-of-the-art DSP signal equalization techniques to manage the problems of noise, echo and crosstalk interferences, and to ensure a bit error rate of 1 x 10 exp(-10). Thanks for the article and for the brief. I just have a little comment on shielded versus unshielded for both analog and digital audio cables, not sure if this applies to data cable but digital audio is data: Cables are of the nude (unshielded) style, which has generally been perceived to sound faster and less colored than conventional fully shielded cables. AhemI am not sure what this means..It sounds a little bit like those articles that you read in that audiophile magazine The Absolute Sound where people claim that they can hear the difference in the acoustics of their listening room depending on where they have situated their teacup..but I digress.see below As it turns out, there is good reason to think so since properly designed, un-shielded cables are much less reactive to the signal than their fully shielded counterparts. At audio frequencies and with reasonably short lengths of cable, a shield typically does more harm than good and is otherwise necessary only for Radio Frequency transmission and/or into extremely high gain inputs such as microphone and phono pre-amps. Instead, properly braided or twisted conductors effectively reduce susceptibility to induced noise, especially inductively coupled interference (EMI) while angular crossing weakens the field effects of opposite polarity conductors on each other. The mechanism for the self-shielding/field controlling design is to divide the signal into several separate runs in a continually changing orientation such that only a small fraction of either polarity is ever in the ideal orientation to the wave front. This has most relevance to electromagnetic fields either internal or external, which especially require an optimal angular component to induce the greatest opposing current flow. This is not a very accurate description of what is happening in a twisted pair situation... There are two factors influencing the design of twisted pair transmission line. First there is the need to control the consistency of the characteristic impedance of the
Re: poor ethernet performance?
On Sat, 17 Jul 1999, Tim Baird wrote: Thanks for the article and for the brief. I just have a little comment on shielded versus unshielded for both analog and digital audio cables, not sure if this applies to data cable but digital audio is data: Cables are of the nude (unshielded) style, which has generally been perceived to sound faster and less colored than conventional fully shielded cables. AhemI am not sure what this means..It sounds a little bit like those articles that you read in that audiophile magazine The Absolute Sound where people claim that they can hear the difference in the acoustics of their listening room depending on where they have situated their teacup..but I digress.see below It all depends on the equipment too since remember the wire is the weakest link in the chain and every cable sounds different. I'm sure no wire is 100% perfect. As it turns out, there is good reason to think so since properly designed, un-shielded cables are much less reactive to the signal than their fully shielded counterparts. At audio frequencies and with reasonably short lengths of cable, a shield typically does more harm than good and is otherwise necessary only for Radio Frequency transmission and/or into extremely high gain inputs such as microphone and phono pre-amps. Instead, properly braided or twisted conductors effectively reduce susceptibility to induced noise, especially inductively coupled interference (EMI) while angular crossing weakens the field effects of opposite polarity conductors on each other. The mechanism for the self-shielding/field controlling design is to divide the signal into several separate runs in a continually changing orientation such that only a small fraction of either polarity is ever in the ideal orientation to the wave front. This has most relevance to electromagnetic fields either internal or external, which especially require an optimal angular component to induce the greatest opposing current flow. This is not a very accurate description of what is happening in a twisted pair situation... There are two factors influencing the design of twisted pair transmission line. First there is the need to control the consistency of the characteristic impedance of the line. This happens by controlling the distance (radius) between the two conductors as well as the dielectric material that is present in their vicinity. For coax, this is a special compound between the braided outer conductor (shield) and the inner conductor. For twisted pair, this is usually air (the dielectric properties of the insulation are made to be virtually the same as air). The dielectric only affects the capacitive element by controlling permittivity, the inductive element is essentially controlled by the permeability of free space. The characteristic impedance has nothing at all to do with the DC resistance of the conductors used...it (CI) is a combination of the two reactive effects inherantly present along the line...namely capacitance (storage of electric charge) measured in Farads/meter and inductance (storage of magnetic energy) measured in Henries/meter. These two effects or reactances will always be equal and opposite at some frequency, the idea is to have an effective cancellation happening over as broad a range as possible so that they do not limit the bandwidth of the transmission line. The values of the two reactances are positive and negative imaginary numbers. When you take the square root of the ratio of the two values, you end up with a real number in the unit of ohms.ie the characteristic impedance. Yes, but how consistent the ohms rating is what is important. BTW This is EXACTLY analogous to index of refraction with respect to light... As the spectral components of your signal increase in frequency, there are some interesting effects which occur...one is skin effect. This effect is the tendency for currents on the line to travel to the outside of the conductor as their self induced electromagnetic force creates a higher flux density at the center of the conductor...this changes the effective cross-sectional area of the conductor and thus the resistance. The result is a more lossy lineOther losses are found in the dielectric material, and of course the natural resistance of the copper Second, to minimize the effect of electromagnetic interference (EMI) which is both crosstalk and other stray emag signals incident on the transmission line, the twisted pair design is used on the assumption that common mode signals are effectively rejected by the reciever...ie any currents induced along the line that are EQUAL will be cancelled out by the differential reciever. If you twist the cable pair as it travels through space, you will have any incident signal affect BOTH conductors equally (hopefully)thus the EMI induced
Re: poor ethernet performance?
I am benefiting from it for sure. I guess what I was asking originally was if the higher frequency rated cables will give it more headroom since the 100BaseTX ethernet does push CAT5 to the limit. 100BaseTX is specified to run on Cat5 cabling, and with proper Cat5 cabling you get a a BER of 10^-8 or better. As long as your cabling meets the Cat5 spec, you'll get 100 Mbps - there's no possibility of more headroom with cables rated to higher frequency. Note that 100BaseTX is different from 10BaseT (but similar to synchronous serial lines) in that there is always a signal present. Note also that FreeBSD can easily saturate 100 Mbps Ethernet. Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On 16-Jul-99 Matthew Dillon wrote: In regards to audio/video verses ethernet, you have to remember that audio and video are *analog*, not digital. The cable quality matters for analog, but it only needs to be good enough for digital. If you don't get any bit errors (and you shouldn't) then a better cable is not going to make a difference. -Matt Matthew Dillon And you seen the nice square waves of 100Mb or !Gb ether on a line then? The techniques used for transmitting 100Mb/s down copper are certainly not digital. Pulse shaping, line estimation, ISI removal are all analogue! The cable itself is less improtant than the impedance matching at connectors and bends in the cable. Duncan --- Duncan Barclay | God smiles upon the little children, d...@ragnet.demon.co.uk | the alcoholics, and the permanently stoned. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
: :And you seen the nice square waves of 100Mb or !Gb ether on a line then? The :techniques used for transmitting 100Mb/s down copper are certainly not digital. :Pulse shaping, line estimation, ISI removal are all analogue! : :The cable itself is less improtant than the impedance matching at connectors :and bends in the cable. : :Duncan : :Duncan Barclay | God smiles upon the little children, :d...@ragnet.demon.co.uk | the alcoholics, and the permanently stoned. Obviously you don't get square waves going down the wire - But it is still a digital communications protocol. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Sat, 17 Jul 1999 sth...@nethelp.no wrote: I am benefiting from it for sure. I guess what I was asking originally was if the higher frequency rated cables will give it more headroom since the 100BaseTX ethernet does push CAT5 to the limit. 100BaseTX is specified to run on Cat5 cabling, and with proper Cat5 cabling you get a a BER of 10^-8 or better. Speaking about specifications, what's the spec to run 100BaseT4? As long as your cabling meets the Cat5 spec, you'll get 100 Mbps - there's no possibility of more headroom with cables rated to higher frequency. Note that 100BaseTX is different from 10BaseT (but similar to synchronous serial lines) in that there is always a signal present. Note also that FreeBSD can easily saturate 100 Mbps Ethernet. It meets the spec when shipped but the bends, curves, temperature and other factors do affect the performance. I guess a good way to test the cable is with FreeBSD since it's the only real OS I've seen that can do like real world speeds. The only thing is that has anyone really saw 12 Megabytes/sec Full Duplex under FreeBSD? Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
Vincent Poy wrote: Note also that FreeBSD can easily saturate 100 Mbps Ethernet. It meets the spec when shipped but the bends, curves, temperature and other factors do affect the performance. I guess a good way to test the cable is with FreeBSD since it's the only real OS I've seen that can do like real world speeds. The only thing is that has anyone really saw 12 Megabytes/sec Full Duplex under FreeBSD? There again, any network installer worth their salt will test the cable when in-situ, after the 'dust' has settled... Fastest I've seen on my setup (doing anything useful) is around 9Mb/sec going from my WinNT box (with Intel Pro 100B) to my FreeBSD -current box (also with Pro 100B). So far, transfers from FreeBSD to WinNT are _always_ slower than transfers from WinNT to FreeBSD - which considering the hardware and write-overhead etc. - you would have though the opposite should be true... I guess NT ain't a great operating system after all... no kidding? :) -Karl To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Sat, 17 Jul 1999, Karl Pielorz wrote: Vincent Poy wrote: Note also that FreeBSD can easily saturate 100 Mbps Ethernet. It meets the spec when shipped but the bends, curves, temperature and other factors do affect the performance. I guess a good way to test the cable is with FreeBSD since it's the only real OS I've seen that can do like real world speeds. The only thing is that has anyone really saw 12 Megabytes/sec Full Duplex under FreeBSD? There again, any network installer worth their salt will test the cable when in-situ, after the 'dust' has settled... Testing after the dust has settled and while it is in use is different since conditions do change. The testers only tests for continuity, not the impedance or any other electrical properties of the cable. Fastest I've seen on my setup (doing anything useful) is around 9Mb/sec going from my WinNT box (with Intel Pro 100B) to my FreeBSD -current box (also with Pro 100B). Hmmm, how large of a file do you have to transfer to see the max speed? So far, transfers from FreeBSD to WinNT are _always_ slower than transfers from WinNT to FreeBSD - which considering the hardware and write-overhead etc. - you would have though the opposite should be true... I guess NT ain't a great operating system after all... no kidding? :) What about from FreeBSD to FreeBSD? =) Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
It meets the spec when shipped but the bends, curves, temperature and other factors do affect the performance. I guess a good way to test the cable is with FreeBSD since it's the only real OS I've seen that can do like real world speeds. The only thing is that has anyone really saw 12 Megabytes/sec Full Duplex under FreeBSD? If you mean mega = 1048576, it's impossible since this is faster than 100 Mbps whichever way you count it. If you mean mega = 100, it depends on which way you're counting. The speed of light for TCP, application to application, on 100 Mbps Ethernet is 100 * 1460/1538 = 94.93 Mbps. This assumes full duplex. I've measured 94.87 Mbps myself on full duplex 100BaseTX (back to back with a crossover cable or through a switch). This is close enough to the speed of light that I see no point in trying to improve on it... Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999 sth...@nethelp.no wrote: It meets the spec when shipped but the bends, curves, temperature and other factors do affect the performance. I guess a good way to test the cable is with FreeBSD since it's the only real OS I've seen that can do like real world speeds. The only thing is that has anyone really saw 12 Megabytes/sec Full Duplex under FreeBSD? If you mean mega = 1048576, it's impossible since this is faster than 100 Mbps whichever way you count it. If you mean mega = 100, it depends on which way you're counting. The speed of light for TCP, application to application, on 100 Mbps Ethernet is 100 * 1460/1538 = 94.93 Mbps. This assumes full duplex. I mean Mega as in 100. 100Mbps Ethernet should be equal to about 12500Kbytes/sec which is equal to 12.5Mbytes/sec. 94.93Megabits/sec doesn't equal to 100Megabits/sec. I've measured 94.87 Mbps myself on full duplex 100BaseTX (back to back with a crossover cable or through a switch). This is close enough to the speed of light that I see no point in trying to improve on it... Yeah but what's the transfer rate you get? Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
I mean Mega as in 100. 100Mbps Ethernet should be equal to about 12500Kbytes/sec which is equal to 12.5Mbytes/sec. 94.93Megabits/sec doesn't equal to 100Megabits/sec. 12.5 Mbytes/sec on the wire *is* 94.93 Megabits/sec application to application using TCP - that's what I'm trying to say. You'll never see 12.5 Mbytes/sec application to application - look up the Ethernet frame formats to see why (1460 bytes of TCP payload is 1538 bytes on the wire). I've measured 94.87 Mbps myself on full duplex 100BaseTX (back to back with a crossover cable or through a switch). This is close enough to the speed of light that I see no point in trying to improve on it... Yeah but what's the transfer rate you get? 94.87 Mbps, application to application, using ttcp. Using Mega = 100, that should be 11.86 MBytes/sec. Oh yeah, this was measured with FreeBSD, with a P-133 on the receving end, back in '96 :-) Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999 sth...@nethelp.no wrote: I mean Mega as in 100. 100Mbps Ethernet should be equal to about 12500Kbytes/sec which is equal to 12.5Mbytes/sec. 94.93Megabits/sec doesn't equal to 100Megabits/sec. 12.5 Mbytes/sec on the wire *is* 94.93 Megabits/sec application to application using TCP - that's what I'm trying to say. You'll never see 12.5 Mbytes/sec application to application - look up the Ethernet frame formats to see why (1460 bytes of TCP payload is 1538 bytes on the wire). I guess I forgot about the overhead. I've tested between two FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL Switch Full Duplex and never seen anything close to the speeds. I've measured 94.87 Mbps myself on full duplex 100BaseTX (back to back with a crossover cable or through a switch). This is close enough to the speed of light that I see no point in trying to improve on it... Yeah but what's the transfer rate you get? 94.87 Mbps, application to application, using ttcp. Using Mega = 100, that should be 11.86 MBytes/sec. Oh yeah, this was measured with FreeBSD, with a P-133 on the receving end, back in '96 :-) Hmmm, how did you do the measurement and how big of a file does it need? With a 122MByte file, it only does 2644Kbytes/sec. This is between two Pentium II 450 machines with Intel Pro100+ NICs. Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
Hmmm, how did you do the measurement and how big of a file does it need? As I said, I used ttcp. ttcp is a network only test - it can source or sink traffic itself. This is nice because you avoid other sources of problems (disk bandwidth etc). I tended to run the tests for 30 seconds to one minute. Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
