思博伦MSTP测试仪表技术培训课件.ppt

You should always test Latency at the maximum Throughput you were able to achieve on your device. BUT, there will be a Sweet Spot that will become apparent. Sweet Spot--If you have Latency of 10ms at 100% load and a Latency of 5ms at 90% load would it be worth the extra 5ms of Latency for that 10% more of Throughput? That’s up to you. 100 90 80 70 60 50 40 30 20 10 5ms 6ms 7ms 8ms 9ms 10ms Regardless what you are testing, you need to know what it is and how it works. If you configure your router with bridging turned on, what are you testing? Are you testing a router or a bridge? What if you weren’t the one to configure it? Are the ports set to 10 meg, 100 meg, half or full duplex? Testing an edge device different than testing a core device. An edge device is specifically built to funnel multiple ports into one port. This device may be very limited on address cache space on the ingress ports. The core device assumes that all ports will be speaking to all ports. It job is to get as many packets moving as possible to as many places as possible. Core devices usually have redundant systems such as power supplies, port cards, redundant backplanes, redundant management modules, etc. Do you just wish to to test throughput and latency, or are you curious what would happen if you hit your router with millions of erred packets? Try to isolate your testing. Whether it is a core device or an edge device some or all of the ports will be dealing with up to 1k addresses per port. How many did you spec for in your design per segment/port? How many can your device keep track of? How fast does it learn new addresses, while still transferring data? Why should an uncongested port “pay” if other ports are congested? What if your device has only a limited amount of shared memory for ingress caching and all of it has been allocated to the overloaded port? Think you can get your few packets through on the uncongested port? At some point on your netwo