hum, do i get a speed ticket?
i did some tests before applying your patches:
lizard> ./tbench 1 dev
.1 clients started
..............+*
Throughput 6.10567 MB/sec (NB=7.63209 MB/sec 61.0567 MBit/sec)
lizard> ./tbench 2 dev
..2 clients started
........................+....+**
Throughput 7.71796 MB/sec (NB=9.64745 MB/sec 77.1796 MBit/sec)
lizard> ./tbench 3 dev
...3 clients started
.....................................+....+.+***
Throughput 9.17012 MB/sec (NB=11.4627 MB/sec 91.7012 MBit/sec)
lizard> ./tbench 4 dev
....4 clients started
........................................................++++****
Throughput 10.3365 MB/sec (NB=12.9207 MB/sec 103.365 MBit/sec)
lizard> ./tbench 5 dev
.....5 clients started
.............................................................+.......++.+.+****
*
Throughput 10.5219 MB/sec (NB=13.1523 MB/sec 105.219 MBit/sec)
> Richard (and others), please try this patch. With this patch I
> get the following between two machines connected via a 100BaseTX
> switch (full duplex):
>
> ----------------
>
> test1:/home/dillon/dbench> ./tbench 1 test2
> .1 clients started
> ..............+*
> Throughput 6.13925 MB/sec (NB=7.67406 MB/sec 61.3925 MBit/sec) 1 procs
> test1:/home/dillon/dbench> ./tbench 2 test2
> ..2 clients started
> ............................++**
> Throughput 8.37795 MB/sec (NB=10.4724 MB/sec 83.7795 MBit/sec) 2 procs
>
> ----------------
>
> On localhost I get:
>
> ----------------
>
> test1:/home/dillon/dbench> ./tbench 1 localhost
> .1 clients started
> ..............+*
> Throughput 25.7156 MB/sec (NB=32.1445 MB/sec 257.156 MBit/sec) 1 procs
> test1:/home/dillon/dbench> ./tbench 2 localhost
> ..2 clients started
> ............................++**
> Throughput 36.5428 MB/sec (NB=45.6785 MB/sec 365.428 MBit/sec) 2 procs
> test1:/home/dillon/dbench>
>
> ----------------
>
> This is WITHOUT changing the default send and receive tcp buffers..
> they're both 16384.
>
> The bug I found is that when recv() is used with MSG_WAITALL,
> which is what tbench does, soreceive() will block waiting for all
> available input WITHOUT ever calling pr->pr_usrreqs->pru_rcvd(),
> which means that if the sender filled up the receive buffer (16K default)
> the receiver will never ack the 0 window... that is until the idle code
> takes over after 5 seconds.
>
> -Matt
>
> Index: uipc_socket.c
> ===================================================================
> RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v
> retrieving revision 1.68.2.16
> diff -u -r1.68.2.16 uipc_socket.c
> --- uipc_socket.c 2001/06/14 20:46:06 1.68.2.16
> +++ uipc_socket.c 2001/12/01 21:09:13
> @@ -910,6 +910,14 @@
> !sosendallatonce(so) && !nextrecord) {
> if (so->so_error || so->so_state & SS_CANTRCVMORE)
> break;
> + /*
> + * The window might have closed to zero, make
> + * sure we send an ack now that we've drained
> + * the buffer or we might end up blocking until
> + * the idle takes over (5 seconds).
> + */
> + if (pr->pr_flags & PR_WANTRCVD && so->so_pcb)
> + (*pr->pr_usrreqs->pru_rcvd)(so, flags);
> error = sbwait(&so->so_rcv);
> if (error) {
> sbunlock(&so->so_rcv);
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
