The Mystery 17% Cost Increase:
Last night I ran a test polling ten words once a minute from an Allen-Bradley SLC5/05C's N7 file over GSM. This is nothing exotic - I ran similar tests a few months ago and had preconceived ideas of what to expect ... beep ... wrong! In between Then and Now, some unknown application changed my Windows XP system registry, enabling the "RFC 1323 Timestamp and Window Scale TCP options". The end result was an unexpected 16.51% increase in data byte traffic with no perceived value.
I have no clue which tool did this; and unfortunately Windows (at least 2K and XP) use a single global setting for the entire TCP stack. I could change it back ... but would that break this other mystery application? Will this other mystery application just change it back? Will I launch a mini cold-war race as this mystery application tries to keep RFC 1323 enabled and my test tools try to keep it disabled?
The Byte Counts with and without RFC1323:
Here is an exact accounting of the change in byte counts - remember, cellular is basically a mobile-IP tunnel which moves TCP/IP or UDP/IP as pure data payload. So you pay for both the IP and TCP headers, plus any data-less TCP Acknowledge or Keepalive packets.
I'll ignore the opening and closing of the socket, plus TCP Keepalive since I'm polling fairly steady-state once per minute. The PLC includes the TCP ACK in the response, so at least we avoid 1-of-2 data-less TCP Acknowledgments.
|no RFC1323||with RFC1323|
|Request: IP header||20||20|
|Request: TCP header||20||32|
|Request: CSPv4 Packet||42||42|
|Response: IP header||20||20|
|Response: TCP header||20||32|
|Response: CSPv4 Packet||56||56|
|Client ACK: IP header||20||20|
|Client ACK: TCP header||20||32|
|Client ACK: (no data)||0||0|
|no RFC1323||with RFC1323|
|Total Bytes per Poll||218||254|
|Total Bytes per Hour||13,080||15,240|
|Total Bytes per Day||313,920||365,760|
|Total Bytes per Month||9,417,600||10,972,800|
So this means a user doing 1 read of 10 words per minute would magically see a 16.51 % increase in data traffic ... just because they (or the IT department or even Microsoft Windows Update) changes a hidden registry setting. This is yet another example of both how hard it is to keep tight control on your cellular data costs; plus adds to my belief that using off-the-shelf host applications over cost sensitive IP networks is a losing battle. At some point you'll need a tool or device which is 100% "under-control" when it come to packet creation.
Windows Registry Details:
Value Type: REG_DWORD—number (flags)
Valid Range: 0, 1, 2, 3
- 0 (disable RFC 1323 options)
- 1 (window scaling enabled only)
- 2 (timestamps enabled only)
- 3 (both options enabled)
Description: This parameter controls the use of RFC 1323 Timestamp and Window Scale TCP options. Explicit settings for timestamps and window scaling are manipulated with flag bits. Bit 0 controls window scaling, and bit 1 controls timestamps.
Post a Comment