Tài liệu KRONE - Catching up with TrueNet ppt

KRONE: 800-775-KRONE www.kroneamericas.com www.truenet-system.com
No part of this document may be reproduced without permission ©2001 KRONE, Inc.
Catching Up With TrueNet
TM
of the KRONE
®
TrueNet
TM
structured cabling system,
much of the cabling industry
has been involved in a game
of follow-the-leader.
Numerous papers have been
published, alternative theories of measuring throughput
performance have been advanced, and generally, the rest
of the industry has supported the notion that measuring
active performance of cabling systems is the wave of the
future.
However, KRONE must repectfully admonish our industry
peers for only getting the story half-correct. We
understand that this can happen when knowledge is
stretched into unfamiliar territories, and this paper
represents KRONEs contribution toward setting the
record straight. We will discuss the various errors and
omissions made in industry research attempts, and
demonstrate the correct methods of evaluating
throughput performance. The goal is to help the reader
understand the real value of throughput performance to
the overall operation of the LAN.
In this paper, we will reference two companion papers,
Network Troubleshooting Using TrueNet, and The

Effect of Errors on TCP Application Performance.
These documents serve as additional background
material for the theoretical impact of errors, and field
experiences with poorly performing LANs.
The first incorrect assumption that has been made is that
there is no need for post-installation active testing on
LANs. KRONE provides this service with every 200-plus
node installation of TrueNet. This subject is dealt with
extensively in the Network Troubleshooting paper, so let
us merely summarize here. The two key benefits of
post-installation active testing are:
One: Prove the KRONE-certified cable installer did a
quality job, and ensure all the cabling components work
properly when installed as a complete system.
Two: Check the integrity of the active devices on the
end-users network.
SINCE
THE 99
LAUNCH
You will notice that only one of these benefits has
anything to do with the cabling itself. The assertion that
quality checking components in the factory means that
the network will run well ignores the fact that a
network is made up of thousands of discrete compo-
nents that all need to be installed properly and work
together seamlessly.
This leads us to our second incorrect assumptionthe
one that really sinks most of the other papers weve
seen out therethe assumption that all active ports
are created equal. Laboratory and field research

(shown in Network Troubleshooting) by KRONE shows
without question that the individual ports on active
devices perform differently, both as senders and
receivers. Think all the ports on that 24 port switch
perform exactly the same? Think again. If you have the
exact same make and model of switches in your
network, do they all have identical transmission
characteristics? Again, no. Perhaps the most telling of
all: is there any relationship between what you paid per
port and how well it performs? Unfortunately, not
really. Throughput experimentation that does not take
into account the performance characteristics of
individual transmit/receive ports can easily lead to an
incorrect conclusion. Various experimental models weve
seen have failed to include key pieces of relevant data:
for example, were each of the sample channels tested
using the exact same ports on the active devices? Were
the experiments repeated using different ports? What
were the characteristics of the senders and receivers?
We can only assume that the omission of these critical
points in the papers that we have read means that
these facts arent understood, or arent considered
relevant. Port performance is very relevant, as we will
show.
Other troubling examples seem to indicate that the
experimenters dont understand how the active systems
that they are testing even work. One demonstration in
particular supposedly shows degradation of streaming
video over poor cabling. The results claim that one lost
packet caused one frame to drop, resulting in a jerky

picture. Nice try, except the 40 second, 56 MB file used
KRONE: 800-775-KRONE www.kroneamericas.com www.truenet-system.com
No part of this document may be reproduced without permission ©2001 KRONE, Inc.
simply connect-
ing a 90 meter
basic link or
channel directly
to a Smartbits at
both ends to
certify zero bit
errors is
extremely mis-
leading.
in the experiment at 15fps would mean that if one
packet = one frame, then each packet would have to
be 93,000 bytes long. Not likely, considering the
Ethernet 1518 byte packet length limit.
Other experiments test technologies that are irrelevant
to the majority of LAN administrators, such as serial
digital video, which was intended for broadcast
television. This would be relevant if typical MIS
departments also had a television studio in the office,
but obviously this is not the case.
The mathematical approach has also been used, trying
to equate the probability of bit errors to such electrical
parameters as near end crosstalk (NEXT) noise,
insertion loss deviation, and signal to noise ratio. While
this is theoretically interesting, it does not address the
dynamics of a real world network. In an operating
network, variables such as transmitters, receivers,

