[Winpcap-users] pcap_next_ex for real time application

[Loris Degioanni]

laurent.charreire at voila.fr wrote:

> Actually, I found the explanation of what is happening at low level (cf. http://www.winpcap.org/docs/docs31/html/group__NPF.html)
> [Extract]
> The size of the user buffer is very important because it determines the maximum amount of data that can be copied from kernel space to user space within a single system call. On the other hand, it can be noticed that also the minimum amount of data that can be copied in a single call is extremely important. In presence of a large value for this variable, the kernel waits for the arrival of several packets before copying the data to the user. This guarantees a low number of system calls, i.e. low processor usage, which is a good setting for applications like sniffers. On the other side, a small value means that the kernel will copy the packets as soon as the application is ready to receive them. This is excellent for real time applications (like, for example, ARP redirectors or bridges) that need the better responsiveness from the kernel. From this point of view, NPF has a configurable behavior, that allows users to choose between best efficiency or best responsiveness (or 
any intermediate situation). 
> 
> The wpcap library includes a couple of system calls that can be used both to set the timeout after which a read expires and the minimum amount of data that can be transferred to the application. By default, the read timeout is 1 second, and the minimum amount of data copied between the kernel and the application is 16K.
> [End of the extract]
> 
> So now, let's try to reduce user buffer's length and keep an eye on CPU behaviour in the meantime.

Don't play with the user buffer. Use pcap_setmintocopy() instead 
(http://www.winpcap.org/docs/docs31/html/group__wpcapfunc.html#ga49).

Loris

> Laurent Charreire
> 
> 
> 
>> Message du 30/08/06 à 12h35
>> De : "laurent.charreire at voila.fr" <laurent.charreire at voila.fr>
>> A : Tom at RedTile.Com, winpcap-users at winpcap.org
>> Copie à : 
>> Objet : Re: [Winpcap-users] pcap_next_ex for real time application
>>
>> My application uses only 5% to 35% CPU, depending on what threads are working : some are more cpu consumer...
>> You will find attached a copy of overall cpu used while my application is running.
>> Yes, I'm looping in order to handle every packet sniffed.
>> Here is a sample of my (overloaded) pcaploop method:
>> void OCA_ThdFiltrage::PcapLoop() {
>>     DWORD resultat = WaitForMultipleObjects(2, _tabEvt, FALSE, 0);
>>     [...]
>>     while (resultat != WAIT_OBJECT_0+1) {
>>          RetrievePacket(_qCapture);
>>     }
>> [...]
>>
>> where RetrievePacket calls pcap_next_ex as you can see in this sample:
>> void OCA_ThdFiltrage::RetrievePacket(pcap_t* pdev) {
>> 	struct pcap_pkthdr *pkt_header;
>> 	const u_char *pkt_data;
>> 	int res;
>>
>> 	while((res = pcap_next_ex( pdev, &pkt_header, &pkt_data)) >= 0){
>>              [...]
>>         }
>>
>> I pointed out that there is (fake) packets bursts, then my thread is waiting about 1 sec for new packets (~ 50 packets).
>> Hence, I suppose that some packets (I logged it : there are about 50 packets) are received and buffered (somewhere in kernel space I suppose). That would be why, on the one hand, my thread is handling so quickly packets and on the other hand, the same thread is waiting for new packets because of the kernel space buffer which may not be enough filled in.
>> Am I right?
>> If yes, what can I do to deal with that?
>>
>> Rgds,
>>
>> Laurent Charreire
>>
>>
>>> Message du 30/08/06 à 10h23
>>> De : "Thomas O'Hare" <Tom at RedTile.Com>
>>> A : laurent.charreire at voila.fr, winpcap-users at winpcap.org
>>> Copie �� : 
>>> Objet : Re: [Winpcap-users] pcap_next_ex for real time application
>>>
>>> We just has a question similar in nature.  May I ask what CPU load you
>>> are using?  IOW, are you looping or using another technique.  I guess %
>>> of CPU use would be a good indicator.
>>>
>>> Thanks,
>>> ~ Thomas O'Hare ~
>>> President, RedTile, Inc. - DBA: RedTile Software
>>> Web, Wireless, Network, Database & Systems Software
>>> +1.407.295.9148 ; +49.8651.717950 ; http://www.RedTile.Com/
>>> Operations Manager; Virtual FoxPro User Group
>>> Tom at VFUG.Org ; http://www.VFUG.Org/
>>>
>>>
>>> laurent.charreire at voila.fr wrote:
>>>> Hello,
>>>> I'm developping a real time application (multi-threading with MFC) which aims at decoding RTP packets to create audio file.
>>>> I make use of pcap_next_ex() in my filtering thread.
>>>> To test my program, I'm using a rtpdump file (G.711 PCMA) and rtpplay tool.
>>>> I don't understand why my filtering thread handles packets faster than 20 ms (length of my packet G.711 PCMA): it detects packets every 2 ms... :(
>>>> As a consequence, my decoding thread can not deal with so many bursts : buffer jitter is getting full and so on.
>>>> Thanks in advance for your support.
>>>> http://mail1.voila.fr/webmail/fr_FR/write.html#
>>>> Envoyer
>>>> Regards,
>>>>
>>>> Laurent Charreire
>>>>
>>>> _______________________________________________
>>>> Winpcap-users mailing list
>>>> Winpcap-users at winpcap.org
>>>> https://www.winpcap.org/mailman/listinfo/winpcap-users
>> [ cpuLoad.JPG (118.5 Ko) ]
> 
> 
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users
>