Curious About Signal/Network/GPS on Your Blackberry? Have a FREE App!

I spent a bit of time digging around for better information on my Blackberry's performance, only to find precious little assistance in the native Blackberry OS.  After a bit of digging, I found a VERY nice free app - Signalloc v5.

It's all there - signal strength, network services avaialble, current ID and channel, plus a full screen of phone network details, another for GPS internals, and yet others for WLAN and device details.  You can (with Google Maps) plot your cell sites on a map, and you can also export your "saved sites" to either CSV or Google Earth.

This is a GREAT app for the tech junkie who wants to see 'behind the scenes' of their Blackberry...grab an OTA install from the link below.

Signal-Location Utility v5

Optimize your Home (or Business) Wireless--FREE--with NetSurveyor

One of my Twitter friends pointed me to the folks at Nuts About Nets, and there's no doubt that my quick visit to the NAN website has already paid tangible dividends.  One word, folks - NetSurveyor.  You won't find a better FREE wireless network profiler out there; whether you're a bithead by trade (like me) or just a power user of home 802.11g/b/n wireless, you'll love this Windows application.  The first thing I did was check channel usage, and I found that 9 of the 13 home WLANs in range of my home (including my own) were fighting on a single channel.  One quick configuration change moved my WLAN to an otherwise unused (and non-overlapping) channel, and I saw immediate performance improvement in my home WLAN of 20+ devices. (For details of 802.11 channels and channel selection, NetGear has a good, basic explanation.)

Alongside NetSurveyor lies NetStress, an 802.11 benchmarking and stress-test tool.  I'll be using NetStress in the near future, just to see what kind of boundaries I can push with my existing wireless infrastructure.

Get NetSurveyor - NOW.

Free Tools » Nuts About Nets

Data Throughput with HTTP, SMB and NRPC - It Isn't Just Network Latency

Customers are often puzzled by the "speed difference" seen when transferring data via Lotus Notes, as compared to HTTP or SMB file transfers; these differences are most often seen in conditions of high network latency, but they are always evident to some degree.  What most folks DON'T realize is that "network latency" is only an exacerbating factor; the real "root cause" reasons are inherent differences among the protocols.  Let's go deeper...

HTTP is, for all intents and purposes, a streaming protocol.  A single request, such as an HTTP GET, results in a (sometimes) lengthy, but uninterrupted, stream of data in response.  It's just "GET", "200 OK" and a blast of data; the protocol performs no metering or interruption of the inbound data flow.  Basically, it looks like this:

GET /booga.zip HTTP/1.0

200 OK <followed by all of booga.zip in one stream>

The limiting factors are, in this case, at the TCP/IP layer itself, in the form of small TCP windows, TCP's "slow start" behavior, and/or congestion avoidance mechanisms.

SMB has its own limiting factor - one that most users of "disk shares" don't know.  SMB/CIFS requests are limited to 64Kb in size; thus, any file transfer is a series of requests, each of which is up to 64Kb in size.  So, no matter how "fast" one's network might be, SMB still operates in 64Kb "chunks" and must issue a new request for each "chunk."  Transferring our booga.zip now looks like this:

Create AndX booga.zip

Create AndX

Read AndX offset 0x0 data 0xf000

Read AndX (64K chunk of data)

Read AndX offset 0xf000 data 0xf000

Read AndX (next 64K chunk of data)

(Repeat until all data transferred...for a 2Mb file, about 32 iterations)

Now, each of these is a network transaction, so now we have a full network round-trip added for each ReadX request, plus the 64Kb blocking overhead on both ends; you can see why large data transfers with SMB are more sensitive to network latency than are HTTP transfers. (The astute among you also see why I NEVER recommend the use of SMB shares for frequently accessed data, such as personal Notes mailfiles...)

Turning to Notes NRPC (aka "Lotus Notes"), we find ourselves somewhere between these two extremes.  Behind the scenes, Lotus Notes/Domino is a transactional database system; even your "mailfile" is a database, and what you see as "an email message" is actually dozens of entries in that database.  It's all fields and attributes, which are handled individuallly.  They're all individual transactions, which means that--while individual transactions may involve large volumes of data--there's a constant back-and-forth between client and server.  Even opening (or replicating) a single email message triggers "Give me this part"..."OK, now this part"..."I'm ready for this part"...and, while not subjected to any particular metering or "chunking" (as is SMB), each of those transactions still requires an extra round-trip between server and client - which is where network latency can hit and hit hard - just as it does with SMB.

Unfortunately, there are no easy solutions for such environments.  You can adjust TCP windows, and (in the case of Lotus Notes), increasing the size of the TCP port buffers can provide some relief, but you'll eventually come up against the laws of physics - the electrons can only move so fast...and now you know how choice of protocols can make a BIG difference in performance when the network is slow...

Peeking Past the Proxy - Using Wireshark to Estimate "Second Hop" Latencies

Peeking Past the Proxy - Using Wireshark to Estimate "Second Hop" Latencies

When discussing network latency, most people only think about two adjacent endpoints; we aren't often called upon to evaluate latencies between intermediate devices along the network path.  Well, I was recently called upon to do just that, and--between documentation of the network path and knowledge of the protocols in use--I was able to take data from one endpoint and make reliable estimates of some intermediate latencies.  Consider the following packet capture, which illustrates the initiation of an SSL connection through an HTTP proxy:

Now, the first three packets--the TCP handshake--give us a straightforward indication of the network latency between the client and the HTTP proxy; in this example, it's roughly 12ms.  We then see our client issue an HTTP CONNECT method to establish a tunneled TLS connection to the true destination; here's where we put our higher-level protocol knowledge to good use.  We know that, according to the HTTP and TLS RFCs, the proxy device is not allowed to return a 2xx code to a CONNECT request unless/until its connection to the remote endpoint is complete.  So, then, the elapsed time between the proxy's ACK of our CONNECT request and its "200 Connection established" response is a reasonable measurement of the latency between the proxy and the device that is handling the "other end" of the TLS connection.  In this case, the latency we "see" is 132ms; however, we know that 12ms of that is the latency between the client and the HTTP proxy.  So, we can estimate the latency between the proxy and the "other end" of the TLS connection at 120ms.  Taking this a step further, the Client Hello/Server Hello exchange indicates a latency of 128ms (140ms raw - 12ms client-to-proxy-latency).

To be fair, these raw numbers include a certain amount of overhead, in that the proxy burns up a few milliseconds managing the transactions on both ends; still, taking this measurement over a collection of connections to the same destination can give us a reliable AND reasonable estimate of "effective latency" between not only points A (client) and B (HTTP proxy), but also between points B (proxy) and C (SSL termination at the destination).

You can't do this in every case of course, but the lesson is simple - the more you know and understand about the higher-level protocols (like HTTP and SSL/TLS), the more valuable your network analysis skills can be.  Go have fun with it!  If you don't have Wireshark, GO GET IT NOW...