[103419] in North American Network Operators' Group
Re: latency (was: RE: cooling door)
daemon@ATHENA.MIT.EDU (Frank Coluccio)
Sun Mar 30 01:03:29 2008
From: Frank Coluccio <frank@dticonsulting.com>
To: nanog@merit.edu, Mikael Abrahamsson <swmike@swm.pp.se>
Reply-To: frank@dticonsulting.com
Date: Sat, 29 Mar 2008 23:54:17 -0500
Errors-To: owner-nanog@merit.edu
Understandably, some applications fall into a class that requires very-short
distances for the reasons you cite, although I'm still not comfortable with=
the
setup you've outlined. Why, for example, are you showing two Ethernet switc=
hes
for the fiber option (which would naturally double the switch-induced laten=
cy),
but only a single switch for the UTP option?=20=20
Now, I'm comfortable in ceding this point. I should have made allowances fo=
r this
type of exception in my introductory post, but didn't, as I also omitted me=
ntion
of other considerations for the sake of brevity. For what it's worth, propa=
gation
over copper is faster propagation over fiber, as copper has a higher nominal
velocity of propagation (NVP) rating than does fiber, but not significantly
greater to cause the difference you've cited.=20
As an aside, the manner in which o-e-o and e-o-e conversions take place when
transitioning from electronic to optical states, and back, affects latency
differently across differing link assembly approaches used. In cases where =
10Gbps
or greater is being sent across a "multi-mode" fiber link in a data center =
or
other in-building venue, for instance, "parallel optics" are most ofen used,
i.e., multiple optical channels (either fibers or wavelengths) that undergo
multiplexing and de-multiplexing (collectively: inverse multiplexing or cha=
nnel
bonding) -- as opposed to a single fiber (or a single wavelength) operating=
at
the link's rated wire speed.
By chance, is the "deserialization" you cited earlier, perhaps related to t=
his
inverse muxing process? If so, then that would explain the disconnect, and =
if it
is so, then one shouldn't despair, because there is a direct path to avoidi=
ng this.
In parallel optics, e-o processing and o-e processing is intensive at both =
ends
of the 10G link, respectively. These have the effect of adding more latency=
than
a single-channel approach would. Yet, most of the TIA activity taking place=
today
that is geared to increasing data rates over in-building fiber links contin=
ues to
favor multi-mode and the use of parallel optics, as opposed to specifying
single-mode supporting a single channel. But singlemode solutions are also
available to those who dare to be different.
I'll look more closely at these issues and your original exception during t=
he
coming week, since they represent an important aspect in assessing the over=
all
model. Thanks.
Frank A. Coluccio
DTI Consulting Inc.
212-587-8150 Office
347-526-6788 Mobile
On Sat Mar 29 20:30 , Mikael Abrahamsson sent:
>
>On Sat, 29 Mar 2008, Frank Coluccio wrote:
>
>> Please clarify. To which network element are you referring in connection=
with
>> extended lookup times? Is it the collapsed optical backbone switch, or t=
he
>> upstream L3 element, or perhaps both?
>
>I am talking about the matter that the following topology:
>
>server - 5 meter UTP - switch - 20 meter fiber - switch - 20 meter=20
>fiber - switch - 5 meter UTP - server
>
>has worse NFS performance than:
>
>server - 25 meter UTP - switch - 25 meter UTP - server
>
>Imagine bringing this into metro with 1-2ms delay instead of 0.1-0.5ms.
>
>This is one of the issues that the server/storage people have to deal=20
>with.
>
>--=20
>Mikael Abrahamsson email: swmike@swm.pp.se
