netdev - Re: Network latency regressions from 2.6.22 to 2.6.29 (results with IRQ affinity)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.1.10.0904201410430.3361@qirst.com>
Date:	Mon, 20 Apr 2009 14:13:23 -0400 (EDT)
From:	Christoph Lameter <cl@...ux.com>
To:	Eric Dumazet <dada1@...mosbay.com>
cc:	David Miller <davem@...emloft.net>,
	Michael Chan <mchan@...adcom.com>,
	Ben Hutchings <bhutchings@...arflare.com>,
	netdev@...r.kernel.org
Subject: Re: Network latency regressions from 2.6.22 to 2.6.29 (results with
 IRQ affinity)

On Mon, 20 Apr 2009, Eric Dumazet wrote:

> > Sounds very good. If I just knew what you are measuring.
>
> Rephrasing my email, I was measuring latencies on the receiving machine,
> by using tcpdump and doing substraction of 'answer_time' and 'request_time'
> Thing is that timestamps dont care about hardware delays.
> (we note time when RX interrupt delivers the packet, and time right before giving frame to hardware)
>
>
> 21:04:23.780421 IP 192.168.20.112.9001 > 192.168.20.110.9000: UDP, length 300   (request)
> 21:04:23.780428 IP 192.168.20.110.9000 > 192.168.20.112.9001: UDP, length 300   (answer)
>
> Here, [21:04:23.780428 - 21:04:23.780421] = 7 us
>
> So my results are extensively published :)

But they are not comparable with my results. There could be other effects
in the system call API etc that have caused this regression. Plus tcpdump
causes additional copies of the packet to be delivered to user space.

> > CONFIG_HPET_TIMER=y
> > CONFIG_HPET_EMULATE_RTC=y
> > CONFIG_NR_CPUS=32
> > CONFIG_SCHED_SMT=y
>
> OK, I had "# CONFIG_SCHED_SMT is not set"
> I'll try with this option set

Should not be relevant since the processor has no hyperthreading.

> Are you running a 32 or 64 bits kernel ?

Test was done using a 64 bit kernel.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html