Stefan Lambrev wrote:
FreeBSD - ACPI
em1 in 13.157 MB/s 13.162 MB/s 23.697 GB
out13.150 MB/s 13.153 MB/s 17.976 GB
FreeBSD - TSC
em1 in 18.624 MB/s 18.832 MB/s 25.507 GB
o
On 04/02/2008, Alexander Leidinger <[EMAIL PROTECTED]> wrote:
> Ivan just change the page today. Feel free to suggest more specific things.
Yes, I've added notes on syscall caching on Linux and socket buffer
semantics. I've also linked to the page from Wikipedia article on
FreeBSD - maybe it will
Greetings,
Stefan Lambrev wrote:
Greetings,
Kris Kennaway wrote:
Kris Kennaway wrote:
Fixing all of the above I can send at about 13MB/sec (timecounter
is not relevant any more). The CPU is spending about 75% of the
time in the kernel, so
that is the next place to look. [hit
Greetings,
Ivan Voras wrote:
On 04/02/2008, Stefan Lambrev <[EMAIL PROTECTED]> wrote:
Kris if you do not mind I'll write to hping developers to adopt this
patch, and if no response from them I can try to reach the port
maintainer, so we have this patched in ports?
As we're in a "the
On 04/02/2008, Stefan Lambrev <[EMAIL PROTECTED]> wrote:
> Kris if you do not mind I'll write to hping developers to adopt this
> patch, and if no response from them I can try to reach the port
> maintainer, so we have this patched in ports?
As we're in a "the whole world is a Linux" situation,
Stefan Lambrev wrote:
Greetings,
Kris Kennaway wrote:
Kris Kennaway wrote:
Fixing all of the above I can send at about 13MB/sec (timecounter is
not relevant any more). The CPU is spending about 75% of the time
in the kernel, so
that is the next place to look. [hit send too soo
Greetings,
Kris Kennaway wrote:
Kris Kennaway wrote:
Fixing all of the above I can send at about 13MB/sec (timecounter is
not relevant any more). The CPU is spending about 75% of the time
in the kernel, so
that is the next place to look. [hit send too soon]
Actually 15MB/sec
Kris Kennaway wrote:
Stefan Lambrev wrote:
I run from host A : hping --flood -p 22 -S 10.3.3.2
and systat -ifstat on host B to see the traffic that is generated
(I do not want to run this monitoring on the flooder host as it will
effect his performance)
OK, I finally got time to look at this
Kris Kennaway wrote:
Fixing all of the above I can send at about 13MB/sec (timecounter is
not relevant any more). The CPU is spending about 75% of the time in
the kernel, so
that is the next place to look. [hit send too soon]
Actually 15MB/sec once I disable all kernel debuggin
Kris Kennaway wrote:
Stefan Lambrev wrote:
I run from host A : hping --flood -p 22 -S 10.3.3.2
and systat -ifstat on host B to see the traffic that is generated
(I do not want to run this monitoring on the flooder host as it will
effect his performance)
OK, I finally got time to look at this
Stefan Lambrev wrote:
I run from host A : hping --flood -p 22 -S 10.3.3.2
and systat -ifstat on host B to see the traffic that is generated
(I do not want to run this monitoring on the flooder host as it will
effect his performance)
OK, I finally got time to look at this. Firstly, this is qu
Greetings,
Stefan Lambrev wrote:
Greetings,
Kris Kennaway wrote:
Stefan Lambrev wrote:
It is the socket buffer that is filling up. Either the application
is not increasing it to large enough size or the default maximum is
too low (Linux may set a larger default). Try increasing
kern.ipc.
Greetings,
Kris Kennaway wrote:
Joseph Koshy wrote:
OK, this is the famous problem with modern CPUs that jkoshy has
declined
to work around :( There are patches for this in perforce, see
http://perforce.freebsd.org/changeView.cgi?CH=126189
"Famous problem" indeed :). I declined the pa
Joseph Koshy wrote:
OK, this is the famous problem with modern CPUs that jkoshy has declined
to work around :( There are patches for this in perforce, see
http://perforce.freebsd.org/changeView.cgi?CH=126189
"Famous problem" indeed :). I declined the patch because it
is incorrect and inc
> OK, this is the famous problem with modern CPUs that jkoshy has declined
> to work around :( There are patches for this in perforce, see
>
> http://perforce.freebsd.org/changeView.cgi?CH=126189
"Famous problem" indeed :). I declined the patch because it
is incorrect and incomplete.
First,
Greetings,
binto wrote:
Hi,
Sorry if a little bit insist & curious.
what is result from:
sysctl -a kern.ipc.maxsockbuf
sysctl -a net.inet.tcp.recvspace
net.inet.tcp.sendspace: 32768
net.inet.tcp.recvspace: 65536
kern.ipc.maxsockbuf: 262144
kern.ipc.nmbclusters: 262144
--
Best Wishes,
Ste
Hi,
Sorry if a little bit insist & curious.
what is result from:
sysctl -a kern.ipc.maxsockbuf
sysctl -a net.inet.tcp.recvspace
sysctl -a net.inet.tcp.sendspace
??
binto
> Greetings,
>
> Kris Kennaway wrote:
>> Stefan Lambrev wrote:
>>
It is the socket buffer that is filling up. Either t
Greetings,
Kris Kennaway wrote:
Stefan Lambrev wrote:
It is the socket buffer that is filling up. Either the application
is not increasing it to large enough size or the default maximum is
too low (Linux may set a larger default). Try increasing
kern.ipc.maxsockbuf and confirming with the
Stefan Lambrev wrote:
It is the socket buffer that is filling up. Either the application is
not increasing it to large enough size or the default maximum is too
low (Linux may set a larger default). Try increasing
kern.ipc.maxsockbuf and confirming with the source and/or ktrace that
it is d
Stefan Lambrev wrote:
You also need changes to the userland libpmc and pmcstat. They should
also be in that (or related) p4 changeset though.
Those are the files that I fetched from p4
/usr/src/lib/libpmc/libpmc.c - rev2
/usr/src/sys/amd64/include/pmc_mdep.h rev2
/usr/src/sys/dev/hwpmc/hwpmc_
Hi Kris,
Kris Kennaway wrote:
Stefan Lambrev wrote:
Hi Kris,
Kris Kennaway wrote:
Stefan Lambrev wrote:
Kris Kennaway wrote:
Stefan Lambrev wrote:
You should use hwpmc to verify where the application is really
spending time, since gettimeofday doesn't seem to account for it
all.
pmc: U
Greets,
Kris Kennaway wrote:
Ivan Voras wrote:
On 23/01/2008, Stefan Lambrev <[EMAIL PROTECTED]> wrote:
Greets,
Now I have final results with Linux and FreeBSD on the same hardware
CPU: Intel(R) Xeon(R) CPU 3070 @ 2.66GHz - dual core
Lan: [EMAIL PROTECTED]:3:0:0: class=0x02 card=0x10bc80
Greets,
binto wrote:
Greetings,
Steven Hartland wrote:
- Original Message - From: "Ivan Voras" <[EMAIL PROTECTED]>
The other thing that bothers me is, that under freebsd is quite easy
to get:
[send_ip] sendto: No buffer space available
It happens almost always on my laptop
> Greetings,
>
> Steven Hartland wrote:
>> - Original Message - From: "Ivan Voras" <[EMAIL PROTECTED]>
The other thing that bothers me is, that under freebsd is quite easy
to get:
[send_ip] sendto: No buffer space available
It happens almost always on my laptop just few
Ivan Voras wrote:
On 23/01/2008, Stefan Lambrev <[EMAIL PROTECTED]> wrote:
Greets,
Now I have final results with Linux and FreeBSD on the same hardware
CPU: Intel(R) Xeon(R) CPU 3070 @ 2.66GHz - dual core
Lan: [EMAIL PROTECTED]:3:0:0: class=0x02 card=0x10bc8086 chip=0x10bc8086
rev=0x06 hdr
Stefan Lambrev wrote:
Hi Kris,
Kris Kennaway wrote:
Stefan Lambrev wrote:
Kris Kennaway wrote:
Stefan Lambrev wrote:
You should use hwpmc to verify where the application is really
spending time, since gettimeofday doesn't seem to account for it all.
pmc: Unknown Intel CPU.
module_register
Greetings,
Steven Hartland wrote:
- Original Message - From: "Ivan Voras" <[EMAIL PROTECTED]>
The other thing that bothers me is, that under freebsd is quite easy
to get:
[send_ip] sendto: No buffer space available
It happens almost always on my laptop just few seconds after I start
hp
Hi,
Ivan Voras wrote:
On 23/01/2008, Stefan Lambrev <[EMAIL PROTECTED]> wrote:
Greets,
Now I have final results with Linux and FreeBSD on the same hardware
CPU: Intel(R) Xeon(R) CPU 3070 @ 2.66GHz - dual core
Lan: [EMAIL PROTECTED]:3:0:0: class=0x02 card=0x10bc8086 chip=0x10bc8086
rev=
- Original Message -
From: "Ivan Voras" <[EMAIL PROTECTED]>
The other thing that bothers me is, that under freebsd is quite easy to get:
[send_ip] sendto: No buffer space available
It happens almost always on my laptop just few seconds after I start
hping with timecounter=TSC
I'm not su
On 23/01/2008, Stefan Lambrev <[EMAIL PROTECTED]> wrote:
> Greets,
>
> Now I have final results with Linux and FreeBSD on the same hardware
> CPU: Intel(R) Xeon(R) CPU 3070 @ 2.66GHz - dual core
> Lan: [EMAIL PROTECTED]:3:0:0: class=0x02 card=0x10bc8086 chip=0x10bc8086
> rev=0x06 hdr=0x00
>
Greets,
Now I have final results with Linux and FreeBSD on the same hardware
CPU: Intel(R) Xeon(R) CPU 3070 @ 2.66GHz - dual core
Lan: [EMAIL PROTECTED]:3:0:0: class=0x02 card=0x10bc8086 chip=0x10bc8086
rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
device = '82571EB Gigabit
Stefan Lambrev wrote:
> Greetings,
>
> Kris Kennaway wrote:
>> Stefan Lambrev wrote:
>>
How much can Linux handle?
>>> Will install ubuntu on the same machine and let you know, but my
>>> experience shows that FreeBSD + TSC
>>> have the same performance as Linux
>>
>> With which timecounter?
Hi Kris,
Kris Kennaway wrote:
Stefan Lambrev wrote:
Kris Kennaway wrote:
Stefan Lambrev wrote:
You should use hwpmc to verify where the application is really
spending time, since gettimeofday doesn't seem to account for it all.
pmc: Unknown Intel CPU.
module_register_init: MOD_LOAD (hwpmc,
Greetings,
Kris Kennaway wrote:
Stefan Lambrev wrote:
How much can Linux handle?
Will install ubuntu on the same machine and let you know, but my
experience shows that FreeBSD + TSC
have the same performance as Linux
With which timecounter?
On my colleague laptop which is little slower com
Kris Kennaway wrote:
Stefan Lambrev wrote:
How much can Linux handle?
Will install ubuntu on the same machine and let you know, but my
experience shows that FreeBSD + TSC
have the same performance as Linux
With which timecounter?
I guess the default as it is not set anywhere (in linux it c
Stefan Lambrev wrote:
Kris Kennaway wrote:
Stefan Lambrev wrote:
You should use hwpmc to verify where the application is really
spending time, since gettimeofday doesn't seem to account for it all.
pmc: Unknown Intel CPU.
module_register_init: MOD_LOAD (hwpmc, 0x8029906d,
0x
Kris Kennaway wrote:
Stefan Lambrev wrote:
You should use hwpmc to verify where the application is really
spending time, since gettimeofday doesn't seem to account for it all.
pmc: Unknown Intel CPU.
module_register_init: MOD_LOAD (hwpmc, 0x8029906d,
0x8054c500) error 78
OK
Stefan Lambrev wrote:
How much can Linux handle?
Will install ubuntu on the same machine and let you know, but my
experience shows that FreeBSD + TSC
have the same performance as Linux
With which timecounter?
Here are the max speeds I can reach with different counters (on the test
server):
Hi,
Ivan Voras wrote:
Stefan Lambrev wrote:
I do not have HEPT on the servers that I test, but simple test on my
laptop shows
that hping can generate with ACPI-fast ~4MB/s traffic, 5MB/s with HPET
and 8MB/s with TSC.
How much can Linux handle?
Will install ubuntu on the same machine and le
Stefan Lambrev wrote:
You should use hwpmc to verify where the application is really
spending time, since gettimeofday doesn't seem to account for it all.
pmc: Unknown Intel CPU.
module_register_init: MOD_LOAD (hwpmc, 0x8029906d,
0x8054c500) error 78
OK, this is the famous pr
Greetings,
Kris Kennaway wrote:
Stefan Lambrev wrote:
Hi,
Dag-Erling Smørgrav wrote:
Stefan Lambrev <[EMAIL PROTECTED]> writes:
I tested all different combination. The performance change is almost
invisible (100-200KB/s), and can't be compared with the performance
boost that TSC gain over
Stefan Lambrev wrote:
I do not have HEPT on the servers that I test, but simple test on my
laptop shows
that hping can generate with ACPI-fast ~4MB/s traffic, 5MB/s with HPET
and 8MB/s with TSC.
How much can Linux handle?
>I didn't check dummy time counter.
If you do, it would give a nice
Stefan Lambrev wrote:
Hi,
Dag-Erling Smørgrav wrote:
Stefan Lambrev <[EMAIL PROTECTED]> writes:
I tested all different combination. The performance change is almost
invisible (100-200KB/s), and can't be compared with the performance
boost that TSC gain over ACPI-fast timecounter. Unfortunat
Hi,
Dag-Erling Smørgrav wrote:
Stefan Lambrev <[EMAIL PROTECTED]> writes:
I tested all different combination. The performance change is almost
invisible (100-200KB/s), and can't be compared with the performance
boost that TSC gain over ACPI-fast timecounter. Unfortunately TSC
doesn't play n
On Tue, Jan 22, 2008 at 03:34:55PM +0100, Dag-Erling Sm?rgrav wrote:
> More modern machines have an HPET timer which is supposedly faster than
> ACPI yet more reliable than TSC.
For NetBSD on AMD64 on a 1.2GHz Core2:
ACPI ~2400 cycles
HPET ~1500 cycles
TSC ~800 cycles
clockinterrupt ~600 cycles
T
Stefan Lambrev <[EMAIL PROTECTED]> writes:
> I tested all different combination. The performance change is almost
> invisible (100-200KB/s), and can't be compared with the performance
> boost that TSC gain over ACPI-fast timecounter. Unfortunately TSC
> doesn't play nice with power saving modes.
Daniel Eischen <[EMAIL PROTECTED]> writes:
> Not to discount any of your suggestions, but isn't the better
> performance of gettimeofday() (and perhaps clock_gettime() also)
> in Linux because they have access to the time in userland and
> can implement it without a system call? I seem to recall t
Greetings,
Dag-Erling Smørgrav wrote:
Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes:
Stefan Lambrev <[EMAIL PROTECTED]> writes:
I tried clock_gettime() (using CLOCK_REALTIME for clock_id), but this
yield worse performance.
Try CLOCK_MONOTONIC instead.
I forgot - there a
On Tue, 22 Jan 2008, Dag-Erling Smørgrav wrote:
Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes:
Stefan Lambrev <[EMAIL PROTECTED]> writes:
I tried clock_gettime() (using CLOCK_REALTIME for clock_id), but this
yield worse performance.
Try CLOCK_MONOTONIC instead.
I forgot - there are also th
Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes:
> Stefan Lambrev <[EMAIL PROTECTED]> writes:
> > I tried clock_gettime() (using CLOCK_REALTIME for clock_id), but this
> > yield worse performance.
> Try CLOCK_MONOTONIC instead.
I forgot - there are also the FreeBSD-specific CLOCK_REALTIME_FAST and
Stefan Lambrev <[EMAIL PROTECTED]> writes:
> I tried clock_gettime() (using CLOCK_REALTIME for clock_id), but this
> yield worse performance.
Try CLOCK_MONOTONIC instead.
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org ma
On 1/22/08, Stefan Lambrev <[EMAIL PROTECTED]> wrote:
> Greetings,
>
> I noticed that hping3 (from ports) is quite slower when running on
> FreeBSD compared to Linux.
> Simple ktrace shows lot of gettimeofday() calls, so I'm looking for
> replacement of this function.
> I tried clock_gettime() (usi
Greetings,
I noticed that hping3 (from ports) is quite slower when running on
FreeBSD compared to Linux.
Simple ktrace shows lot of gettimeofday() calls, so I'm looking for
replacement of this function.
I tried clock_gettime() (using CLOCK_REALTIME for clock_id), but this
yield worse performan
53 matches
Mail list logo
