[Spyderturbo007]

I've been looking at switches for my house and have a quick question. I know there are two different switch types, store and forward and cut through. I understand how each of them work, but what I can't find is when you should use one type over the other.

It looks like cut through will allow wire speed and are faster, so why aren't all switches cut through?

One other question that I should probably know the answer to, concerns the router used with the switch. If I get a gigabit switch and couple that with a 10/100 wireless n router, that will still allow gigabit LAN speeds, correct? Provided I run the up-link right out of the router and don't use any of it's ports.

I currently have this router and was looking at this switch.

Edited by Spyderturbo007, 24 February 2010 - 09:08 AM.

[Advertisements]

One other question that I should probably know the answer to, concerns the router used with the switch. If I get a gigabit switch and couple that with a 10/100 wireless n router, that will still allow gigabit LAN speeds, correct? Provided I run the up-link right out of the router and don't use any of it's ports.

yes....the traffic will only move at the fastest speed allowed by the transmission media/device that the traffic is actually going through. so if you had a 10 mbps connection on the inside of the router, all your traffic would be limited to that speed when the traffic is destined to pass through the router, but if you had 3gbps fiber links on the lan you'd still have that speed for lan communications.

the same applies on the outside of the router (wan side) i doubt you've got a gigabit connection to the internet, but you can still maintain gigabit lan speeds because the interface you're traveling through on the lan is gigabit capable.

a good read on cut-through vs store and forward switching. the basic difference is that a cut-through makes it's forwarding decision much sooner than a store and forward does.

store and forward is used mostly in locations where a lot of "wire congestion" could be an issue. this is the case because store and forward receives the entire packet and can make a real time decision as to the validity of the packet and choose to drop or forward the packet if it's malformed or in some other way incorrect.

cut-through is used in locations where this congestion isn't an issue. a cut-through process only examines enough of the packet to know where it came from and where it's going, then it sends it on it's way. it doesn't care if it's malformed (as far as the data portion of the packet is concerned) or incorrect. this model lets the end device drop malformed packets. cut-through will drop packets that have incorrect addressing headers and malformed portions of the packet that relate to addressing.

when i mention congestion above, we're talking about milliseconds of latency which can be an issue when you're transmitting MASSIVE amounts of data back and forth on the lan, or when you're transmitting latency sensitive data at a high rate

in a home scenario you're not going to notice the difference between either technology

[dsenette]

One other question that I should probably know the answer to, concerns the router used with the switch. If I get a gigabit switch and couple that with a 10/100 wireless n router, that will still allow gigabit LAN speeds, correct? Provided I run the up-link right out of the router and don't use any of it's ports.

yes....the traffic will only move at the fastest speed allowed by the transmission media/device that the traffic is actually going through. so if you had a 10 mbps connection on the inside of the router, all your traffic would be limited to that speed when the traffic is destined to pass through the router, but if you had 3gbps fiber links on the lan you'd still have that speed for lan communications.

the same applies on the outside of the router (wan side) i doubt you've got a gigabit connection to the internet, but you can still maintain gigabit lan speeds because the interface you're traveling through on the lan is gigabit capable.

a good read on cut-through vs store and forward switching. the basic difference is that a cut-through makes it's forwarding decision much sooner than a store and forward does.

store and forward is used mostly in locations where a lot of "wire congestion" could be an issue. this is the case because store and forward receives the entire packet and can make a real time decision as to the validity of the packet and choose to drop or forward the packet if it's malformed or in some other way incorrect.

cut-through is used in locations where this congestion isn't an issue. a cut-through process only examines enough of the packet to know where it came from and where it's going, then it sends it on it's way. it doesn't care if it's malformed (as far as the data portion of the packet is concerned) or incorrect. this model lets the end device drop malformed packets. cut-through will drop packets that have incorrect addressing headers and malformed portions of the packet that relate to addressing.

when i mention congestion above, we're talking about milliseconds of latency which can be an issue when you're transmitting MASSIVE amounts of data back and forth on the lan, or when you're transmitting latency sensitive data at a high rate

in a home scenario you're not going to notice the difference between either technology

[Spyderturbo007]

yes....the traffic will only move at the fastest speed allowed by the transmission media/device that the traffic is actually going through. so if you had a 10 mbps connection on the inside of the router, all your traffic would be limited to that speed when the traffic is destined to pass through the router, but if you had 3gbps fiber links on the lan you'd still have that speed for lan communications.

Perfect, that's what I figured, but wanted to check with the experts before I got the switch.

a good read on cut-through vs store and forward switching. the basic difference is that a cut-through makes it's forwarding decision much sooner than a store and forward does.

I did read through that earlier, but a lot of it confused me.

when i mention congestion above, we're talking about milliseconds of latency which can be an issue when you're transmitting MASSIVE amounts of data back and forth on the lan, or when you're transmitting latency sensitive data at a high rate

Does the choice of switch type matter when dealing with longer run lengths, but still staying under the Cat 5e limitations? I was reading about the time the packet is "on the wire". I found this, but it confused me as well.

It's to do with the maximum distance between active nodes. Nodes with store and forward will extend the maximum distance.

The limit's imposed by the time it takes for the smallest packet to be entirely on the wire. If a packet is entirely on the wire, and the beginning hasn't been accepted by all other nodes in the same collision domain, then you could have one begin transmitting and corrupting the other packet. The real problem is the original node doesn't know this has happened, so will only retransmit it if requested.

Thanks!

[dsenette]

I did read through that earlier, but a lot of it confused me.

any specifics? switching in your case isn't that complex.

Does the choice of switch type matter when dealing with longer run lengths, but still staying under the Cat 5e limitations? I was reading about the time the packet is "on the wire". I found this, but it confused me as well.

