Contact Us online
Skip Navigation LinksHome :: About PacketIQ :: PacketIQ Clients
 

PacketIQ Clients





A sampling of the organizations our associates have served includes...

British Petroleum

IBM

McKesson

United HeathCare

American Express

NationsBank (Now BoA)

Matrix Rehabilitation of Dallas

North Shore Health System

Pyxis Corp.

Scott & White Memorial Hospital

DataMedic

MCI/WorldCom

Coors Brewery

Baptist/St. Vincent's Health System

BJC Health System

Haggar Clothing Co.

Iowa Health System

Lutheran Health Systems

Marian General Hospital

University of Chicago

IDX Systems Corp.

RTape Corp.


What our clients have said...

I have worked with Jim (President - PacketIQ - ed) now for almost three years on the global roll out of a strategic enterprise system for a large oil and gas client that will be deployed to over 15,000 users. During that time Jim has completed network impact assessments along with various application performance profiling initiatives to provide us with the information needed to make the right decisions on how we deliver our solutions to users in remote locations, whilst providing detailed analysis on what type of performance we can expect to achieve.

Some of the challenges we have been faced with is to provide answers to questions like:

  • How will this application perform at a location?
  • What is our impact on the network?
  • What is the impact of the network on our applications?
  • Where is the all the time being spent on a specific application function?
  • What does 'good' look like?
  • Show us where and why an application response time differs at different locations
  • Show us comparisons of application performance at different sites

Jim has been able to deliver a service that answers all of these questions (and more) whilst presenting them in a form that is both easy to understand and very detailed allowing us to understand an application’s network profile.

Many network engineers can pull bandwidth and latency reports to try and make assessments on application performance but the difference with the toolset Jim uses is the granular level of detail with which he is able to provide. Whether that be 'time of day' analysis on network links or the detailed breakdown of exactly where time is being spent in a transaction, the level of detail with which he is able to provide has been invaluable.

I would absolutely recommend Jim for any type of network analysis and network application performance profiling. Take a look for yourself at an example NIA (NIPA - ed) and see the level of detail he can provide. I don't believe there is another toolset out there that can deliver this type of analysis. I look forward to working with Jim in the future and hope to be able to ask questions that he cannot answer!

Sam Phillips
Maximo and SAP Performance Consultant
SSNE Ltd.

What was said by clients we provided NIPAs for...behind our back (they called them 'NIAs'):

NIPA Kudos


Jim provided excellent insight for two critical application deployments spanning 4 continents. His detailed performance analysis was an invaluable input to the final agreed designs. This was complemented by Jim's depth of experience and his remarkable ability to explain complex networks infra and terminology to the layman!

As a result, confidence in the end delivery was assured. Happy to report that we have had zero related issues a number of years on. A real pleasure to work with.

Gareth Jones, PMP
Project/Programme Mgr
Information Technology and Services Consultant


"I was really amazed at how accurate your projection of network loading and transfer completion time was for this disaster recovery transfer - especially for a transfer from Chicago to Singapore!"

Sr. Project Manager - R&M


"The depth and usefulness of the data you provided on this video (telepresence) impact analysis was heads and shoulders better than anything I've ever received from [leading healthcare solutions provider]!"

CIO - large healthcare group in Texas

See the PacketIQ Blog for more in-depth case studies and How-To articles.


Some of the unique problems we've solved for our clients...
Severe Medical Application Performance Issue

A medical application company commissioned a PacketIQ associate to perform an Application Performance Analysis on their application to assist in determining the source of very high end-user response times (>25 seconds) on behalf of their client who had a headquarters location and several nearby offices located in the Dallas, TX area. Response times at the headquarters location where the application server resided were well under 5 seconds.

Analysis data collected from a user location revealed that 92% of the remote user response time was attributable to network delay because a) the application utilized a lot of small packets for various functions, and incurred a lot of application turns, and b) the round-trip network path latency was an astounding 66 milliseconds, which is completely unexpected given that the distance between the user location and the application server was less than 5 miles. The combination of a lot of small packets and app-turns with the high path latency was responsible for nearly all of the high response time.

Conference calls with the frame relay service provider convinced them to perform their own latency tests, which uncovered the fact that the switching center for all of the Dallas locations was located in Tucson, AZ - thus the high path latency. The provider subsequently reconfigured their service and reduced this path latency substantially.

The high number of small packets was discussed with the application vendor, who announced that they were about to release an update that would address this problem. A follow-up analysis a short time after these changes were completed confirmed the application was utilizing fewer, larger packets, which along with a signficantly reduced network path latency resulted in a significant improvement in average response times.



Major SAP Deployments in Azerbaijan – North America – Alaska – Angola

I performed network impact & performance assessments to support a $500M deployment of SAP ERP & financials, Maximo materials management, Business Information (BI), and several equipment inventory/maintenance applications to over 15,000 users across multiple locations around the globe for a major oil company client.

Several of these assessments resulted in WAN link upgrade recommendations to accommodate what typically amounted to 6-10 Mbps of additional network traffic per region; the Alaska engagement also uncovered an errant WAN route to one site with insufficient capacity to support the imminent roll-out, and the fact that a certain WAN link failure scenario between Anchorage and the North Slope would swamp a 30 Mbps WAN link with ~40 Mbps of traffic, which was previously unconsidered and could have resulted in significant slow-downs and session timeouts for a very large number of mission-critical applications and users – the likelihood of this actually happening was significantly increased by the barren landscape in this region and the fact that winter storms can prevent problem resolution for days

After informing the client of this potential scenario, an upgrade of the fail-over link was ordered, and an alternate route with sufficient bandwidth was provisioned for the remote site.

