Wireshark-users: [Wireshark-users] CACE TurboCap / dropping frames / really?
From: Stuart Kendrick <skendric@xxxxxxxxx>
Date: Wed, 02 Sep 2009 15:47:21 -0700
Hi folks,

I spent the morning with my network analysis buds Mike Pennacchi and Chris Greer from Network Protocol Specialists. We're pushing our analyzers -- trying to identify where they drop frames (at what rates do they start dropping frames, whether slicing or increasing memory buffers help, and so forth). We've run across behavior which we find puzzling.
We tapped a link between a laptop and a switch and used a TurboCap card to 
capture.  Then, we used a Fluke OptiView (hardware analyzer) to pound the laptop 
with maximum sized frames (raw IP traffic) -- full GigE.  We sent 10,000 frames 
at a time; the TurboCap card captured 10,000 frames.  We configured the OptiView 
to emit pings and blew 10,000 maximum-sized pings at the laptop at full GigE -- 
the TurboCap card captured ~20,000 frames (slightly less ... it is possible that 
the TurboCap card dropped a few. However, we suspect that the TurboCap card 
captured everything, and that the laptop OS dropped a few of the replies).  So 
far, so good:  we would expect the TurboCap card to be able to capture at 
full-line rate.
But when we use another station to send iPerf traffic (TCP) to the laptop, the 
TurboCap card drops frames regularly -- streaks of ~20K (~15 frames at a time), 
according to our brief analysis. 
https://vishnu.fhcrc.org/stress-analyzers/dropped-frames-at-8775.pdf
'TCP Out-Of-Order segment' is the expert diagnosis -- iPerf reports throughput 
in the ~200Mb/s range.  Ditto when we use the TurboCap card to capture a file 
copy over CIFS (~30Mb/s) -- streaks of lost frames.  [Interestingly enough, 
dumpcap reports 'Packets dropped: 0' when we break the capture.]
I don't have a model to explain this behavior.  Ethernet frames are Ethernet 
frames -- I wouldn't expect TurboCap to discriminate based on payload.
Was there something hallucinogenic in the cookies we were eating?  The cookies 
had an odd, bitter flavor to them ... but no, Chris didn't have any of the 
cookies, and he saw this behavior, too.
Anyone have insights into what we are seeing?

--sk

Stuart Kendrick
Fred Hutchinson Cancer Research Center
Seattle, WA USA


Test Bed

                           Optiview Network Analyzer
                                      |
                                      |
                                      |
LaptopA ------ In-Line Tap ------ Gig Switch ------- LaptopB
                 |  |
                 |  |
                 |  |
             TurboCap Card
                inside
              Shuttle XPC
                running
           Windows Server 2003
           and WireShark 1.2.1
             w/WinPcap 4.1beta5
             + TurboCap v1.2

Capture statement:
C:\Temp> dumpcap -i 6 test.pcap

Interfaces:
C:\Temp>dumpcap -D
1. \Device\NPF_GenericDialupAdapter (Adapter for generic dialup and VPN capture)

2. \Device\NPF_{FF47BC98-C742-4A0F-92E0-689F0D8ED02E} (Marvell Yukon Ethernet Co
ntroller.)
3. \Device\NPF_{468CC35E-4855-48ED-BA98-C8234AFDD64B} (Marvell Yukon Ethernet Co
ntroller.)
4. \\?\pci#ven_cace&dev_0001&subsys_115e8086&rev_06#4&37a76f2b&0&0030#{ccc1ec52-
8c28-41f5-9748-5695dcbda22a} (TurboCap Gigabit Ethernet Board - Port A)
5. \\?\pci#ven_cace&dev_0002&subsys_115e8086&rev_06#4&37a76f2b&0&0130#{ccc1ec52-
8c28-41f5-9748-5695dcbda22a} (TurboCap Gigabit Ethernet Board - Port B)
6. \\?\TC_bap_001517714382 (TurboCap Board Aggregating Port)

C:\Temp>