I got really poor performance when I try to upload files to the box (via pureFTP or Samba) when using jumbo frames somewhat above 2k. uname -a : FreeBSD carenath.tzim.net 7.0-STABLE FreeBSD 7.0-STABLE #4: Wed May 28 17:45:14 CEST 2008 tzim@carenath.tzim.net:/usr/obj/usr/src/sys/CARENATH amd64 It seems that TCP acks are delayed for about a second, so the upload rate nevers goes above 60kB/s. I can provide wireshark captures done on the box uploading the files if necessary. The client is a Windows XP64 box, but I do not recall having the same problem on 6.2. I did got about 100 MB/s for similar file transfers, but I had to disable jumbo frames when I upgraded to 7.0-Release because of some bug on txcsum/rxcsum on re(4) so I only noticed the issue recently. The txcsum bug doesn't seem to occur anymore, but now I have this strange rate issue, with or without checksum offloading disabled. I also tried with tso disabled. Same results. Is it related to the re(4) driver ? Or to the TCP stack ? Arnaud Houdelette
Does the trace show the window size being negotiated correctly? ----- Original Message ----- From: "Arnaud Houdelette" <arnaud.houdelette@tzim.net>>I got really poor performance when I try to upload files to the box (via > pureFTP or Samba) when using jumbo frames somewhat above 2k. > > uname -a : > FreeBSD carenath.tzim.net 7.0-STABLE FreeBSD 7.0-STABLE #4: Wed May 28 > 17:45:14 CEST 2008 > tzim@carenath.tzim.net:/usr/obj/usr/src/sys/CARENATH amd64 > > It seems that TCP acks are delayed for about a second, so the upload > rate nevers goes above 60kB/s. I can provide wireshark captures done on > the box uploading the files if necessary. > The client is a Windows XP64 box, but I do not recall having the same > problem on 6.2. I did got about 100 MB/s for similar file transfers, but > I had to disable jumbo frames when I upgraded to 7.0-Release because of > some bug on txcsum/rxcsum on re(4) so I only noticed the issue recently. > > The txcsum bug doesn't seem to occur anymore, but now I have this > strange rate issue, with or without checksum offloading disabled. > I also tried with tso disabled. Same results. Is it related to the re(4) > driver ? Or to the TCP stack ?===============================================This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.
Arnaud Houdelette wrote:> I also tried with tso disabled. Same results. Is it related to the re(4) > driver ? Or to the TCP stack ?Having used em driver with 7-RELEASE and 7-STABLE, I can assure you that large MTU size (9100) works well and gives 100mb/s transfer rates easily. So I can only conclude it is releated to the re driver. - Andrew
On Thu, May 29, 2008 at 04:25:33PM +0200, Arnaud Houdelette wrote:
> I got really poor performance when I try to upload files to the box (via
> pureFTP or Samba) when using jumbo frames somewhat above 2k.
>
> uname -a :
> FreeBSD carenath.tzim.net 7.0-STABLE FreeBSD 7.0-STABLE #4: Wed May 28
> 17:45:14 CEST 2008
> tzim@carenath.tzim.net:/usr/obj/usr/src/sys/CARENATH amd64
>
> It seems that TCP acks are delayed for about a second, so the upload
> rate nevers goes above 60kB/s. I can provide wireshark captures done on
> the box uploading the files if necessary.
> The client is a Windows XP64 box, but I do not recall having the same
> problem on 6.2. I did got about 100 MB/s for similar file transfers, but
> I had to disable jumbo frames when I upgraded to 7.0-Release because of
> some bug on txcsum/rxcsum on re(4) so I only noticed the issue recently.
>
> The txcsum bug doesn't seem to occur anymore, but now I have this
> strange rate issue, with or without checksum offloading disabled.
> I also tried with tso disabled. Same results. Is it related to the re(4)
> driver ? Or to the TCP stack ?
>
It seems that handling jumbo frame in re(4) is one of trickiest
feature. Would you show me the following information?
- Captured tcpdump data on receiving side(i.e. host with re(4))
in your test.
- dmesg output of re(4)
- MTU size you've configured
- output of "netstat -nd -I re0"
- output of "ifconfig re0"
--
Regards,
Pyun YongHyeon