Re: Issues with a Large Fat pipe Network simulation

From: Pieter de Boer (pieter_at_thedarkside.nl)
Date: 06/20/05

  • Next message: Ari Suutari: "Policy routing idea (Was: ipfw: Would it be possible to continue processing rest of rules after match ?)" 
    Date: Mon, 20 Jun 2005 23:14:53 +0200
To: Luigi Rizzo <rizzo@icir.org>

    Luigi Rizzo wrote:

    >>When testing without any extra delay on 'network' and send/recvspaces of
    >>65535 bytes, we can sustain around 800mbit/s. The interrupts on
    >>'network' may be the limiting factor here. However, when we set the
    >>send/recv space to 65535*2, we can only sustain around 200-300mbit/s. It
    >
    >
    > have you checked that these two
    > kern.ipc.maxsockbuf: 262144
    > kern.ipc.sockbuf_waste_factor: 8
    >
    > aren't responsible for the trouble ?

    I've seen 200-300mbit when using a 1MB maxsockbuf. Raising it to 2, 4 or
    8MB doesn't seem to have much (if any) effect. Altering
    sockbuf_waste_factor doesn't seem to do anything, either.

    However.. when I deleted the pipe rules on 'network', the speed suddenly
    went up to around 800mbit/s too! I remade them, and voila, 200mbit/s.

    So apparantly it's an issue in the dummynet configuration I have. So, to
    reiterate:

    On 'network':
    pipe 1 from client to server via em0
    pipe 2 from server to client via em1
    allow ip from any to any

    Will give me 200MBit/s when using 128KB window sizes, but 800MBit/s when
    using 64KB window sizes.

    On 'network':
    allow ip from any to any

    Will give me 800Mbit/s when using 64KB or 128KB window sizes. I haven't
    configured the pipes in any way, though.

    So it appears it's due to the 'network' box afterall.. 

    -- 
Pieter
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
  • Next message: Ari Suutari: "Policy routing idea (Was: ipfw: Would it be possible to continue processing rest of rules after match ?)"

    Relevant Pages

    • Re: Why is my overlapped WriteFile getting blocked? (repost)
      ... The "server bug" was that it was never ... the client would connect to the named pipe ... and get blocked on the first WriteFile. ... I ran both the client and server on the same PC and opened the client pipe ...
      (microsoft.public.win32.programmer.networks)
    • Re: Named pipe problem
      ... When the client opens a pipe on the same machine as ... the server, I get 1 pipe connect request. ... When the same client program on a different computer opens the same pipe I ... I getting 2 connection requests over a network? ...
      (microsoft.public.win32.programmer.networks)
    • Re: Named pipe problem
      ... When the client opens a pipe on the same machine as ... the server, I get 1 pipe connect request. ... When the same client program on a different computer opens the same pipe I ... I getting 2 connection requests over a network? ...
      (microsoft.public.win32.programmer.networks)
    • Multithreaded pipe server, deadlock problem
      ... I'm working on a multithreaded pipe server. ... The primary thread create name pipes and if a client is connected, it then create a thread and let the thread procedure "InstanceThread" process the clients. ... // Marker 0 ...
      (microsoft.public.win32.programmer.kernel)
    • Re: A question about Named Pipe?
      ... I have a memory that it will come out of its ReadFile with (or for async, ... the session and it would make no sense to send additional information to the server via ... that pipe. ... >In block mode, once ConnectNamedPipereturns, it means the client called ...
      (microsoft.public.vc.mfc)