All of the implementations were successful; most of the applications were network efficient given sufficient bandwidth, with the exception of a mobile device-based inventory application for which 50% of a very high response time (which also suffered from high server processing times) was going to be incurred due to a high app-turns count – this was identified by the NIPA modeling outputs and user expectations set accordingly – before the roll-outs - while the application is being reworked to perform better across the network.



Drilling Rig Operations Monitoring Software Deployments in Azerbaijan – Gulf of Mexico - North Sea – Brazil – Trinidad/Tobaggo

I performed multiple network impact & performance assessments to support the implementation of a suite of Kongsberg applications that monitor drilling rig operations, including Blow-Out Preventers on the ocean floor.

This is a near-real-time monitoring solution to allow teams on the rig and in monitoring centers around the globe to monitor and manage safe and efficient drilling operations on rigs that often have limited VSAT bandwidth allocations, which made the network impact planning process a critical part of the implementation.

Right-sized upgrade recommendations were made for several WAN links; all the deployments were successful.



High Tech Video Conferencing / Collaboration solution –w- Disaster Recovery Considerations

I performed a NIPA to determine if a limited bandwidth WAN link to a site in Libya would support a VC / collaboration solution that offered various resolutions / bandwidth demands, along with a request to consider if or how nightly data replication transfers could be accommodated.

The analysis findings were that the link at its current loading could only accommodate a lower-resolution session without jeopardizing existing applications performance, as well as the performance of the collaboration session, without an upgrade.

Link usage dropped off at night, leaving more bandwidth for DR transfers, but was it enough, and for long enough to complete most transfers?

The PacketIQ Bandwidth Statistical Analyzer with its Time of Day Analysis feature – a 24 hour view of usage levels statistically derived from 3 months of usage data - revealed a reliable opportunity window where usage on the link was consistently at 2 Mbps or below between 10:30 PM and 7:00 AM each business day night (and all through the weekend).

TCP rate modeling calculations for the given bandwidth and latency factors indicated that 90% of the typical transfer volumes could be accomplished within this window – with the caveat / strict warning that the DR transfers be halted by 7:30 each morning and any residual data transferred in the weekend ‘catch up’ period to avoid any performance issues / conflicts from the DR activity.

An optimized / right-size upgrade from 8 to 12 Mbps was recommended to support the preferred VC resolutions and allow 99% of the DR transfers to complete within the opportunity window.



ERP Application: No fix for this application – don’t waste any more time or money

A manufacturing company in New Jersey engaged PacketIQ to perform an Application Performance Analysis on their ERP system and associated reporting applications to isolate the source of generally poor performance at a couple of remote locations.

The applications performed acceptably in the home office, not quite so good from a relatively close remote office, and initial testing at another corporate office (a merger was taking place) in the mid-US revealed performance so poor for some transactions that a planned migration to the ERP system in NJ was put on hold until the problem could be resolved.

The Application Performance Analysis data revealed that this client’s ERP system was – by design – operating as a 2-tier solution: the client’s browser downloaded a set of JavaScript and other supporting files from the application server in NJ, but when sales order forms were being completed the client itself made numerous direct requests to the database server, which was also located back in the NJ office.

This resulted in a lot of request/response cycles over a network path with ~95 milliseconds of RTT delay, which when coupled with relatively inefficient SQL data delivery (related to an older server OS version) accounted for 64% of the overall response time.

Network bandwidth was adequate for a moderate number of users, and path latency was appropriate for the distance involved – there was nothing that could be done to the network to fix the problem; the performance issue was directly related to the application design.

I recommended upgrading the server OS to take advantage of improvements in Microsoft TCP stack efficiencies for SQL and file transfers, but unfortunately there was nothing else that could be practically done except to recommend a modern 3-tier or SaaS replacement for the current ERP system...

Not what the client wanted to hear, obviously, but information that hopefully saved them from wasting multiple thousands of dollars and a lot of time and frustration trying to further troubleshoot and fix a system that was never going to work well over the WAN.



SharePoint-based Work Management Application

An Application Performance Analysis conducted to support a NIPA for the planned roll-out of this SharePoint-based work management application revealed a solution that exhibited average Task-Level (mouse-click) network demands of ~1.3 Mbps server-to-client (per click!), which along with a moderate app-turns count was projected to result in 12-15 second response times and swamped WAN links to several remote user locations.

The network impact projections from the NIPA model and associated link upgrade calculations resulted in some astounding upgrade recommendations – 4 to 15 Mbps for one site, 10 to 20 for another, and a whopping 1.5 to 12 Mbps upgrade for yet another – all due to the fact that at least 10-12 Mbps of available bandwidth was needed in order to get response times down to reasonable (7-8 second) levels, which was still 2-3 seconds higher than the LAN-speed RT’s due to the network latencies involved to the target sites.

The client was recommended to investigate a Citrix solution (if practical for this application) or revisit the application design – and to NOT roll out the application in its current configuration.



Simultaneous Nationwide Server Crashes

A major bank was experiencing a vexing problem: several times a week, on a very intermittent basis, network servers hosting critical financial applications were going down - during the business day, all over the country, and all within 10 minutes of each other...

After several such crashes had occured and no one seemed to have an idea of the cause of this crisis, a PacketIQ associate was contacted to assist with troubleshooting the problem. Recognizing that this had to be a broadcast-based anomaly, he set up a continuous packet capture appliance that filtered out all but broadcast packets; this was allowed to run until another multi-crash event.

A detailed analysis of the resultant (very large) capture file uncovered a packet containing an illegal protocol code, which was eventually traced to a user several states away. A discussion with this user revealed that he was intermittently and quite innocently utilizing a printer configuration management application that was broadcasting the illegal code during it's printer search routine.

Needless to say, the user was strongly urged not to utilize the printer application until a non-offending upgrade was available from the vendor.