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

Gianluca Varenni gianluca.varenni at cacetech.com
Mon Sep 27 12:14:36 PDT 2010 

I'm not sure what you mean by "relying on interrupts". There is no concept 
of interrupts in the WinPcap library. Do you mean waitable handles?

GV

--------------------------------------------------
From: "Black, Michael (IS)" <Michael.Black2 at ngc.com>
Sent: Monday, September 27, 2010 8:22 AM
To: <winpcap-users at winpcap.org>
Subject: Re: [Winpcap-users] About the packets loss ,what is the bottleneck 
?

> A couple more ideas...
>
> #1 Have you tried just looping pcap_next instead of relying on interrupts?
> #2 Have you checked pcap_stats while running to see if receiver errors are 
> occurring?
>
> Can you show us your capture code?
>
> Michael D. Black
> Senior Scientist
> Advanced Analytics Directorate
> Northrop Grumman Information Systems
>
>
> ________________________________
>
> From: winpcap-users-bounces at winpcap.org on behalf of yulou liu
> Sent: Mon 9/27/2010 9:56 AM
> To: winpcap-users at winpcap.org
> Subject: Re: [Winpcap-users] EXTERNAL:Re: About the packets loss , what is 
> the bottleneck ?
>
>
>
> 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)" <Michael.Black2 at ngc.com> ??:
>
>> 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-bounces at winpcap.org on behalf of liu.yulou at zte.com.cn
>> Sent: Mon 9/27/2010 12:49 AM
>> To: winpcap-users at 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.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 <mailto:lyulou at gmail.com>
>> Sent: Sunday, September 19, 2010 12:50 AM
>> To: winpcap-users at winpcap.org <mailto: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.
>> <winmail.dat>
>> _______________________________________________
>> 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
>

More information about the Winpcap-users mailing list