Subject: RE: [bmwg] RFC 1242 and negative latencies (fwd)

From: "Conrad C. Nobili" <[email-masked]>
Date: Thu, 8 Feb 2007 18:12:17 -0500 (EST)

I sent this earlier (modulo correcting some typos just now) but it
didn't go through.  I guess most of it has been said by others by
now, but may still be of some minor interest to a few.

Curtis' recent mail suggests that these cut through devices might
still be of interest in some environments.  I suppose if you're
using really large packet sizes with relatively low wire speeds,
serialization delay may still matter.

--cn

Conrad C. Nobili  <[email-masked]>  Harvard University UIS NOC

---------- Forwarded message ----------
Date: Thu, 8 Feb 2007 14:20:47 -0500 (EST)
From: Conrad C. Nobili <[email-masked]>
To: Timmons C. Player <[email-masked]>
Cc: [email-masked]
Subject: RE: [bmwg] RFC 1242 and negative latencies

Yeah, those cut through devices used to be popular.  I've been out
of the device testing business for some years, but would guess that
nobody bothers doing cut through any more.  We quit doing simple
performance testing when it became clear that line rate performance
was becoming easily achievable with nearly any old box of parts.

Anyway, the motivation behind the last-bit-to-first-bit measure is
that it's trying to capture the time it takes the device to make
its switching decision, the presumption being that any sane --
store and forward -- device would wait until it had the last bit,
make sure the checksum was valid, and then make its switching
decision and immediately forward it (starting with the first bit
obviously).  A nice side effect of this definition is that this
time shouldn't really change with packet size.

With cut through devices you used to get negative latencies with
this definition.  But people don't deal with negative numbers very
easily, so using a nth-bit-to-nth-bit measure was more sane.  And
in any case, the semantics of nth-bit-to-nth-bit is more natural
to some people -- it is not the time it takes the device to make
its switching decision, but rather the amount of time the device
holds onto a given bit of the packet.  It's actually just as good
if you record the nth-bit-to-nth-bit time anyway, since you can
easily calculate the last-bit-to-first-bit time if you have the
frame size.

--cn

Conrad C. Nobili  <[email-masked]>  Harvard University UIS NOC

> The "wire" concept is interesting, but the negative latency is an
> artifact of the difference between typical router and switche
> architectures, more or less.  Any network device could be expected to
> fully receive a packet before sending it out (on another interface,
> presumably).  After all, logically, you have to process the checksum at
> the end of the frame to know if it is a valid frame and can be
> forwarded.
> 
> The early LAN switch designers took advantage of the nature of Ethernet
> to short cut this.  They begin emitting the packet on the outbound
> interface before they fully received the packet on the inbound
> interface.  This creates negative latency compared to the typical router
> handling.  IF the packet did have a defect, revealed when the checksum
> was examined, they would use the Ethernet "jam / collision" signal to
> trash the partially emitted packet.  Clever and screwy by the
> definitions developed for a pure store & forward world.  Hence, negative
> latency.
> 
> (Then there's the einstein switch which sends the entire packet before
> receiving it....)
> 
> cheers,
> 
> Jim McQuaid
> 
> NetQoS
> 
> 
> 
> -----Original Message-----
> From: Timmons C. Player [mailto:[email-masked]]
> Sent: Thursday, February 08, 2007 1:40 PM
> To: [email-masked]
> Subject: [bmwg] RFC 1242 and negative latencies
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> So, I was perusing RFC 1242 the other day and reread the discussion
> section for the definition of latency in section 3.8.  I was a little
> surprised by the reference to negative latency values, but after
> thinking about how store and forward latency is measured, it occurred to
> me that negative latencies should definitely be producible when
> measuring latency using the definition for store and forward.
> 
> Now remember, store and forward is measured in the following way:  The
> transmit timestamp is when the DUT receives the last bit of the frame.
> The receive timestamp is when the DUT transmits the first bit of the
> frame.  If our DUT is a wire, then the receive timestamp should occur
> BEFORE the transmit timestamp because the time to transmit a bit across
> the wire is significantly shorter than the time to put all of the bits
> on the wire.  Thus, the test box should receive the first bit before it
> transmits the last bit, and should thus report a negative latency value.
> 
> I also calculated this nifty table that shows store and forward latency
> values for a 1 meter long cable assuming a propagation delay of 59%
> found that number at of the speed of light (I found the 59% number on a
> website somewhere, however, using 1 or 100 doesn't really make much of a
> difference at < gig speeds) at various frame sizes.
> 
> Calculated Store and Forward Latency (ns)
> Frame Size	10Mbps	100Mbps	1000Mbps	10000Mbps
> 64	-51194.35028	-5114.350282	-506.3502825	-45.55028249
> 128	-102394.3503	-10234.35028	-1018.350282	-96.75028249
> 256	-204794.3503	-20474.35028	-2042.350282	-199.1502825
> 512	-409594.3503	-40954.35028	-4090.350282	-403.9502825
> 1024	-819194.3503	-81914.35028	-8186.350282	-813.5502825
> 1280	-1023994.35	-102394.3503	-10234.35028	-1018.350282
> 1518	-1214394.35	-121434.3503	-12138.35028	-1208.750282
> 9016	-7212794.35	-721274.3503	-72122.35028	-7207.150282
> 
> Anyway, I'm curious as to other people's opinions on negative latency.
> Yes, I realize that correctly setup measurements of a DUT probably
> should not produce negative latencies, however a loopback test using an
> arbitrary length of cable SHOULD.  However, I haven't found any test box
> that will report them. :(
> 
> Also, if anyone can find a fallacy in either my logic or my math, I
> would appreciate it.
> 
> Timmons
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (MingW32)
> 
> iD8DBQFFy26UPps6tU0vhXERAlYQAJ47HYR8Xnp5bfjUAZ0X+6xVsnpJLgCgsUBk
> miZm1bGa6lNFXkdndhxqSw8=
> =PC2d
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> bmwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/bmwg
> 
> _______________________________________________
> bmwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/bmwg

_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg