On Sat, 29 Jan 2011, Slawa Olhovchenkov wrote:
On Sat, Jan 29, 2011 at 07:52:11AM +1100, Bruce Evans wrote:
To see how much CPU is actually available, run something else and see how
fast it runs. A simple counting loops works well on UP systems.
===
#include
#include
int Dummy;
int
main
On a Lanner 7535 atom d510 system DUT, using a single gig port, running
-CURRENT from Jan 6.
input(Total) output
packets errs idrops bytespackets errs bytes colls
410015 0 0 43461452204 0 15592 0
410341 0
On Fri, 28 Jan 2011, Slawa Olhovchenkov wrote:
On Fri, Jan 28, 2011 at 09:10:20AM -0800, Julian Elischer wrote:
On 1/28/11 8:15 AM, Stefan Lambrev wrote:
The overhead comes from badly written software.
This software is optimized for linux and you have to optimize it for freebsd,
then you wil
On Sat, Jan 29, 2011 at 07:52:11AM +1100, Bruce Evans wrote:
> >> there are of course several possible answers, including:
> >>
> >> 1/ Sometimes BSD and Linux report things differently. Linux may or may not
> >> account for the lowest level interrupt tie the same as BSD
> >
> > But I see only 20%
On Fri, Jan 28, 2011 at 06:03:15PM +0200, Stefan Lambrev wrote:
> Do the test with netblast ;)
> Most perf tools are written badly and for Linux.
> In our internal test netblast running on freebsd outperform everything else.
>
> P.S. - /usr/src/tools/tools/netrate/netblast - we have tested little
On Fri, Jan 28, 2011 at 07:44:57PM +0200, Stefan Lambrev wrote:
> >> there are profiling tools that you may decide to run.
> >
> > What tools I can use on amd64?
>
> Look at this document -
> http://software.intel.com/sites/oss/pdfs/profiling_debugging_freebsd_kernel_321772.pdf
> It contains br
Assuming your problems are related to the driver, maybe you could try the
driver from Realtek's website for FreeBSD. If there is a bug in the FreeBSD
driver and the Realtek driver works, that would narrow down things quite a bit.
http://www.realtek.com.tw/downloads/
___
Hi,
On Jan 28, 2011, at 7:25 PM, Slawa Olhovchenkov wrote:
> On Fri, Jan 28, 2011 at 09:10:20AM -0800, Julian Elischer wrote:
>
>> On 1/28/11 8:15 AM, Stefan Lambrev wrote:
>>> The overhead comes from badly written software.
>>> This software is optimized for linux and you have to optimize it fo
On 1/28/11 8:15 AM, Stefan Lambrev wrote:
The overhead comes from badly written software.
This software is optimized for linux and you have to optimize it for freebsd,
then you will have the same overhead.
All those *popular* benchmarks like hping, iperf, netperf have some strange
optimizations
On Fri, Jan 28, 2011 at 09:10:20AM -0800, Julian Elischer wrote:
> On 1/28/11 8:15 AM, Stefan Lambrev wrote:
> > The overhead comes from badly written software.
> > This software is optimized for linux and you have to optimize it for
> > freebsd, then you will have the same overhead.
> > All thos
The overhead comes from badly written software.
This software is optimized for linux and you have to optimize it for freebsd,
then you will have the same overhead.
All those *popular* benchmarks like hping, iperf, netperf have some strange
optimizations for linux - we call them linuxism.
Just sea
On Fri, Jan 28, 2011 at 06:03:15PM +0200, Stefan Lambrev wrote:
> Do the test with netblast ;)
> Most perf tools are written badly and for Linux.
> In our internal test netblast running on freebsd outperform everything else.
I don't speak about bad performance.
I speak about overhead.
Linux: ove
Hi,
Do the test with netblast ;)
Most perf tools are written badly and for Linux.
In our internal test netblast running on freebsd outperform everything else.
P.S. - /usr/src/tools/tools/netrate/netblast - we have tested little more
expensive card - em/igb and bce.
On Jan 28, 2011, at 4:33 PM,
I test network performance and found some strange result -- on the
same hardware Linux more then 10x used CPU resources for interrupt
processing.
FreeBSD system utilise 70% CPU (32% idle, 59% interrupt, 9% sys) and
network card generate 14K-18K interrupt per second.
Linux system utilise 20% CPU (
14 matches
Mail list logo