this is a bit touchy....as it depends on a lot of variables. none of which should be encountered in a small home network.

if you're running at max length for ethernet (300' ish) and you've got a lot of machine connected to a large switch pushing lots of information all the time. then this can be a problem. the more info on the wire the more chance of packet corruption, the more chance of packets getting malformed etc.. etc.. etc..

in a small home network (let's say 10 devices max) you're never going to be pushing the limits of a gigabit network, no matter how many large files you move or movies you stream from machine to machine.

one way or another...the switch you linked to is store and forward, so it's the more stable transmission method anyway.

[dsenette]

just to add... a lot of the issues mentioned in these switching articles and white papers etc.. also involve high level switching infrastructures where you've got multiple "hops" (nodes) between the source and the destination. such as a situation where you've got traffic traversing multiple switches between the server and the client. each segment of that type of network is a collision domain (an area where packet collisions can occur)....so the space between each of these switches can get flooded with packets bouncing back and forth across the segment traveling to and from each end node. if there's no flood control or packet shaping going on in that segment then you can get packet corruption


in your situation you have one collision domain (technically), which exists between your end point devices (computers, xbox, playstation, whatever) and the switch. since the switch is forwarding the packets to one of two places (out to the WAN or across the LAN) your collision chances are very minimal and the traffic will be controlled pretty well on the wire

[Spyderturbo007]

That makes sense, but what actually causes a packet collision? I'm pretty sure I know what a packet is, being 1492k of information, plus the header, but how they collide confuses me. The way I think of it, you're sending electricity across a wire which is going to travel at a constant velocity.

Thinking back to my college physics classes, it's like a tube filled with marbles. The electrons are already in the wire waiting to be moved. Add a marble at one end and another falls out the other side. So if you are sending packets one after another, I wouldn't think they would ever collide, but I know they do. Unless you had two devices sending packets at the exact same moment in time.

Also, what actually happens when a packet collides? I'm assuming the information gets "meshed" together and becomes worthless.

I know this has nothing to do with switches, but I was just thinking out loud.

[dsenette]

Thinking back to my college physics classes, it's like a tube filled with marbles. The electrons are already in the wire waiting to be moved. Add a marble at one end and another falls out the other side. So if you are sending packets one after another, I wouldn't think they would ever collide, but I know they do. Unless you had two devices sending packets at the exact same moment in time.

your physics background is going to help here...what happens if you've got that tube filled with marbles and you add a marble at both ends at the same time?

packet collisions rarely happen when traffic is heading one way...but network traffic is RARELY one way communication. back in the days of simplex communication (or half duplex) you only had one way comms at any one point in time. most modern networking equipment is full duplex so it's trying to send and receive at the same time on both ends. so without having something to control the sending of the packets (like a layer 2 or layer 3 switch) you're going to run into collisions where there's data heading both ways on the same wire at any given point in time. this is where collisions can occur which ends up in a corrupted packet... fortunately most modern switching equipment also has collision detection at a minimum and a lot even have collision avoidance to reduce the chances

[Spyderturbo007]

But I thought that you had a separate wire for send and receive, so there shouldn't ever be a collision because it's basically two separate one way streets? I also saw that, as you said, the switch creates a collision domain between itself and the node as opposed to something like a bridge. It seems that a bridge places multiple devices in the same collision domain, which would allow them to try and transmit at the same time causing a collision. But if we have one wire for transmit, one for receive and only one collision domain, how would there be a collision?

I hope I'm not wasting your time on this, but for some stupid reason, I like to know how all this stuff works.

Edited by Spyderturbo007, 24 February 2010 - 01:37 PM.

[dsenette]

you're not wasting my time....it's a complicated issue

the wire itself isn't really the issue (gets complicated right about now)...when talking about "time on the wire" you're actually talking about time between processing and forwarding

you're correct there's one pair for send and one pair for receive (actually in gigabit with cat6 there's 2 pairs for send and 2 for receive), the collision doesn't ACTUALLY happen on the wire it happens in the switch. when the packet hits the switches interface the switch has to process the packet and then take action. if switch A sends a response to switch B before Switch B was done fully sending the packet then switch B is going to get confused and drop the packet (even though the send is happening on a different packet). this can happen a bit more easily in a cut-through switch because switch A will send the ACK packet back to switch B as soon as it gets the packet header (a couple milliseconds before the full packet is received by switch B).

with store and forward you don't have this problem (or at least the problem is lessened) because switch A is going to wait till it gets the "footer" of the packet before it sends its ACK reply.


and again...collisions only become a real problem when you're moving A LOT of data at the same time in both directions from multiple sources to multiple destinations. MOST data that's transmitted isn't affected by collisions anyway. remember we're talking about milliseconds between a collision, the collision detection, and a resend of the packet. MOST applications in use in the home don't care about that kind of latency... we're not talking about seconds of latency it's probably less than 10 ms all together

[Spyderturbo007]

when the packet hits the switches interface the switch has to process the packet and then take action. if switch A sends a response to switch B before Switch B was done fully sending the packet then switch B is going to get confused and drop the packet (even though the send is happening on a different packet).

That makes perfect sense, thanks.

switch A will send the ACK packet

What is an ACK packet? I'm guessing it's an acknowledgment packet, letting switch A know the packet was received and processed?

[dsenette]

right...an ack packet is an acknowledgment of receipt..not necessarily a "yes this is good" or "no this is bad", just a "hey i got this". there are a lot of different packet types (and i'd love to find a comprehensive list but i'm not finding one right now)....

here you'll find a decent amount of information about TCP communications (no where near all of it) which is where all the acks, nacks, and syn-acks live hehe