send performance of rl(4)
Transferring files from my desktop to my laptop with rsync (over a point-to-point netowork connection) is extremely slow, maxing out at around 50 kB/s and often dropping to 0. Both systems show hardly any activity. Is this normal for rsync running over a network? There is a rsync daemon running on the laptop. Network interface on the laptop is xl(4), the desktop is rl(4). I think that the link is OK, because transferring dumps with nc from the laptop to the desktop can max out the connection (9000-1 kB/s over 100baseTX full-duplex). However, when I try nc to transfer a file from the desktop to the laptop it is extremely slow, topping out at around 200 kB/s. When I check with netstat, the qeues on the laptop are empty, while the send-queue on the desktop shows a large value: Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address(state) tcp4 0 40951 192.168.0.1.55460 rfs.65000 ESTABLISHED I've tried disabling the firewall on the desktop (laptop doesn't have one) and enabling polling on both interfaces. It doesn't seem to make any difference. Are there any bottlenecks I could check for? Or is this just a case of crappy hardware? The rl(4) based cards don't seem to have a very good reputation. I've got an old 3com 905B card lying around. Would it help if I used that instead? Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpHNvXPw0gra.pgp Description: PGP signature
Re: send performance of rl(4)
Transferring files from my desktop to my laptop with rsync (over a point-to-point netowork connection) is extremely slow, maxing out at around 50 kB/s and often dropping to 0. Both systems show hardly any activity. Is this normal for rsync running over a network? There is a no. rsync daemon running on the laptop. Network interface on the laptop is xl(4), the desktop is rl(4). it may be problem with autoconfiguration of speed and half/full duplex. try setting it manually on one or both sides. it's unfortunately common ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: send performance of rl(4)
On Sun, Dec 14, 2008 at 03:45:35PM +0100, Wojciech Puchar wrote: Transferring files from my desktop to my laptop with rsync (over a point-to-point netowork connection) is extremely slow, maxing out at around 50 kB/s and often dropping to 0. Both systems show hardly any activity. Is this normal for rsync running over a network? There is a no. Good, so there is presumably something I can fix. rsync daemon running on the laptop. Network interface on the laptop is xl(4), the desktop is rl(4). it may be problem with autoconfiguration of speed and half/full duplex. try setting it manually on one or both sides. Both were showing 100baseTX full-duplex on autoselect. Setting both manually with 'ifconfig [rl1|xl0] media 100baseTX mediaopt full-duplex' didn't improve things. it's unfortunately common :-( Would swapping the rl(4) card with a xl(4) card help? I've got one in my spare parts bin. I presume two xl(4) cards would have no trouble talking to eachother. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp6IRkTuvugX.pgp Description: PGP signature
Re: send performance of rl(4)
it may be problem with autoconfiguration of speed and half/full duplex. try setting it manually on one or both sides. Both were showing 100baseTX full-duplex on autoselect. Setting both manually with 'ifconfig [rl1|xl0] media 100baseTX mediaopt full-duplex' didn't improve things. try half-duplex, then other cable, then other card. it's unfortunately common :-( Would swapping the rl(4) card with a xl(4) card help? I've got one in my it may. but one of the cards or the cable is bad. on short cables when one pin does not contact it MAY work, just like that :) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: send performance of rl(4)
On Sun, Dec 14, 2008 at 04:34:17PM +0100, Wojciech Puchar wrote: it may be problem with autoconfiguration of speed and half/full duplex. try setting it manually on one or both sides. Both were showing 100baseTX full-duplex on autoselect. Setting both manually with 'ifconfig [rl1|xl0] media 100baseTX mediaopt full-duplex' didn't improve things. try half-duplex, then other cable, then other card. --- --- -- :-( :-( :-) Swapping the rl(4) card for a xl(4) card did the trick. I can now saturate the line in both directions. I think I'm going to scrap the other rl(4) card in my machine as well and replace it with an fxp(4) card. Thanks Wojciech! Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpXIFAdESzkR.pgp Description: PGP signature
Re: send performance of rl(4)
On Mon, 15 Dec 2008 00:25:01 +0100, Roland Smith rsm...@xs4all.nl wrote: Swapping the rl(4) card for a xl(4) card did the trick. I can now saturate the line in both directions. I think I'm going to scrap the other rl(4) card in my machine as well and replace it with an fxp(4) card. Yeah... something I did some years ago - and I'm still happy with it. I found that - quite in general - the xl and fxp NICs do have better performance than the rl ones. -- Polytropon From Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: send performance of rl(4)
:-( :-( :-) Swapping the rl(4) card for a xl(4) card did the trick. I can now saturate the line in both directions. I think I'm going to scrap the other rl(4) card in my machine as well and replace it with an fxp(4) card. no. realtek cards are not bad by design. this particular was broken ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: send performance of rl(4)
On Mon, 15 Dec 2008 00:42:31 +0100 (CET), Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: realtek cards are not bad by design. this particular was broken I always found Realtek cards okay because they would work everywhere, nearly every OS supported them. But especially the RTL8139, if I remember correctly, was so busy generating IRQs that it didn't find the time to have a good performance. :-) Maybe Realteks newer models perform better. I'm quite happy with 3Com's and Intel's NICs, I usually give away Realtek NICs along with computer systems I built for others. -- Polytropon From Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: send performance of rl(4)
I always found Realtek cards okay because they would work everywhere, nearly every OS supported them. But especially the RTL8139, if I remember correctly, was so busy generating IRQs that it didn't find the time to have a good performance. :-) but it works very well. in places when there is no high traffic constantly i happily use them. Maybe Realteks newer models perform better. at least my gigabit realtek integrated with motherboard was buggy, disabling hardware checksumming fixed it PARTIALLY. but still it do locks up every month or so of heavy traffic. I'm quite happy with 3Com's and Intel's NICs, I usually give away Realtek NICs along with computer systems I built for others. esp. with windows there is not much difference. other os overhead is larger than interrupt overhead. anyway - it's primitive hardware, but WORKING :) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org