You name it, we analyze it

463 views
329 views

Published on

With the ever increasing number of networking protocols, it can be difficult for vendors, integrators, and end-users to determine how well different products and systems perform in real-world networking situations. Each protocol has their own method of defining traffic streams and message structures. Packet analyzers, like Wireshark, have been developed to interpret individual network packets and can perform rudimentary analysis of traffic streams for well-known packet types. Analyzing industrial protocols usually requires much more massaging of the data and in many cases requires a user to do much of the work by hand. This session will present a method to break-down industrial traffic streams into the core components necessary to analyze their performance. By identifying a few key fields in each protocol, a user can define their own method to identify individual traffic streams and analyze their performance.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
463
On SlideShare
0
From Embeds
0
Number of Embeds
28
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

You name it, we analyze it

  1. 1. You Name It, We Analyze It! Jim Gilsinn Kenexis Consulting Corporation You Name It, We Analyze It! 1
  2. 2. Industrial Network Types & Metrics: Publish/Subscribe • Publish/subscribe or peer-to-peer communications • Main performance metric: Cyclic frequency variability/jitter • Real-time EtherNet/IP™ uses publish/subscribe • Requested/Accepted Packet Interval (RPI/API) • Measured Packet Interval (MPI) You Name It, We Analyze It! 2
  3. 3. Industrial Network Types & Metrics: Publish/Subscribe Subscriber TSub_Com_Init Publisher TPub_Com_Init TPub_1 TPub_2 TSub_M . . . • Difference between TPub_Com_Init & TSub_Com_Init is network roundtrip delay • TPub_Com_Init, TSub_Com_Init not important • Variability in TPub much more important • Theoretically, TPub doesn’t need to match Tsub TPub_N-1 TPub_N You Name It, We Analyze It! • In production systems, they are the same 3
  4. 4. Performance Testing Methodology: Performance Metrics • Command/response or master/slave communications • Main performance metric: Latency • Large numbers of protocols use this • Most (All?) PC-based server/client protocols – HTTP(S), (S)FTP, etc. • Most industrial protocols – Modbus/TCP, Profinet, Ethercat, etc. You Name It, We Analyze It! 4
  5. 5. Industrial Network Types & Metrics: Command/Response Commander TCom_Delay_1 Responder TRes_1 • Difference between TCom_Delay & TRes is network roundtrip delay • Latency in TCom & TRes important TCom_1 TCom_Delay_2 TRes_2 TCom_2 You Name It, We Analyze It! 5
  6. 6. Isolating Traffic Streams • Isolating traffic streams can be tricky • 10’s – 100’s of traffic streams in production environment • Your Wireshark Fu must be strong! • Usually requires additional post-processing • Multiple streams can exist between same devices You Name It, We Analyze It! 6
  7. 7. Isolating Traffic Streams • Traffic pairs • • • • Source IP/MAC address Destination IP/MAC address Source TCP/UDP port Destination TCP/UDP port • Publish/Subscribe • Communication stream ID • Sequence number (optional) • Command/Response • Command message/field • Response message/field • Message ID (optional) You Name It, We Analyze It! 7
  8. 8. Test Time vs. Packet Interval Measured Packet Interval (ms) ~62 sec test Mean MPI = 2ms Min ~ 1.2 Max ~ 2.9 Test Time (s) You Name It, We Analyze It! 8
  9. 9. Time Plot for Command/Response Regular Pattern to Delayed Packets Regular Pattern of Minimal Delayed Packets You Name It, We Analyze It! 9
  10. 10. Command/Response Timing Plots • Quick succession of command/response packets • Minimal delay in command/response sequence • Apparently large delay in a single packet • Example: Rockwell tag reads Delay Until Next Time Sequence Quick Succession Read Commands You Name It, We Analyze It! 10
  11. 11. Next Steps • Streamline traffic stream processing • Develop better command/response code • Build more mathematical statistical models • Add graphical modeling of time & frequency domain • Add more industrial protocols and obtain example files • • • • • Modbus Profinet DNP3 61850 And others… You Name It, We Analyze It! 11
  12. 12. Questions • Contact Me • • • • • • Jim Gilsinn 301-706-9985 or 614-323-2254 jim.gilsinn@kenexis.com Twitter – @JimGilsinn LinkedIn – http://www.linkedin.com/in/jimgilsinn/ SlideShare – http://www.slideshare.net/gilsinnj You Name It, We Analyze It! 12

×