Sunday, January 27, 2013

TCP maximum throughput... LFN's

So in my previous post on Nagle's Algorithm I mentioned educating folks on maximum theoretical TCP throughput over Long Fat Networks  (LFN's) during a cross country Data Center migration.

I thought it might be a good idea to post a few of the calculations you can do yourself if so inclined.  There are quite a few web sites that will do this for you but I believe its a basic calculation a Network Engineer should know how to do, if for no other reason than to be able to "check the work" of those websites.

Calculating Maximum theoretical throughput
 
   tcp window in bits / latency in seconds  =  throughput (bps)

So to calculate the following:
   1.)  64KB Window Size
   2.)  50ms Round trip time
   3.)  Say 45mbp/s link
   4.)  Assume 0% packet loss for now

Convert Max TCP window to bits
  64KB = 65535 bytes   65535 * 8 =  524280 bits
Divide bits by latency in milliseconds
  524280 / .050 =  10485600 which is 10.4 mbp/s per flow

This is just the basic calculation and does not take into account congestion and congestion avoidance mechanisms, optimizations that can (at a price) increase window size, etc.  I expect to share some more on this interesting subject over the next few posts.

If you have a great interest in this and desire further information sooner there are tags associated with this post you can google but I would also recommend this excellent and recently updated book.
TCP/IP Illustrated Volume I






Nagle's Algorithm...

I found this post concerning TCP Nagle algorithm causing inefficient network performance within C#/.NET Web Applications  http://romikoderbynew.com/tag/nagle-algorithm/  and wanted to pass it along.  Nagle's Algorithm was developed to concatenate small, interactive data into single datagrams to increase efficiency in older interactive programs like Telnet.  In many cases it is still used by default without knowledge of the socket programmer.

One of the cool things I wanted to point out about the original post was the lengths the developers went to optimize performance.  Sadly this usually isn't the case.  As a Network Performance Analyst I am very aware of Nagle's, and other "optimizations" in the TCP stack as well as options that can be utilized in socket programming to tune TCP for certain types of applications.  Not always the case in the development world.  These guys really went to great lengths and utilized several tools to get to the bottom of their web app performance issues. Kudos!

TCP Congestion avoidance, buffer bloat, Nagle's ....  these are fascinating topics for the Performance Analyst but really need to be socialized more broadly to the IT world and specifically to developers. Not really intending to pick on developers but generally speaking they are trying to produce "working" code on schedule - not necessarily network optimized code.

Here are a couple of the tools they utilized.  The links are listed in the article as well...
dotTRACE
http://www.jetbrains.com/profiler/

Apachebench
http://httpd.apache.org/docs/2.2/programs/ab.html

Fiddler
http://www.fiddler2.com/fiddler2/





Saturday, January 26, 2013

Cell phone unlock a crime as of today...

Dwight Silverman @dsilverman writing on the Houston Chronicle Techblog covered this subject well so I am not going to get real in-depth other than to say be aware of the new rules before you invest in any used equipment you might be considering to unlock... and read the Techblog, it's an excellent read on this subject, and indeed on all things TECH.

My little rant...
So, when I read about the review of the DMCA by the Librarian of Congress a few months ago I was struck by the pure stupidity of this process.  The Digital Millenium Copyright Act is an ill-conceived, draconian and unfair law... but that's nothing new, what really aggravates me is we have the "Librarian of Congress" interpreting the law... Really?  The Librarian of Congress is the most qualified person we can find???  I just find the whole thing frustrating and arbitrary, ill-conceived and it pisses me off.  I don't really even care about phone unlocking myself except that it seems to me to not be necessary if you offer good, competitive price and products. It does make sense if you want to artificially lock people in and not let the free market work.  Information and Information device freedom is the hallmark of a progressive, information-based, free society... not locking things (even public domain information sometimes) up behind impenetrable walls. But... I feel like we are missing out on a treasure trove of possibilities as a society by not having more progressive telecommunication laws like other countries.
But, this was meant to be a quick post... I think I'll pick up on this theme in more depth in the coming weeks.

Read Mr. Silverman's assessment, and perhaps the whole ruling by "the Librarian" and be informed.

Wednesday, January 23, 2013

A little nostalgia...

Came across this evidence of my first IT Certification and digitized it the other day.
I attained this while serving the US Postal Service but had been in IT for a few years already doing
System Administration on smaller Unix systems as well as some programming (Cobol, RPG, Pascal).

I took my training for this Cert. in Washington DC and was in class with many folks from the DoD and State Department as well as a few East Coast banks who utilized larger WANG systems running batch Cobol.
Ah but the WANG days were coming to a close. Upon my return we started a project to install a "gateway" system between the WANG and Novell Netware.  Remember the old definition of "gateway", a system that connected two dissimilar systems.  Well there was a WANG-Netware gateway although I confess I don't remember much about it.


Very interesting days....