What version of FBSD does Yahoo run?

Kris Kennaway kris at obsecurity.org
Thu Oct 7 15:32:10 PDT 2004


On Thu, Oct 07, 2004 at 05:35:18PM -0400, TM4525 at aol.com wrote:
> In a message dated 10/7/04 4:06:34 PM Eastern Daylight Time, drosih at rpi.edu 
> writes:
> Here's one benchmark, showing UDP packet/second generation
>      rate from userland on a dual xeon machine under various
>      target loads:
> 
>      Desired Optimal 5.x-UP  5.x-SMP 4.x-UP  4.x-SMP
>       50000   50000   50000   50000   50000   50000
>       75000   75000   75001   75001   75001   75001
>      100000  100000  100000  100000  100000  100000
>      125000  125000  125000  125000  125000  125000
>      150000  150000  150015  150014  150015  150015
>      175000  175000  175008  175008  175008  169097
>      200000  200000  200000  179621  181445  169451
>      225000  225000  225022  179729  181367  169831
>      250000  250000  242742  179979  181138  169212
>      275000  275000  242102  180171  181134  169283
>      300000  300000  242213  179157  181098  169355
> 
> That does show results for both single-processor (5.x-UP 4.x-UP)
> and multi- processor (5.x-SMP, 4.x-SMP) benchmarks.  It may be
> that he ignored the table as soon as he read "dual Xeon".
> --------------------------------------------
> I haven't seen this before.

Check your email..the above was copied from an email of mine in this
thread from earlier today.

> If I did, I would immediately ask:
> 
> - What is the control  here? What does your "benchmark" test?

UDP packet generation rate from userland.

> - Is this on a gigabit link? What are the packet sizes? Was network
> availability a factor in limiting the test results?

I didn't run that benchmark myself, so I'm not the best person to
answer all of your questions, and I've asked the person who did to
comment in more detail.

> - What does "target load" mean? Does it mean don't try to send
> more than that? If so, what does it show if you reach it? If you 
> don't measure the utilization that it takes to saturate your "target"
> I don't see the point of having it.
>
> - It seems that the only thing you could learn from this test would 
> be what is the maximum pps
> you could achieve unidirectionally out of a system. Why is that
> useful, since its hardly ever the requirement unless you're 
> building a traffic generator?

You can see from the data that 5.x systems are capable of pushing out
more packets from userland than 4.x systems are.  That's an aspect of
kernel performance, and it's one that's relevant for a number of
applications involving high data-rate transmission from userland.  If
that's not what you're interested in, then you can go and run your own
benchmarks and let us know what you find out.

> - a relatively slow machine (a 1.7Ghz celeron with a 32-bit/33mhz
> fxp NIC running 4.9) pushes over 250Kpps, so why is your machine, 
> with seemingly superior hardware, so slow?

Because traffic is being generated from userland, not from within the
kernel.

> Assuming that your benchmark does test something, Your "results"
> seem to show that a uniprocessor machine is substantially more
> efficient than an SMP box.

For this workload, yes.

> It also seems that the gap has widened between UP and SMP
> performance in 5.x. Wasn't one of the goals of 5.x to substantially
> improve SMP performance?

Yes, and it's ongoing.  You don't see it on this workload, but there
are other benchmarks (e.g. mysql select testing) that I don't have to
hand at the moment, which show the smp benefits of 5.3 more clearly.

> This seems to show the opposite.

No, it shows a small increase on SMP and a large increase on UP.
Anyway, weren't you demanding an email ago that I produce benchmarks
on UP systems, because no-one really uses SMP?

Kris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20041007/2272dfce/attachment.bin


More information about the freebsd-questions mailing list