Silly me. I didn't mean "turns" alone, but also intended to include the number of state "transitions" (e-o, o-e, e-e, etc.) in my preceding reply, as well.
Frank A. Coluccio DTI Consulting Inc. 212-587-8150 Office 347-526-6788 Mobile On Sun Mar 30 16:47 , Frank Coluccio sent: >Mikael, I see your points more clearly now in respect to the number of turns >affecting latency. In analyzing this further, however, it becomes apparent that >the collapsed backbone regimen may, in many scenarios offer far fewer >opportunities for turns, and more occasions for others. > >To the former class of winning applications, because it eliminates local >access/distribution/aggregation switches and then an entire lineage of >hierarchical in-building routing elements. > >To the latter class of loser applications, no doubt, if a collapsed backbone >design were to be dropped-shipped in place on a Friday Evening, as is, the >there >would surely be some losers that would require re-designing, or maybe simply >some >re-tuning, or they may need to be treated as one-offs entirely. > >BTW, in case there is any confusion concerning my earlier allusion to "SMB", it >had nothing to do with the size of message blocks, protocols, or anything else >affecting a transaction profile's latency numbers. Instead, I was referring to >the "_s_mall-to-_m_edium-sized _b_usiness" class of customers that the cable >operator Bright House Networks was targeting with its passive optical network >business-grade offering, fwiw. >-- > >Mikael, All, I truly appreciate the comments and criticisms you've offered on >this subject up until now in connection with the upstream hypothesis that began >with a post by Michael Dillon. However, I shall not impose this topic on the >larger audience any further. I would, however, welcome a continuation _offlist >_ >with anyone so inclined. If anything worthwhile results I'd be pleased to post >it >here at a later date. TIA. > >Frank A. Coluccio >DTI Consulting Inc. >212-587-8150 Office >347-526-6788 Mobile > >On Sun Mar 30 3:17 , Mikael Abrahamsson sent: > >>On Sat, 29 Mar 2008, Frank Coluccio wrote: >> >>> 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? >> >>Yes, I am showing a case where you have switches in each rack so each rack >>is uplinked with a fiber to a central aggregation switch, as opposed to >>having a lot of UTP from the rack directly into the aggregation switch. >> >>> 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. >> >>The 2/3 speed of light in fiber as opposed to propagation speed in copper >>was not in my mind. >> >>> 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 >> >>My opinion is that the major factors of added end-to-end latency in my >>example is that the packet has to be serialisted three times as opposed to >>once and there are three lookups instead of one. Lookups take time, >>putting the packet on the wire take time. >> >>Back in the 10 megabit/s days, there were switches that did cut-through, >>ie if the output port was not being used the instant the packet came in, >>it could start to send out the packet on the outgoing port before it was >>completely taken in on the incoming port (when the header was received, >>the forwarding decision was taken and the equipment would start to send >>the packet out before it was completely received from the input port). >> >>> 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. >> >>No, it's the store-and-forward architecture used in all modern equipment >>(that I know of). A packet has to be completely taken in over the wire >>into a buffer, a lookup has to be done as to where this packet should be >>put out, it needs to be sent over a bus or fabric, and then it has to be >>clocked out on the outgoing port from another buffer. This adds latency in >>each switch hop on the way. >> >>As Adrian Chadd mentioned in the email sent after yours, this can of >>course be handled by modifying or creating new protocols that handle this >>fact. It's just that with what is available today, this is a problem. Each >>directory listing or file access takes a bit longer over NFS with added >>latency, and this reduces performance in current protocols. >> >>Programmers who do client/server applications are starting to notice this >>and I know of companies that put latency-inducing applications in the >>development servers so that the programmer is exposed to the same >>conditions in the development environment as in the real world. This means >>for some that they have to write more advanced SQL queries to get >>everything done in a single query instead of asking multiple and changing >>the queries depending on what the first query result was. >> >>Also, protocols such as SMB and NFS that use message blocks over TCP have >>to be abandonded and replaced with real streaming protocols and large >>window sizes. Xmodem wasn't a good idea back then, it's not a good idea >>now (even though the blocks now are larger than the 128 bytes of 20-30 >>years ago). >> >>-- >>Mikael Abrahamsson email: [EMAIL PROTECTED] > >
