[Winpcap-users] is winpcap appropriate for my gigabit ethernet device?

[max reason]

 Much thanks Zafer,

 Your answers and advice are very helpful - and exactly what I was
 hoping to hear!  Yes, in my situation it is perfectly acceptable
 to require a dual-core or quad-core CPU, and PCIe disk controllers.
 In fact, I bought intel PCIe cards with 2 gigabit ethernet interfaces
 thinking they might be better than the on-motherboard 1Ge controller,
 but I have performed that test yet.  My main point is: in my case,
 it is perfectly okay to say "you must have quad-core CPU, 4GB RAM,
 PCIe ethernet controllers, PCIe disk controllers", etc.  I came to
 the same conclusion you did - that a vanilla desktop/notebook PC
 would not work.  In fact, I am not sure any notebook PC will work,
 partly due to the slower disk drives, but also due to the slower
 *everything* in notebook computers.  Oh yes, it is also okay to
 require the computer have 2+ disk drives to save to, and it does
 appear to be very marginal to expect one SATAII drive to consume
 rougly 100+ MBps (800+ Mbps).

 I was planning to implement mine with multiple processes with
 shared memory - instead of multiple threads like you.  However,
 I do not yet understand the detailed, subtle behavior of the
 level 3 cache in Phenom CPUs.  I worry that CPU #0 will pull
 a large block of data into the level #1 cache owned by CPU #0,
 then CPU #1 (or the "save to disk" function) will try to save
 that large block of data to disk - and cause some sort of
 cache-thrashing.  Whereas, if an application could make sure
 these blocks of data never reached level #1 or level #2 caches,
 then no thrashing would occur.  I'm not sure whether the process
 or writing the data to the disk would be faster from main memory
 or from level #3 cache --- and frankly, I'll bet that depends
 upon the disk controller.

 I do hope I can execute my lossless data compression algorithm
 on the CPU.  If all I want to do is save to disk, then I can
 save the compressed data - no problem.  But when I want to
 write the image onto a texture (pixel-array) object in the GPU,
 the data needs to be decompressed.  The algorithm I developed
 does not compress very well, but it is incredibly SIMPLE - so
 simple I can execute it on the fly in the FPGA or [de]compress
 in the CPU with only 5~8 machine instructions per pixel!  :-)
 Now that I think about it, no need to decompress in the CPU!
 I wrote the 3D simulation/graphics/game engine myself, including
 the vertex and pixel shader programs.  So it will be simple AND
 faster to write a decompress shader that runs in the GPU.  Yes!

 BTW, what level did you program at to achieve your throughput?
 Did you program with winpcap functions, packet.dll functions,
 directly to the kernel-mode NPF driver (which I guess we can
 figure out how to do by looking at the packet.dll source-code)?

 Again, thanks for your very help answers.  PS:  I chose the
 cyclone3 FPGA because it is very cheap - only $15 for 1 unit.
 Of course, add another $9 for the marvell PHY, so the equivalent
 cost is about $25.  Still, all the FPGAs fast enough to support
 gigabit ethernet inside the FPGA were far outside my budget!
 Wish I could put the PHY inside the FPGA, but no such luck.

 Max


