[Winpcap-users] About the packets loss , what is the bottleneck ?

Gianluca Varenni gianluca.varenni at cacetech.com
Fri Oct 1 15:13:28 PDT 2010 

1. If you really want, you can switch to RDTSC in this way by modifying/adding a registry key

       HKLM\System\CurrentControlSet\Services\NPF\TimestampMode
  Possible values are
   * 0 (default) -> Timestamps generated through KeQueryPerformanceCounter,
          less reliable on SMP/HyperThreading machines,
          precision = some microseconds
   * 2 -> Timestamps generated through KeQuerySystemTime,
   more reliable on SMP/HyperThreading machines,
          precision = scheduling quantum (10/15 ms)
   * 3 -> Timestamps generated through the i386 instruction RDTSC,
          less reliable on SMP/HyperThreading/SpeedStep machines,
          precision = some microseconds

My 6th sense tells me that you won't see any change in performance.

2. Usage of kernel buffer: at the moment is not available (it could be added by modifying the driver). However, if the problem is the kernel buffer, the dropped packet count would not be zero. And it's my understanding that this counter is always zero in your case, right?
    no of frames copied per DPC and served per interrupt. This information is simply not available because it's all managed by the NIC card driver. WinPcap sits on top of it and just receives the packets one by one.

3. Performance-wise at 1Gbps there is no difference. I definitely prefer pcap_next_ex because I find it easier to use.

GV





From: Helmut Vaupotitsch 
Sent: Tuesday, September 28, 2010 4:22 AM
To: winpcap-users at winpcap.org 
Subject: Re: [Winpcap-users] About the packets loss , what is the bottleneck ?


Hi Gianluca,

1) According to Section 5.3 and Figures 6,9 in http://www.winpcap.org/docs/WinPcap-SBAC03.pdf (small packets),
timestamp optimization is switched off in the standard distribution, which costs *a lot* of cpu processing.
Is it possible to turn on the "rdtsc" instruction on proper cpu´s? (or even turn off driver-timestamping for special purposes) 

2) To have a better understanding of the bound NIC and the driver in oder to tune the driver settings (e.g. reduce context switches),
it would be very nice to have some informations about:
# usage of kernel buffer (max, average or anything like that)
# no of frames copied to the kernel buffer during one DPC
# no of frames served by one interrupt

3) Regarding performance, what would you prefer,
pcap_next_ex() or pcap_loop()?


Best regards
Helmut


Gianluca Varenni schrieb: 
  The copies are the following ones:

  1. from the NIC driver buffers to the WinPcap kernel buffer (1st copy)
  2. from the kernel buffer to the user buffer (buffer allocated inside wpcap.dll) (2nd copy)

  If you copy the packets received from pcap_next_ex (or any other pcap receive function) to your own application buffer, that would be a 3rd copy.

  GV





  From: liu.yulou at zte.com.cn 
  Sent: Sunday, September 26, 2010 10:49 PM
  To: winpcap-users at winpcap.org 
  Subject: Re: [Winpcap-users] About the packets loss ,what is the bottleneck ?



  GV> Not at the moment with WinPcap. Having said that, I've used this double copy mechanism to bring several Gbps's to user mode without any packet loss (not with WinPcap, with custom hardware. However the buffering mechanism was the same). 

  YL> 'double copy mechanism'  ,  Data copy from the user buffer to application(user mode) is the third copy ?   





  GV>Are you dumping the packets to disk? If so, have you measured the dump-to-disk bandwidth? 

  YL> Yes,   Dumping packets to disk is my final goal.  But right now ,  To avoid the limitation of the disk write speed ,  I just count the packets number in the receive  thread.   But  on the  rate of 614 Mbps,   sometimes  there are still packets loss. 

  PS.     The route of packets transfer is :  FPGA BOARD sends data through ether net -->  PC'S  net card --> winpcap  kernel buffer --> winpcap user buffer  -->  receive thread count .   The FPGA's sending packets rate is about 614 Mbps ,   the size of  each packet is 1460 bytes,   every packet has a sequence number  ,   the sending process's  starting and stopping  can be controlled  .     

  The app that  I make only counts the packet's number when a packet comes without saving .   While  the  last packet comes ,  the app will compare the number (it counts by itself)  with the sequence number (of the last packet).  Then I will know if there is packets loss. 






        "Gianluca Varenni" <gianluca.varenni at cacetech.com> 
        发件人:  winpcap-users-bounces at winpcap.org 
        2010-09-21 07:41 请答复 给
              winpcap-users at winpcap.org 


       收件人 <winpcap-users at winpcap.org>  
              抄送 
             
              主题 Re: [Winpcap-users] About the packets loss ,        what is the bottleneck ? 


             
             

       



    

  From: yulou liu 
  Sent: Sunday, September 19, 2010 12:50 AM 
  To: winpcap-users at winpcap.org 
  Subject: [Winpcap-users] About the packets loss , what is the bottleneck ? 


  There is still the question about packets loss.
  Â Â 
  According to the essay  ' Profiling and Optimization of Software-Based Network-Analysis Applications' ,    every packet is copied twice in the main memory before reaching the user.  In order to reduce the cost of CPU and the bus occupying of the SDRAM of pc,   is it possible to copy data directly from the kernel buffer to the final buffer ,  which I want the date kept  in ?   
    
  GV> Not at the moment with WinPcap. Having said that, I've used this double copy mechanism to bring several Gbps's to user mode without any packet loss (not with WinPcap, with custom hardware. However the buffering mechanism was the same). 

  Â Â 
  Here is another idea ---  allocate several different user buffers , once a user buffer is fulled , then let the next user buffer to save the new datas from kernel buffer.  Meanwhile copy datas from the first user buffer to disk (assume that the hard disk write rate is fast enough).  Is this idea work with the winpcap ? 
    
  GV>Are you dumping the packets to disk? If so, have you measured the dump-to-disk bandwidth? 
    
  GV 
    
    
  _______________________________________________
  Winpcap-users mailing list
  Winpcap-users at winpcap.org
  https://www.winpcap.org/mailman/listinfo/winpcap-users



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
  

------------------------------------------------------------------------------
  _______________________________________________
  Winpcap-users mailing list
  Winpcap-users at winpcap.org
  https://www.winpcap.org/mailman/listinfo/winpcap-users

------------------------------------------------------------------------------
_______________________________________________
Winpcap-users mailing list
Winpcap-users at winpcap.org
https://www.winpcap.org/mailman/listinfo/winpcap-users

--------------------------------------------------------------------------------


_______________________________________________
Winpcap-users mailing list
Winpcap-users at winpcap.org
https://www.winpcap.org/mailman/listinfo/winpcap-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winpcap.org/pipermail/winpcap-users/attachments/20101001/a05b4957/attachment-0001.htm

More information about the Winpcap-users mailing list