external noise, cabling components and installation
practices combine to produce a complex and dynamic
system. Attempting to predict the performance of a
complex system like a LAN by conducting mathematical
analysis of just one element ignores the fact that
network performance is more than just the sum of its
parts.
Finally, recent experimentation with a device called
SmartBits
TM
manufactured by Spirent Communications
has been widely reported in the trade literature. In
fact, KRONE was the first to identify this product as a
possible tool to evaluate different cabling systems.
Originally, the product was designed to test switch and
hub performance by bombarding ports with simulated
network traffic, but only over a short distancein
other words, connected by a patch cord only. It is this
ability to generate traffic and count the packets as
they arrive at the other end that seemed ideal to test
whether or not cabling systems by themselves contrib-
uted to packet loss. However, upon experimentation,
we discovered that the signal characteristics in a
SmartBits NIC is abnormally good, and as such is not
representative of a real-word device such as an off-the
shelf NIC or a switch port.
Papers now circulating in the industry claim third party
throughput verification of cabling systems using
SmartBits. These experiments were conducted by
simply connecting a 90 meter basic link or channel (with

two, three or four connections) directly to a SmartBits
at both ends to certify zero errors (10
-10
). This
conclusion is extremely misleading, because the
methodology fails to take into account the abnormally
good SmartBits NICs as mentioned earlier. What the
methodology didnt take into account is that you can
still get zero errors with a 140 meter channel40%
longer than the standards allow! In fact, KRONE
repeated the experiment shown in the third party
verification with a 140 meter, four connector channel
that had the cable torn apart in the middle, kinked,
mangled,crushed, twisted, and with some of the
insulation removed. We still got zero errors with the
SmartBits. Clearly, this is due to unusually high signal
strength and unusually capable receivers on the
SmartBits NICs. A SmartBits NIC costs thousands of
dollarsno wonder theyre so good. However, how
many network managers ever paid that much for a
NIC in a LAN? So, its no wonder that the third party
verification of a reasonably well made 100 meter
cabling channel showed no errors. Directly connecting
a SmartBits will yield error-free results over almost any
channel.
How its Really Done
Is the use of SmartBits incorrect? No, but the direct-
connection methodology is flawed. First, one must
normalize the strength of the sending card, and then
collect the signal at the opposite end through

something approximating a normal receiver, instead of
using the super-receiver in the SmartBits.
First, to normalize the SmartBits signal, the simulated
traffic should be sent through a device that actually
regenerates the signal, and sends it out again using
one of the transmitters (ports) on the device. This
takes the abnormally strong SmartBits signal and re-
creates it along more normal parameters. You can do
this either with a hub or a switch, by connecting it to
the SmartBits NIC with a short patch cord. Using a
store-and-forward device such as a switch also
ensures that if SmartBits or the short patch cord
corrupt any packets, they are discarded before being
sent out over the cabling system under test. An
A channel with this mess in it, and
still ZERO ERRORS with SmartBits!
KRONE: 800-775-KRONE www.kroneamericas.com www.truenet-system.com
No part of this document may be reproduced without permission ©2001 KRONE, Inc.
Is the use of
SmartBits
incorrect? No,
but the direct-
connection
methdology is
flawed.
incoming packet from SmartBits that doesnt pass the
switchs CRC check would be discarded before being
sent out over the cabling system; therefore, only
packets corrupted by the switchs transmitter or the
cabling system itself would be counted at the far end of

the channel. If you used a hub for this purpose, since a
hub just repeats a signal and doesnt read the CRC, it
would pass along errors between the SmartBits and the
hub, so it really doesnt isolate the channel under test.
Therefore, a switch is a better choice.
Second, on the receiving end, you need to use some-
thing approximating a normal NIC. There are various
NICs out there that have special drivers, making them
capable of counting the packets received, and reporting
errors. We used a Digitech
®
LAN900
TM
card and
software to do this, although there are other products
on the market also capable of this same thing. One
also has to decide whether to use a PCI (equivalent to a
desktop PC NIC) or PCMCIA (equivalent to a laptop NIC)
version of the receiving card. Upon evaluation of various
options, we chose the PCMCIA version, because these
proved to be more likely to count an error when
receiving a packet with marginal signal characteristics.
A better NIC might be able to equalize partially
corrupted signals and make sense out of them; so it is
best to use a NIC with marginal receiving properties to
represent real-world worst case. In addition, notebook
computers that use PCMCIA cards have become
commonplace in the LAN.
Throughput Test Methodology:
Throughput testing of cabling channels is best accom-