> -----Original Message-----
> From: winpcap-users-bounces at winpcap.org
> [mailto:winpcap-users-bounces at winpcap.org]On Behalf Of Zafer SAVAS
> Sent: 2008 September 04 : Thursday 11:06 am
> To: winpcap-users at winpcap.org; winpcap-users at winpcap.org
> Subject: RE: [Winpcap-users] is winpcap appropriate for my gigabit ethernet device?
>
> Hi Max,
>
> I have been working on a similar project like yours.  My aim was to
> transfer LARGE AMOUNT of data (like ~110MBytes/sec) from a FPGA based
> hardware to a standard PC.  My FPGA is a Virtex-5 xilinx FPGA and it
> has gigabit ethernet core in it.  To maximize the speed I am avoiding
> any header and sending raw ethernet frames (Layer-2) with format
> -6 bytes dest MAC
> -6 bytes source MAC
> -2 bytes type/length
> -x bytes data
> By the way there is a cross link with the PC and the FPGA and
> no hubs/routers etc...
>
> Here are my answers for your questions:
> 
> Q: So my first question is, "does winpcap do what I need?".
> A: Yes, it is DEFINITELY possible.  Thats something what winpcap is
>    capable of doing.  It can capture/send raw ethernet packets.
> 
> Q: I hope winpcap can simply "give my application the packet"
>    and do no [additional] processing whatsoever.
> A: Without any processing whole packet can be passed to user side.
>
> And here are some advices for your application:
>
> Winpcap can nearly capture gigabit ethernet packets at line speed
> (which is about 120MBytes/sec) but it is very dependent on your
> hardware and your software.  You can capture packets but if you
> process and try saving the packets to harddisk with a standard PC
> YOU WILL DEFINITELY LOSE PACKETS.
>
> To avoid these problems, here are some advices for you:
> - Use Multi-CPU PC
> - Allocate a large amount of kernel and user RAM in your applciation.
>   (For example RAM for 1G packets which requires a large amount of RAM)
> - Copy group of packets.
> - Do not process them after you capture
> - Use RAID disks to speed up your write to HD.
>
> As I said I achieved ~110MBytes/sec of data and in my application.
> There are two threads for achieving this:
> - 1 thread for capturing packets and writing them to user RAM 
> - and the other one for copying the packets to Hard-drive.
>
> God bless winpcap and its creators :)
>
> Good luck
> zafer.
>
> Zafer SAVAS
> Senior Expert Test Engineer
> Aselsan Inc.
> 
> 
> -----Original Message-----
> From: winpcap-users-bounces at winpcap.org on behalf of max reason
> Sent: Thu 04.09.2008 12:52
> To: winpcap-users at winpcap.org
> Subject: [Winpcap-users] is winpcap appropriate for my gigabit ethernetdevice?
>  
> 
>  This is my first post, since I just learned about winpcap.
>  I suspect my application for winpcap is unusual, so I'd like
>  to ask others with winpcap experience whether winpcap will
>  do what I need.  So, here goes.
> 
>  I designed an inexpensive but high-speed, high-resolution
>  digital video camera with 5 megapixel [and 8 megapixel] CCDs.
>  To keep the per-unit cost low, I had to find some way to get
>  151,165,440 bytes per second from camera to PC - which equals
>  roughly 1.2 gigabits per second.  My solution was to base the
>  camera circuit on a cyclone3 FPGA and gigabit ethernet PHY.
>  Plus I had to concoct a lossless compression system that is
>  both brain-dead simple, and simple and fast enough to compress
>  100 million 16-bit pixels per second enough to reduce the
>  bandwidth far enough below 1 gigabit per second to squeeze
>  the data through the PHY along with ethernet packet overhead.
> 
>  The bottom line is the following.  For this to work reliably,
>  the packets need to be captured, then stored and/or displayed
>  with as little overhead as possible.  Thet's probably obvious!
> 
>  To make this work, the ethernet cable from the camera must plug
>  directly into the RJ45 connector on the PC - no routers/hubs/etc.
>  The connection must be direct connect, or no way.
> 
>  My plan has been to send the data in a simple ethernet packet:
>    6-byte target-MAC-address
>    6-byte source-MAC-address
>    2-byte length-field
>    data (2592 pixels)
>    CRC32
> 
>  I didn't learn until recently that PC operating systems do not
>  typically receive or send such fundamental ethernet packets,
>  and support might be non-trivial.  I wrote some prototype code
>  on Linux with PF_PACKET that appears to provide me a way to
>  process these fundamental packets efficiently, and avoid ALL
>  subsequent [higher-level protocol] processing by the OS.
> 
>  But so far, I have not found a similar mechanism in win32.
>  However, if I understand the nature of winpcap correctly,
>  winpcap appears to provide similar capabilities.
> 
>  So my first question is, "does winpcap do what I need?".
> 
>  I think "what I need" is fairly obvious, but I'll rephrase
>  it this way.  On the "PC receives data" side, I need a way to
>  receive the packet - at least the data payload, but also the
>  header if feasible.  I prefer to receive the CRC32 at the end
>  of the packet (after the data), but can live without it.
> 
>  On the "PC sends data" side, I need to send short, simple
>  command packets fairly rarely - no more often than one per
>  image == 1944 ~ 2448 received packets.  And that packet
>  can and should be sent when no data is being received
>  (during a short pause between images).  These packets
>  should also be plain, ordinary ethernet packets with
>  the same fields shown above.
> 
>  I very much prefer to ***avoid*** IP, UDP, TCP/IP packets!
>  It is difficult enough to make the FPGA control and receive
>  data from four CCDs simultaneously (?did I mention that?),
>  plus perform realtime lossless data compression, plus send
>  the compressed data through the gigabit ethernet PHY also
>  in realtime (albeit one scanline later == pipelined).
> 
>  To waste space, bandwidth and complexity in the packet header
>  on totally useless NOTHINGNESS (to my application anyway),
>  is just stupid.  To create those larger packets just tempts
>  the OS to perform some packet processing, which just consumes
>  CPU bandwidth that my application need for other work (say,
>  saving the data to disk, or blasting it into a texture-map
>  in a GPU card, or etc).  It also throws a complexity-wrench
>  into my plans for computing the CRC32 in the FPGA.
> 
>  I hope winpcap can simply "give my application the packet"
>  and do no [additional] processing whatsoever.  It is also
>  very important that the OS not waste its time trying to
>  process the packet too.  I mean, what on earth for?
> 
>  And no, I can't just slow down the frame rate a little, to
>  whatever bandwidth is "feasible".  Some of the applications
>  of this device require "super-cinema HDTV" media output,
>  which is 2592 x 1080 x 24 FPS --- and the frame rate is
>  fixed by convention (and the equipment that processes it).
>  And that's not the only application that requires this
>  little device crank out data out at nearly 1 gigabit.
>  PS:  I suspect the actual data-payload rate can be in
>  the neighborhood of 900Mbps (maybe even 850Mbps), but
>  it must not "studder or skip" on frames that contain
>  "complexity" the lossless compression cannot compress
>  as much as "easy" frames.  That's an absolute no-can-do.
> 
>  I thank whoever decides to answer my question.  I am happy
>  to dig-in, read and learn how to hook winpcap into my code.
>  I just want to make sure I don't do all that work just to
>  discover winpcap can't do what I need.  Thanks, Max.
> 
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users
>