Skip to Content.
Sympa Menu

ndt-users - Re: Am I seeing the right results?

Subject: ndt-users list created

List archive

Re: Am I seeing the right results?


Chronological Thread 
  • From: Simon Leinen <>
  • To: Peter Van Epp <>
  • Cc:
  • Subject: Re: Am I seeing the right results?
  • Date: Sun, 30 Sep 2007 22:47:36 +0200

Peter Van Epp writes:
> On Sat, Sep 29, 2007 at 11:14:40AM +0200, Simon Leinen wrote:
>> Because interrupt coalescence is quickly becoming prevalent (even my
>> laptop has it), it would be useful to think about measurement methods
>> that are "robust" to it.
>>
>> In general, I would favour it if everybody used kernel timestamps
>> (e.g. SO_TIMESTAMP), and every adapter that performs interrupt
>> coalescence would decorate incoming frames with hardware
>> timestamps. That wouldn't require much (if any) new hardware on
>> the adapters, just a little more logic in the driver to convert
>> hardware timestamps into OS-level timestamps.

> It is more difficult than this. The Interrupt coalescence is
> built in to the ethernet chips which have internal buffers and no
> access to the kernel time.

Yes, I know. The adapter doesn't need to have access to "kernel
time", just a suitably fine-grained time source. The driver would
convert the adapter timestamps into kernel time.

> The answer is Endace DAG cards (www.endace.com) which keep an on
> board time source (syncable to GPS via ntp if desired) [...]

This is fine if you have enough money and all you want to is
measurement. But I'm more concerned about systems (especially
cost-effective systems) that want to do other networking things
efficiently, and that may still have a need for precision timestamps.

"Turn off Interrupt Coalescence" is of course a possibility, but
adapters with per-frame hardware timestamping support could be an
attractive alternative.

Or maybe with the move to multicore/manycore architectures, nobody
will care anymore about interrupt coalescence and all these other
niceties that contemporary adapters have (onboard checksumming, large
send offload etc).
--
Simon.



Archive powered by MHonArc 2.6.16.

Top of Page