plished with the three devices mentioned previously:
1. A SmartBits SB200 chassis with MIL-7710 10/100
Base-TX cards as the packet generator.
2. A Cisco Catalyst 2900 10/100 Base-TX switch to
regenerate and normalize the signal.
3. A typical 10/100 NIC with a special driver to report
errors (we used a Digitech LAN900).
For these experiments, we tested Fast Ethernet 100
Base-TX performance, as this is the most widely
deployed technology in todays LANs. We tested two
different cabling channels using this set-up, a Cat 5e
KRONE TrueNet C5eT channel, and a channel of off-the
shelf Cat 5e components from recognized manufactur-
ers that approximates a mix and match cabling
solution. The channels will be described in more detail
later.
It is important to first establish if there is any error rate
inherent to the devices themselves, prior to testing
channel throughput. To do this, we connected the
SmartBits card directly to the Cisco switch with a short
patch cord, and then out again directly to the LAN900
card with another short patch cord. This will show us if
any of the port combinations are grossly better or worse
than others. Upon testing numerous port pairings, it was
found that the error rate was zero, in all cases. A screen
shot of the LAN900 control window is shown below.
The detail indicates that 6,482,321 frames were sent
with no (frame) errors. In all the experiments, the
maximum Ethernet frame size of 1518 bytes was used.
There did not appear to be any inherent problems with

the ports used on the switch, at least when signal
strength is optimum over a short distance.
Now, it is important to discern the subtle differences
between the ports, so that we can see a real-world
best and worst case scenario from this particular
switch. Using the two cabling channels evaluated in the
experiments, we tested throughput performance on the
switch using various port combinations to see which
combinations tend to perform better and which ones are
worse. We finally settled on ports 10 and 16 as the best
case and 1 and 2 as the worst case for this switch.
Cabling Channel Test Bed
Finally, we get to channel comparisons. For both the
KRONE channel, and the mix and match channel, we
used a 100 meter four-connection Category 5e channel,
representing the greatest number of connections and the
greatest physical distance allowed by the TIA/EIA
standards. Each channel consisted of a patch panel, a
block representing a cross connect equipment field, a
block representing a consolidation point, a jack repre-
senting the workstation outlet, Category 5e UTP cable
for connection, and two seven-foot patch cords. The
first channel that we tested was a KRONE TrueNet C5eT
certified channel.
LAN900 Control Screen
KRONE: 800-775-KRONE www.kroneamericas.com www.truenet-system.com
No part of this document may be reproduced without permission ©2001 KRONE, Inc.
Testing the KRONE TrueNet Channel
As the detail from the
LAN900 screen shot on the

left shows, for the best
case port combination, out
of 4,089,553 frames, there
was only one error
detected.
This corresponds to a bit
error rate of 2*10
-11
, by
the following math (this will serve as the basis for all
subsequent examples):
We first need to assume that the one frame error was
the result of just one bit error (this carries forward to all
examples). In reality, its possible that there was more
than one bit error, but the probability of this is
extremely small and the net effect of one bit error or
two bit errors (or ten, for that matter), in a frame is
exactly the samethat one frame is thrown out.
Therefore:
4,089,553 frames * 1518 bytes per frame * 8 bits/byte
= 49,663,531,632 bits.
1 bit error divided by 49,663,531,632 bits = 2*10
-11
or .000000002%
KRONE Channel with Best
Case Ports on the Switch
In the second test, we
tested the worst case port
combination and found
that the error rate

increased to six errors in
3,122,967 frames, or an
error rate of 1.6*10
-10
(.000000016%).
KRONE Channel with Worst
Case Ports on the Switch
Since this is the exact same channel we tested in the
best case port combination, we can attribute the
rise in errors to the subtly different performance of
these ports (perhaps also in combination with the
receiving characteristics of the LAN900 card).
Testing the Mix and Match Channel
The second channel we used was laid out exactly the
same as the first, and is comprised of off the shelf
cabling components, all
Category 5e compliant
from recognized
manufacturers. This
would approximate a
mix and match
solution, often chosen
by combining various
manufacturers
productssince few
manufacturers besides
KRONE actually make all
the pieces needed to
create a channel. Again,
the best and worst case

