1. Home
  2. Embedded Programming
  3. Qualifying (quantifying!) network switches

Qualifying (quantifying!) network switches

Hi,

Given a switch having dubious documentation ("This is the power plug. These are the network connection points. *Fini*"), what sorts of techniques might be fruitful in empirically deriving the characteristics of the switch? I'm looking for solutions that can be deployed "unattended" and for low cost (i.e., part of a deployed system instead of a special stand-alone device)

[Note that, for the time being, I am only interested in temporal characterizations. I am, also, willing to assume that all ports behave identically]

E.g., as a minimum, you would want to know any *fixed* latencies involved in frame routing.

Beyond that, the policy(ies) that the switch uses for routing frames (cut-through, store-and-forward, adaptive, hybrid, etc.) and the structure and depth of its elastic store.

The goal of this exercise is to be able to quantify the range of transport delays an arbitrary frame is likely to experience when it encounters the switch.

AFAICT, there is no way to do this without also being able to characterize the NIC(s) in your "tester" (i.e., if you can't predict how rames get placed onto -- and pulled off of -- the wire on *your* end, then this is a big variable in the overall process).

Thanks!

--don

Reply to
Don Y
Loading thread data ...

Measuring switch performance is established science and business. The Tolly Group

formatting link
makes mostly this. So the easiest thing is find a product that uses the switch chip you are interested in an read the Tolly group report on it.

I you want to measure yourself, use a frame-level driver, use a cross-over cable first without the switch between two systems, then measure the ping-pong time. I think you can put some network adapters into loop-mode, so there would be no SW involved. Then add the switch.

If you do target moderate speeds you might be able to drive several network cards in one system and do more complex traffic pattern.

Andreas

Reply to
acd

Thanks, I'll make a note of the site!

It's not a question of picking a switch and finding the information about it but, rather, having to *work* with some existing switch (ideally, without knowing what make/model is involved).

I already have access to this information.

That only tells you part of the story. E.g., I could make an educated guess about whether the switch always operates in store-and-forward mode (assuming no other traffic is present while I am testing). But, you'd never be able to saturate the switch with just two nodes. So, you could never get a feel for where the limits on the elastic store are.

[actually, I wonder if I could force frames directed to *myself* out onto the interface and effectively double the traffic to "myself" (assuming the other node is also sending to me continuously)? That might be a good INefficiency hack! :> ]

I am assuming I have more than one node available to "conspire" against the switch in coordinated fashion. What I am trying to get a feel for is what sort of traffic patterns to try in order to characterize the switch as thoroughly (though not necessarily EXHAUSTIVELY) as possible.

I realize that the traffic on the other nodes will always represent an unknown in the process. As will the actual network topology. So, I can't expect a complete solution but, rather, a first order approximation...

Reply to
Don Y

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.