[Winpcap-users] TurboCap device

Fri Jul 11 06:05:51 GMT 2008

But the performance of disk I/O makes the process fills all buffers to start 
drops packets?? Or are you saying that packets are droped in high throughput 
even when you have space in buffers and the cpu is not overloaded??

I didn't understand the advantage of set processor affinities when you have 
more cpu than threads. I'm not using ring buffer (the kernel buffer already 
uses it) because the job of control the memory blocks leaves me in doubt 
about the performance against a individual heap space with low-fragmentation 
heap sorted by a std::list. I´m using LFH to main process heap and small 
block heap (threshold 128) too. But I never tested in a large throughput 
before like you and It's job is not save entire the data to disk...

Thanks...

Renato A. Ferreira

----- Original Message ----- 
From: "Zafer SAVAS" <zsavas at aselsan.com.tr>
To: <winpcap-users at winpcap.org>; <winpcap-users at winpcap.org>
Sent: Wednesday, July 09, 2008 12:54 PM
Subject: RE: [Winpcap-users] TurboCap device

> Hi all,
> I have been trying the performance of winpcap for a while.
> My aim was to record (save to disk) high throughput gigabit ethernet (like 
> 120MBytes/sec data flowing)
>
> My hardware configuration is :
> - onboard gigabit ethernet card with PCI-express (x1) bus
> - 4 Gigs of RAM
> - Quad Xeon CPUs
> - SAS (Serial Attached SCSI->375MBytes/sec) hard disk
>
> I was never able to achive to record without any packet loss. I can record 
> %95 of all packet which makes about 114MBytes/sec.
>
> According to my observations, to record without any packet loss;
> - You must allocate large amounts of user RAM for the stored packets 
> (1GByte)
> - You must allocate large amounts of kernel buffer for winpcap (100M)
> - You must use a Ring Buffer to store
> - you must implement to threads; first one for copying packets from driver 
> to ring buffer, second one for reading from ring buffer and save to 
> harddisk.
> - The threads must be assigned different cpu affinities i.e : thread#1 
> working on CPU-1/2 and thread#2 on CPU-3/4.
> - The threads must have TIME_CRITICAL priorities.
> Because without implementing these maximum I can achieve is %60 
> performace.
>
> Is there anybody else trying to achieve the performance of Turbocap with 
> winpcap or is it just a dream?
>
> Regards
>
> Zafer SAVAS
> Senior Expert Test Engineer
> Aselsan Inc.
>
>
> -----Original Message-----
> From: winpcap-users-bounces at winpcap.org on behalf of Renato Araújo 
> Ferreira
> Sent: Wed 09.07.2008 15:50
> To: winpcap-users at winpcap.org
> Subject: Re: [Winpcap-users] TurboCap device
>
> The main issue of packet based analisys is that the reliability of data
> decreases while the throughput increases. I think that, and I'm looking 
> for
> it, the main purpose of these capture devices is deliver a hardware and
> software solution that solves this question, like endace promises with 
> your
> DAG card. Turbocap device, and it's software driver/API working together
> provide a mechanism to avoid the packet losses and the CPU overload?? If
> yes, will a normal implementation of winpcac using pcap_findalldevs,
> pcap_setfilter, pcap_open_live, etc takes advantage of these
> characteristics??
>
> Thanks,
>
> Renato A. Ferreira
>
> ----- Original Message ----- 
> From: "Gianluca Varenni" <gianluca.varenni at cacetech.com>
> To: <winpcap-users at winpcap.org>
> Sent: Tuesday, July 08, 2008 1:05 PM
> Subject: Re: [Winpcap-users] TurboCap device
>
>
>>
>> ----- Original Message ----- 
>> From: "Renato Araújo Ferreira" <marina.peixe at terra.com.br>
>> To: <winpcap-users at winpcap.org>
>> Sent: Monday, July 07, 2008 3:40 PM
>> Subject: [Winpcap-users] TurboCap device
>>
>>
>>> Hello, all...
>>>
>>> I'd like to know how turbocap device works. If it's looks like as a very
>>> large OS level buffer to avoid the packets of being droped in high
>>> throughputs, and if I need to change one implementation that already 
>>> work
>>> with winpcap with common network devices.
>>
>> I'm not sure if I understood your questions completely. However, this is 
>> a
>> very brief explanation of how TurboCap works and how it differs from the
>> standard WinPcap driver.
>>
>> In the normal WinPcap case, the driver stack used to receive packets is
>> composed by
>> - a NIC miniport (written by the NIC manufactor) that deals with the
>> hardware and exports a standard windows interface to deliver packets to
>> the upper layers
>> - zero or more IM drivers (written by 3rd parties) that can
>> analyze/monitor/block packets. Personal firewalls and QoS packet 
>> scheduler
>> are IM drivers.
>> - the WinPcap protocol driver (npf.sys) which receives the packets from
>> the underlying layer(s) (i.e. NIC miniport or the IM drivers) and 
>> delivers
>> them to user level.
>>
>> This stack architecture uses a framework provided by MS called NDIS (it's
>> not 100% true as NDIS was designed in conjuction with other companies, if
>> i remember well before even Windows, there was some NDIS stuff for DOS or
>> similar). The NDIS framework was not designed with packet capture in 
>> mind,
>> although it definitely allows you to create network sniffers.
>>
>> TurboCap instead is a monolitic driver that talks directly with a 
>> specific
>> NIC card (based on an Intel chipset), buffers the packets in the driver
>> and delivers them to user mode applications.
>>
>> If you use a TurboCap board and have a WinPcap based application, the
>> TurboCap board is accessible directly through the WinPcap interface
>> (although some features might not be available) or rewrite the capture
>> part of your application using the TurboCap native API.
>>
>> Let me know if this answers your question.
>>
>> Have a nice day
>> GV
>>
>>>
>>> Thanks..
>>>
>>> Renato A. Ferreira
>>> _______________________________________________
>>> 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
>
>
> ######################################################################
> Dikkat:
>
> Bu elektronik posta mesaji kisisel ve ozeldir. Eger size
> gonderilmediyse lutfen gondericiyi bilgilendirip mesaji siliniz.
> Firmamiza gelen ve giden mesajlar virus taramasindan gecirilmekte,
> guvenlik nedeni ile kontrol edilerek saklanmaktadir. Mesajdaki
> gorusler ve bakis acisi gondericiye ait olup Aselsan A.S. resmi
> gorusu olmak zorunda degildir.
>
> ######################################################################
> Attention:
>
> This e-mail message is privileged and confidential. If you are
> not the intended recipient please delete the message and notify
> the sender. E-mails to and from the company are monitored for
> operational reasons and in accordance with lawful business practices.
> Any views or opinions presented are solely those of the author and
> do not necessarily represent the views of the company.
>
> ######################################################################
>
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users
> 