ports on the switch are
used in the measure-
ment. As the screen
shots show, the error
rate increases dramati-
cally. For the best case
channel, the error rate is 1873 bit errors out of
1,928,463 frames, or 8*10
-8
(.000006%) . The worst
case channel has a staggering 5291 errors after just
183,405 frames, a bit error rate of 2.4* 10
-6
(.00024%).
(Note the difference between the error rate in the
screen shots, and the BER rate calculated. Remem-
ber the screen shots display the frame error rate, not
the Bit Error Rate.)
Effect of Alien Crosstalk
Finally, to demonstrate the dramatic effect that
outside noise can have on a cabling system, we
devised a test to simulate very strong alien crosstalk.
Alien Crosstalk is the noise from adjacent transmitting
cables in a bundle that can be heard through the
sheath on the cable being tested. The test bed was
modified to include an identical channel directly next
to the channel being tested.
Mix and Match Channel with
Worst Case Ports on the Switch
Mix and Match Channel with

Best Case Ports on the Switch
KRONE: 800-775-KRONE www.kroneamericas.com www.truenet-system.com
No part of this document may be reproduced without permission ©2001 KRONE, Inc.
The second channel is energized by the SmartBits in
exactly the same manner as the first; in order to create
noise that replicates real traffic. This represents an
extreme worst-case alien crosstalk scenario, since in
reality its unlikely that a neighboring cable would be
constantly running at 100% utilization, and directly
adjacent for the entire run. However, this is a more
realistic simulation of outside noise than other attempts
we have seen, notably an experiment where the two
unused pairs under the same sheath were energized to
simulate crosstalk. In reality, that situation would not
occur.
In the extreme crosstalk scenario, it was observed that
even the best case channels are affected. The TrueNet
best case channel with the external noise records 35 bit
errors in 2,793,835 packets, or a BER of 1*10
-9
(.0000001%), while the off the shelf best case
channel clocks 5640 errors in 1,331,291 packets, or a
BER of 3.5*10
-7
(.00003%). We would expect to see an
increase in errors as noise in the system rises, as the
cables used are unshielded (UTP), and hence not
completely immune to outside noise.
The Final Straw
Just to prove that these experiments were not shaded to

favor the TrueNet solution, we offer one of the most
troubling pieces of evidence of all. Most end-users insist
on hand-held test results from their installation contrac-
tors for new installations. We demonstrated that the
real-world performance (bit errors), of these channels
are dramatically different.
Now look at the
actual hand-held
test result screens.
Which is the TrueNet
and which is the one
with the errors?
Actually, the
TrueNet channel is
the one with the
lower reading. So
how is an end-user
to know if the
Category 5e
compliant system
they purchased has
errors? The only
way to tell the difference between meeting the
standards and delivering optimum performance is to
perform active testing on the operating network.
KRONE has recognized this situation, and developed the
TrueNet cabling system and active testing methodology
to ensure that IT managers get a true picture of what
they paid for. KRONE remains the only structured
cabling provider in the world that performs on-site

active testing of the installed network.
The Effect of Errors on your Applications
Clearly, there is a significant difference between the
error rates of the two channels tested, but at first
glance, even an error rate of .000024% seems tiny.
Therefore, lets look at the previous examples in
another way. The LAN900 card indicates an average
frame per second rate (FPS) for each of the experi-
ments. Lets look at Table 1, which shows the error
performance of the best and worst case channels as a
function of time.
Now the effect of all those errors seems much more
tangiblebut just what would happen to your
applications if you had nodes racking up 148 errors per
second?
Tested Channel FPS* # Frames Test Duration Errors Result
(seconds)
KRONE w/ best case ports 5736 4,089,553 712 1 One error per 11.9 minutes
KRONE w/ worst case ports 5642 3,122,967 554 6 One error per 1.5 minutes
Mix&Match w/ best case ports 4061 1,929,463 475 1873 4 errors per second
Mix&Match w/ worst case ports 5147 183,405 36 5291 148 errors per second
Table 1: Error Performance Over Time
*Average FPS reported; variation in FPS is a result of the switch.
KRONE: 800-775-KRONE www.kroneamericas.com www.truenet-system.com
No part of this document may be reproduced without permission ©2001 KRONE, Inc.
KRONE, Inc.
North American Headquarters
6950 South Tucson Way
Englewood, CO 80112-3922
Telephone: (303) 790.2619

