Date: Thu, 30 Nov 2006 17:24:43 -0500 From: Miles Nordin <carton@Ivy.NET> To: freebsd-sparc64@freebsd.org Subject: Re: Netra T1 105 (sparc64) optimization Message-ID: <oqvekw609g.fsf@castrovalva.Ivy.NET> In-Reply-To: <755cb9fc0611301208w1ff93987m88885b3b59444373@mail.gmail.com> (Alexandre Vieira's message of "Thu, 30 Nov 2006 20:08:46 %2B0000") References: <755cb9fc0611290724q127f006va84f3457c48443b6@mail.gmail.com> <oq8xht7biy.fsf@castrovalva.Ivy.NET> <456E8D8B.8010102@orel.ru> <755cb9fc0611300454s4d28ad14rd402cba8388d49@mail.gmail.com> <14989d6e0611300700n3ac073bayc4584f2b1020ee61@mail.gmail.com> <755cb9fc0611300839y6deed1ceqf452018cc2f73737@mail.gmail.com> <oqzma869j9.fsf@castrovalva.Ivy.NET> <755cb9fc0611301208w1ff93987m88885b3b59444373@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--pgp-sign-Multipart_Thu_Nov_30_17:24:34_2006-1
Content-Type: text/plain; charset=US-ASCII
>>>>> "av" == Alexandre Vieira <nullpt@gmail.com> writes:
av> Without polling it transfers like 8MB/s, with polling it does
av> less than this and there is twice the latency.
that's not what i expected on both counts.
but the supposed benefit of polling is increase in pps capacity, not
reduced latency.
In theory, it is supposed to operate normally with interrupts enabled
for small-packets-per-second loads, giving the same latency as without
polling. For your ping test where the bridge is presumably idle
except for the ping, I'd expect that---interrupt mode, and the same
latency as without polling.
Somewhere around 1 - 10kpps it should switch to polling and collect
batches of 1ms of packets on each timer interrupt, giving you <= 1ms
additional latency (HZ=1000) compared to without polling. In exchange
for the added latency, the CPU load should be lower, and the max pps
it can handle before dropping packets should be greater. Again the
tradeoff should only happen under load, not just an idle line except
ping.
polling is mostly about high pps, so that would be either gigabit
without jumboframes, or 100Mbit/s with small packets (VoIP or DDoS).
so for 100Mbit/s and big packets like FTP I'm not surprised that you
see no benefit, but I would still have expected the transfer speed
with polling to be either unaffected or better.
...guess it's not what I expected. :)
--pgp-sign-Multipart_Thu_Nov_30_17:24:34_2006-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)
iQCVAwUARW9aK4nCBbTaW/4dAQInhwP8D8TiR31b8XdnVO6DHGJGDzoW7amjNquN
NvLPOS2tR8Bhp4fYjZXW8s6dFqenCs3wDKEM9/MjO10urmiMUhs26+XcC2qnNw/j
O6KFy+EtS5NMkIg6K5tDzbaYcuT2074kdqlyNbioU/lnjve5Vk/7PjW3XdMGYuRY
s/XxpyyNmMc=
=Y7dT
-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Thu_Nov_30_17:24:34_2006-1--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?oqvekw609g.fsf>