DragonFly users List (threaded) for 2005-02
In a message dated 2/10/2005 12:53:08 AM Eastern Standard Time, Matthew
Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> writes:
>:I may have spoken too soon. It appears that I may have been trashing my
>:(cheapo) switch, which caused an actual transmitter failure/device timeout.
>:The machine with dfly ran while I was at lunch without failing. In FreeBSD
>:it locks up the transmitter in a minute or 2. I'm going to run it
>:I do have a question about my top measurements. Running the same test on
>:the same MB, In Dragonfly, I see about 8% system and 12% interrupt, but
>:FreeBSD 4.11 only shows 12%-14% interrrupt and 0% for system. Is freeBSD
>:not including cycles that Dfly is? Is this going to be like measuring a
>:with a yardstick?
> That's like comparing apples with oranges. It sounds about right,
> I would expect FreeBSD to handle packet routing entirely within the
> interrupt. Right now I think Dragonfly is routing through the ethernet
> stack so it's getting messaged to a thread, and its going to stay that
> way for a while. I wouldn't expect a 14% vs 20% difference in load but
> your earlier saturation tests seem to validate those numbers.
> Optimizing network throughput is not a priority for us right now, I
> would be quite happy with a 14% vs 20% difference. We are more focused
> on getting the implementation correct first, and optimizing it later.
Ok, well I decided to do a little more testing before I dismantled my testbed.
What I found is that I get the following:
Network load = 15K pps: System 5% Interrupt 9-12%
Network load = 34Kpps: System 10% Interrupt 10-14%
(the interrupt number bounces around a bit)
Something doesn't seem right. Generally the load increases are linear for
this sort of test. The interrupt load seems about the same for what should
be twice the load. Even if no additional interrupts were generated I can't see
that the interrupt work could be that similar for double the load.