I believe your "route" is actually: FPGA -> ipqueue ->FPAGcard->ether->PCcard->ipqueue->winpcapbuf->winpcapuserbuf On your sending device are you checking to ensure the bytes sent match what you think you are sending? Many people assume that just because they made the function call means it worked. Packet calls should always be checked to ensure the returned bytes match the sent bytes....otherwise you have to handle it properly. I suspect if anything is being dropped it's on the receiving end but you should double-check your sending anyways. Michael D. Black Senior Scientist Advanced Analytics Directorate Northrop Grumman Information Systems
________________________________
From: winpcap-users-boun...@winpcap.org on behalf of liu.yu...@zte.com.cn
Sent: Mon 9/27/2010 12:49 AM
To: winpcap-users@winpcap.org
Subject: EXTERNAL: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.vare...@cacetech.com>
???: winpcap-users-boun...@winpcap.org
2010-09-21 07:41
??? ?
winpcap-users@winpcap.org
???
<winpcap-users@winpcap.org>
??
??
Re: [Winpcap-users] About the packets loss , what is the bottleneck ?
From: yulou liu <mailto:lyu...@gmail.com>
Sent: Sunday, September 19, 2010 12:50 AM
To: winpcap-users@winpcap.org <mailto:winpcap-users@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@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.
<<winmail.dat>>
_______________________________________________ Winpcap-users mailing list Winpcap-users@winpcap.org https://www.winpcap.org/mailman/listinfo/winpcap-users
