On Tue, Feb 01, 2011 at 05:46:29PM +0300, Slawa Olhovchenkov wrote:
> On Tue, Feb 01, 2011 at 04:15:01PM +0300, Slawa Olhovchenkov wrote:
>
> > On Tue, Feb 01, 2011 at 02:23:32PM +0200, Stefan Lambrev wrote:
> >
> > > >> Also in the past ENOBUF was not handled properly in linux.
> > > >>
> > >
On Wed, Feb 02, 2011 at 04:04:36AM +1100, Bruce Evans wrote:
> On Tue, 1 Feb 2011, Slawa Olhovchenkov wrote:
>
> > I do some more test and build kernel with KTR.
> > Now I don't think that inetrrupt overhead on FreeBSD weight: I try
> > polling and don't see any difference.
> >
> > I see many rep
On Tue, 1 Feb 2011, Slawa Olhovchenkov wrote:
I do some more test and build kernel with KTR.
Now I don't think that inetrrupt overhead on FreeBSD weight: I try
polling and don't see any difference.
I see many reported by netperf send errors. I found this
http://docs.freebsd.org/cgi/mid.cgi?E1Ai
On Tue, Feb 01, 2011 at 04:15:01PM +0300, Slawa Olhovchenkov wrote:
> On Tue, Feb 01, 2011 at 02:23:32PM +0200, Stefan Lambrev wrote:
>
> > >> Also in the past ENOBUF was not handled properly in linux.
> > >>
> > >> http://wiki.freebsd.org/AvoidingLinuxisms - Do not rely on
> > >> Linux-specifi
On Tue, Feb 01, 2011 at 02:23:32PM +0200, Stefan Lambrev wrote:
> >> Also in the past ENOBUF was not handled properly in linux.
> >>
> >> http://wiki.freebsd.org/AvoidingLinuxisms - Do not rely on Linux-specific
> >> socket behaviour. In particular, default socket buffer sizes are different
> >
On Feb 1, 2011, at 2:18 PM, Slawa Olhovchenkov wrote:
> On Tue, Feb 01, 2011 at 02:07:51PM +0200, Stefan Lambrev wrote:
>
>>> I do some more test and build kernel with KTR.
>>> Now I don't think that inetrrupt overhead on FreeBSD weight: I try
>>> polling and don't see any difference.
>>>
>>> I
On Tue, Feb 01, 2011 at 02:07:51PM +0200, Stefan Lambrev wrote:
> > I do some more test and build kernel with KTR.
> > Now I don't think that inetrrupt overhead on FreeBSD weight: I try
> > polling and don't see any difference.
> >
> > I see many reported by netperf send errors. I found this
> >
Hi,
On Feb 1, 2011, at 1:37 PM, Slawa Olhovchenkov wrote:
> On Sat, Jan 29, 2011 at 07:52:11AM +1100, Bruce Evans wrote:
>
there are profiling tools that you may decide to run.
>>>
>>> What tools I can use on amd64?
>>>
>>> I boot kernel configured with 'config -p'.
>>> Most time in spinl
On Sat, Jan 29, 2011 at 07:52:11AM +1100, Bruce Evans wrote:
> >> there are profiling tools that you may decide to run.
> >
> > What tools I can use on amd64?
> >
> > I boot kernel configured with 'config -p'.
> > Most time in spinlock_exit and acpi_cpu_c1.
>
> Normal profiling works poorly (I se
On Sat, Jan 29, 2011 at 11:54:11PM +1100, Bruce Evans wrote:
> > And I see drammaticaly less number of context switches in linux stats
> > (by dstat).
>
> FreeBSD uses ithreds for most interrupts, so of course it does many
> more context switches (at least 2 per interrupt). This doesn't make
> m
On Sat, Jan 29, 2011 at 09:55:06PM -0800, Robby Sun wrote:
> I'd like to suggest that you use the same bit-width for 'Dummy' as that for
> 'count', and initialize it to 0, so as to ensure that it won't overflow.
I don't use value of Dummy, overflow don't meaning.
> -Robby
>
> On Fri, Jan 28, 20
I'd like to suggest that you use the same bit-width for 'Dummy' as that for
'count', and initialize it to 0, so as to ensure that it won't overflow.
-Robby
On Fri, Jan 28, 2011 at 1:52 PM, Slawa Olhovchenkov wrote:
> On Sat, Jan 29, 2011 at 07:52:11AM +1100, Bruce Evans wrote:
>
> > >> there ar
On Sat, Jan 29, 2011 at 11:54:11PM +1100, Bruce Evans wrote:
> >> So FreeBSD has about 18% more network overhead (absolute: 65-47), or
> >> about 38% more network overhead (relative: (65-47)/47). Not too
> >> surprising -- the context switches alone might cost that.
> >
> > For only 14K vs 56K in
On Sat, 29 Jan 2011, Slawa Olhovchenkov wrote:
On Sat, Jan 29, 2011 at 02:43:07PM +1100, Bruce Evans wrote:
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
On Sat, Jan 29, 2011 at 02:43:07PM +1100, Bruce Evans wrote:
> 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 countin
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 (
29 matches
Mail list logo
