North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: latency (was: RE: cooling door)

  • From: Frank Coluccio
  • Date: Sun Mar 30 01:24:11 2008

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 switches
for the fiber option (which would naturally double the switch-induced latency),
but only a single switch for the UTP option?  

Now, I'm comfortable in ceding this point. I should have made allowances for this
type of exception in my introductory post, but didn't, as I also omitted mention
of other considerations for the sake of brevity. For what it's worth, propagation
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. 

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 channel
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 this
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 avoiding 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 continues 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 the
coming week, since they represent an important aspect in assessing the overall
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 the
>> 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 
>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 
>with.
>
>-- 
>Mikael Abrahamsson    email: [email protected]