Hello, > > When using 32768 bytes MTU I can get around 190 Mbps out from a PIII 450. > > (and only 190 Mbps because the two frontends have fast ethernet cards) > > So why this is so bad? If the other end can keep up, it will increase > > throughput. > And you could get even better by getting rid of the request/response > turnaround stall by using TCP instead of UDP. Forgot to tell that these results are with TCP, not UDP! But as far as I can remember the original problem is still that with the gx driver I was unable to use a "standard" UDP NFS mount, because of the fragments (it worked with the em driver) and if I remember correctly it had problems with TCP too. My letter was about this: a warning that if people notice problems with the gx driver, they should try the em. It is often hard to find a driver which is not even in LINT...
> Then don't add the fragment reassmbly code to the code path for packets > you send to the server. That way you'll have less overhead. I am not a big expert on this area, but if I get 200 Mbps instead of 15, I think increasing the packet size is good for me :) And going over the MTU with UDP also gives similar results. (the above is for TCP) > I run all my NFS over TCP. If I avoid intentionally triggering > fragmentation, it works out to a little over 100 machine instructions in > the fast path. Done any cycle counting on your use of UDP yet? I use TCP. I just noted that I *could* not use UDP mounts, with packet size bigger than the MTU with the gx driver. Which works with the em one, so either me, or the driver is buggy :) --------[ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]------- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU) phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
