ndt-users list created

[Peter Van Epp <>]

        Interrupt moderation is reasonably likely, since its an Intel chip 
set and it should support it, and a linux 2.6 kernel. The fibre card that 
works is an older SysKonnect that interrupts for every packet (or at least the
kernel said it was disabled and I assumed because the card can't do it). 
Since 
we won't be chasing something already solved, we can poke at it and see if we 
can figure out why its doing it and if there is some may to flag that its 
happening. Lixin just told me when he started tcpdump on the same interface
at the same time as an ndt run that it decided this really is a gig link, so
timing looks like a good bet (and/or promiscuous mode on the interface doing
something).

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada

On Tue, Jul 26, 2005 at 04:27:22PM -0400, Richard Carlson wrote:
> Hi Peter;
> 
> Thanks for the feedback.  I've used copper GigE cards before and never saw 
> this error, but that doesn't really tell you anything.  My guess is the NIC 
> is doing some pacing or packet bunching (maybe interrupt moderation).
> 
> The NDT server uses the libpcap utility to timestamp packets as they arrive 
 iat the interface.  These timestamps are put on in the kernel, so it's not 
> the arrival time at the interface, but the arrival time at the kernel.  If 
> the packets are getting bunched up then it could skew the timestamps enough 
> to make the report come out as you see.
> 
> So, I'd suggest the following:
> 
> 1) What OS/hardware is having the problem?
>         a) what driver got started?
>         b) what specific NIC is having problems?
> 2) Start looking at the NIC documents to see how it handles interrupt 
> processing
>         a) what are the current settings?
>         b) what can be changed?
> 3) Look at the NDT server settings.
>         a) look in the Documents/networking directory for .txt files
>         b) try running the /sbin/ethtool utility to see what is currently 
>         set.
> 
> Send us some details and I'll see what other helpful comments I can make .-)
> 
> Rich
> 
> At 03:39 PM 7/26/2005, Peter Van Epp wrote:
> >        Is there a known problem with copper GigE cards (note the one we 
> >        are
> >using is also exhibiting odd UDP rate limiting on jumbo frames with an
> >Apparant Networks sequencer)? I didn't see anything likely in the list 
> >archive.
> >
> >On Tue, Jul 26, 2005 at 11:36:19AM -0700, Lixin Liu wrote:
> >> Just tried fibre to fibre (from .2 to .6) and it correctly reports the
> >> connection is GigE, not 10GigE:
> >>
> >> TCP/Web100 Network Diagnostic Tool v5.3.3e
> >> click START to begin
> >> Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done
> >> running 10s outbound test (client to server) . . . . . 990.11Mb/s
> >> running 10s inbound test (server to client) . . . . . . 989.22Mb/s
> >> The slowest link in the end-to-end path is a 1.0 Gbps Gigabit Ethernet 
> >subnet
> >>
> >> When using copper interface on blowfish (.6), we get
> >>
> >> TCP/Web100 Network Diagnostic Tool v5.3.3e
> >> click START to begin
> >> Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done
> >> running 10s outbound test (client to server) . . . . . 989.60Mb/s
> >> running 10s inbound test (server to client) . . . . . . 989.50Mb/s
> >> The slowest link in the end-to-end path is a 10 Gbps 10 Gigabit 
> >Ethernet/OC-192 subnet
> >> Information: The receive buffer should be 60595.70 Kbytes to maximize 
> >throughput
> >>
> >>
> >> Lixin.
> >>
> >
> >Peter Van Epp / Operations and Technical Support
> >Simon Fraser University, Burnaby, B.C. Canada