Toll-Free: (800) 775.KRONE
Facsimile: (303) 790.2117

www.kroneamericas.com
www.truenet-system.com
The time impact of
errors on TCP is espe-
cially important,
because IS managers
can buy more band-
width to deal with
efficiency loss, but
they can never buy
more time to speed
up transaction
processing.
The effect of errors on application performance is the
ultimate question at hand. The KRONE white paper,
Effects of Errors on TCP Performance provides some
answers. To summarize the main conclusions of this
very in-depth paper, we learn the following:
· The majority of current applications rely on TCP
(embedded in the Ethernet frame) as the main
information delivery protocol. This includes FTP,
virtually all web-related applications, and virtually all
transaction-oriented systems (such as databases).
· Errors at the Ethernet level effect the proper
functioning of TCP.
· In a perfectly functioning node, Ethernet efficiency
is mathematically limited to 92.9%, due to TCP and

Ethernet overheadmeaning that only 92.9% of
the transmitted information is the actual data
packetthe rest is setup, addressing and other
information.
· The paper illustrates various examples of efficiency
degradation from bit errors, including a mathemati-
cal example where just two bit errors over a short
period of time reduces Ethernet efficiency to
63.5%.
· Even more dramatic than the mathematical
calculation of efficiency degradation is the time
impact of a few errors. In the same mathematical
examples, the projected time to complete a
transaction actually doubles, due to the logical
construction of TCP, and how it deals with errors.
· The time impact of errors on TCP is especially
important, because while IS managers could buy
more bandwidth to deal with efficiency loss, they
cant buy more time to speed up the transactions
that are bogged down trying to resolve errors.
Now consider the impact that a 2.4*10
-6
BER (148
errors per second, from the previous example) can
have on a database transaction, if just two bit errors
could double the time necessary to complete an
operation.
Conclusion
It can be very difficult to make sense of all the claims in
the marketplace regarding throughput performance of

cabling systems. This paper was designed to demon-
strate that this very complex issue has been embraced
by the industry, but often poorly executed in subse-
quent counter-claims to the KRONE TrueNet message.
Well meaning experimentation without a proper
understanding of the underlying principles of networks
and TCP have often led others in the industry to
declare that throughput is important, without
understanding why. Many of the claims have been
made based on experiments that involve forms of video
that are very unlikely to appear in a data center. The
underlying implication is that if these systems carry
video, they should easily carry data efficiently.
However, this conclusion is not necessarily valid. To gain
a real sense of how well a system will carry data, the
experiments need to focus on the technologies that are
widely deployed in the field. Hence, our focus was on
Fast Ethernet and transaction oriented processing.
This paper demonstrated that the SmartBits testing
methodology that has been employed in the industry
requires further steps to make it a valid tool for
throughput measurement. We also demonstrated that
not all Category 5e is what it seems to be, especially as
reported by hand-held field testers. The conclusion
reached is that to ensure proper performance in a
complex installed system like a LAN, on-site active
testing must be done to tell the difference between
merely meeting the standards, and delivering error-free
performance.
Finally, by reference to another KRONE paper on TCP

application performance, we concluded that errors in
networks are a very real problem for applications,
particularly those that are transaction oriented. Such
errors manifest themselves in slower application
performance and additional bandwidth requirements.
However, since errors cause a demand for more
transaction time, these issues cannot automatically be
fixed merely by throwing bandwidth at the problem.
Root cause elimination of errors is a much more
effective strategy for optimal LAN performance.
About The Authors:
Tim Takala is the Technical and Laboratory Manager for
KRONE, Inc., having recently joined the US team from
KRONE Australia. He helped develop and implement the
technical methodologies behind the TrueNet warranty
program. He also designed and supervised the testing
methodolgies employed in this paper. Mr. Takala holds an
Industrial Engineering degree from the Sydney Institute of
Technology.
Bill Fetter is the TrueNet Global Coordinator for KRONE, Inc.
He has been instrumental in the form and formation of the
TrueNet program since its inception. Mr. Fetter holds an
MBA from Indiana University.
KRONE, TrueNet and C5eT are trademarks of KRONE
All other trademarks are property of their respective owners.