2009/10/20 István :
> therefore i like netpipe runs you can see the performance and the latency as
> well using the packet size as your "x" axis, i think it makes more sense
> then just 1 number
My point was to demonstrate that saturating gigabit ethernet is very
doable with FreeBSD, and his lim
On Mon, Oct 19, 2009 at 2:36 AM, Adrian Chadd wrote:
> uhm:
>
> kristy# netperf -H 192.168.10.2 -p 22113 -l 10
> TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.10.2
> (192.168.10.2) port 0 AF_INET
> Recv SendSend
> Socket Socket Message Elapsed
> Size SizeSize
Its max not default, so relies on your configuring each app you want to have
high performance to take advantage of it. In our case that means our
large transfers easily saturate Gig.
Regards
Steve
- Original Message -
From: "Ivan Voras"
To:
Sent: Monday, October 19, 2009 12:44
Steven Hartland wrote:
Try with something like this, which is the standard set we use on our
file serving machines.
net.inet.tcp.inflight.enable=0
net.inet.tcp.sendspace=65536
kern.ipc.maxsockbuf=16777216
net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.recvbuf_max=16777216
16 MB network buffers
Chuck Swiger wrote:
Hi, Steve--
On Oct 17, 2009, at 8:14 AM, Steve Dong wrote:
If there's a better/lighter way to show these graphics, I'd like to know.
Sure-- put 'em on a webserver somewhere, and put links to them in your
email to this mailing list.
If you wanted to do even better than t
Steve Dong wrote:
It looks the jpeg attachments were somehow dropped. Trying again with pdf
attachment. Hopefully it works this time.
Hi,
I haven't tried comparing this sort of performance with Linux so your
conclusion still might be right, but the fact that you couldn't saturate
1 Gbps on
Try with something like this, which is the standard set we use on our
file serving machines.
net.inet.tcp.inflight.enable=0
net.inet.tcp.sendspace=65536
kern.ipc.maxsockbuf=16777216
net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.recvbuf_max=16777216
Regards
Steve
- Original Message ---
