Yes, I have checked the sending of fpga in this way: two fpga board , one for sending , another for receiving. And made such experiment for a great of times to ensure there is no problem on the fpga's side.
在 2010-9-27，20:31，"Black, Michael (IS)" <[email protected]> 写到： > 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: [email protected] on behalf of [email protected] > Sent: Mon 9/27/2010 12:49 AM > To: [email protected] > 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" <[email protected]> > ???: [email protected] > > 2010-09-21 07:41 > ??? ? > [email protected] > > > ??? > <[email protected]> > ?? > ?? > Re: [Winpcap-users] About the packets loss , what is the bottleneck ? > > > > > > > > > From: yulou liu <mailto:[email protected]> > Sent: Sunday, September 19, 2010 12:50 AM > To: [email protected] <mailto:[email protected]> > 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 > [email protected] > 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 > [email protected] > https://www.winpcap.org/mailman/listinfo/winpcap-users _______________________________________________ Winpcap-users mailing list [email protected] https://www.winpcap.org/mailman/listinfo/winpcap-users
