raman325 / ostinato

Automatically exported from code.google.com/p/ostinato
GNU General Public License v3.0
0 stars 0 forks source link

Time calculations in nSeconds instead of uSeconds #30

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I've been doing some work to integrate hardware support for Napatech adapters 
into ostinato.  

One limitation that I've discovered is that the micro-second ipg calculations 
that ostinato currently uses do not provide the granularity required for 
transmitting high-rate traffic on 10Gbps links.  As a result traffic does not 
transmit reliably at higher rates.  It would be better if you made these 
calculations using nano-seconds.  I realize that nano-second sleep is not 
available on all OS's.  However, it would be better to use this capability when 
possible.

Original issue reported on code.google.com by pjyoung...@gmail.com on 8 Dec 2010 at 9:39

GoogleCodeExporter commented 9 years ago
@pjyoung311 - I agree that this should be done. However, I'm unlikely to find 
the time to do this in the next couple of weeks. Meanwhile feel free to make 
the required changes and send me a patch (or merge request from a clone)

Original comment by pstav...@gmail.com on 9 Dec 2010 at 3:58

GoogleCodeExporter commented 9 years ago
I'll see what I can do.  I had implemented this previously for Linux.
However, we are bypassing libpcap in our implementation since, even with
this change, running at 10G is problematic for libpcap because the CPU
utilization is so high.  We are actually adding a separate Port object that
uses our API directly instead of going through libpcap.  For that I have to
change the time calculations in AbstractPort but don't deal with actually
implementing the Delay.  It's still important however, so I'll see what I
can do.

Ultimately, we would like to add our direct support to Ostinato, if
possible.

Phil

Original comment by pjyoung...@gmail.com on 22 Dec 2010 at 4:09

GoogleCodeExporter commented 9 years ago
This issue was closed by revision f5f6c330bda5.

Original comment by pstav...@gmail.com on 18 Jul 2011 at 2:00