Re: problems with PCIX-bus NICs

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 15 Jul 2009 14:26:37 +0200 (CEST)
    From:        6bone%6bone.informatik.uni-leipzig.de@localhost
    Message-ID:  
<Pine.NEB.4.64.0907151403150.20409%6bone.informatik.uni-leipzig.de@localhost>

  | Any Ideas what could be the problem?

If you haven't done it already, rre-run your test, and give ping6 the -n
flag - the interaction of ping's packet receivin/timing code and the
DNS resolver library routines generates a huge mess, and you can essentially
ignore the times whenever -n is not used (if you're lucky, and all the
nameservers are correctly configured, and ideally close, then you can
get reasonable results - but if there are misconfigured or non-responding
nameservers, it is all just a mess).

Ideally we'd have a way to have the kernel timestamp arriving packets, and
pass that info back to the application along with the rest of the control
info that's available, but either NetBSD has no way to do that, or
ping6 just doesn't use it, so the time it presents is the time from
when the packet was sent, until when the ping6 application got around to
processing the reply - if it gets itself stuck inside the resolver, the
returned packet can have sat in the kernel waiting to be fetched for a
long time.

I'd tend to suspect that the difference between the ping6 results you're
seeing on the two different interfaces is more a reflection of the
relevant .IP6.ARPA zone configurations for the different addresses
that anything else.

If you still see the same kind of results when you use -n, ask again...

kre