Netra T1 105 (sparc64) optimization

[Miles Nordin]

>>>>> "av" == Alexandre Vieira <nullpt at 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. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20061130/26190a82/attachment.pgp