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

[liu.yulou at zte.com.cn]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winpcap.org/pipermail/winpcap-users/attachments/20100927/314384b4/attachment.htm