Geekzone: technology news, blogs, forums
Guest
Welcome Guest.
You haven't logged in yet. If you don't have an account you can register now.


Filterer

489 posts

Ultimate Geek


#11382 19-Jan-2007 08:29
Send private message

I have got two computers connected with about 2 meters of Cat5e ethernet cable, each with network cards (from different manufactures)  that claim to be able to handle 1Gb/s.

By default when connected together they ran at 100Mb/s however in the settings instead of automatically detect network speed If I manually select 1Gb/s the two cards claim to be connected at 1000 Mb/s.

If I try to transfer a large file and watch the network utilization with Windows Task Manager it normally sits at less than 10%, which makes me think that in fact they are connected at 100Mb/s, however I am sure I have seen over 12.5%.

Any suggestions as to what settings I need to start fiddling with?




pɐǝɥ sıɥ uo ƃuıpuɐʇs

View this topic in a long page with up to 500 replies per page Create new topic
 1 | 2 | 3
muppet
2297 posts

Uber Geek

Trusted

  #58328 19-Jan-2007 09:50
Send private message

Almost all consumer grade GigE cards I've seen are pretty crappy really. Most have terrible problems with GigE support and even if you do get it working you'll get ~400Mb/s through them tops before they start to crap out. Depending on how bad their network drivers are, if you flood them with traffic they can lock them or even lock the whole machine up (though that was under Linux, so it might be premature to blame the drivers!)

Anyway, I wouldn't put too much faith in Windows network monitor. If you want to see what throughput you're getting between the two devices, iperf is your friend:

IPerf Homepage

Download 1.7.0, I know there's a version 2 but no one seems to trust it, myself included.
Windows Binary Click Here

On one machine, run iperf as a server:

iperf -s -u -w2m -i1

Those flags mean:

s: run as server
u: use UDP
w: use a buffer of 2meg
i: print out a report every second.

Then on your other PC, run iperf as a client:

iperf -c [ip address of server] -u -b400M -w2m -i1 -t60

Those flags mean:

c: run as client
u: use UDP
b: Send 400Mb/s data
w: Use a buffer of meg
t: run for 60 seconds
i: print a report every second

You will get some stats printing on the server about how much data it's receiving.

You can also use iperf in TCP mode. In TCP mode you don't tell it how much bandwidth to send, it tunes its TCP window to get the maximum it can out of the link.

For this:

server: iperf -s -w2m -i1
client: iperf -c [ip address of server] -w2m -i1 -t60

Have a play around with iperf and you'll soon see how much data you're really getting between the two devices. If you are only getting 100M, time to look for updated drivers probably, or even new cards.

Hope this helps.

Tim

Filterer

489 posts

Ultimate Geek


  #58395 19-Jan-2007 23:02
Send private message

Cheers dude, I will have a look into it over the weekend




pɐǝɥ sıɥ uo ƃuıpuɐʇs

 
 
 
 


juha
1319 posts

Uber Geek

Trusted

  #58434 21-Jan-2007 14:04
Send private message

Ah yes, gigabit networks... I've noticed several issues there. One being that hard drives and applications sending/receiving data can't yet match the speed of GigE. Best I've seen with FTP and SMB transfers is around 200Mbit/s with SATA-II drives.

Windows XP still seems to default to a tiny, 8kbyte TCP window by default:

C:\iperf>iperf -c [server] -t30
------------------------------------------------------------
Client connecting to [server], TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[1884] local port 4910 connected with port 5001
[ ID] Interval Transfer Bandwidth
[1884] 0.0-30.0 sec 1.10 GBytes 316 Mbits/sec

Let's increase that a bit:

C:\iperf>iperf -c [server] -w64k -t60

------------------------------------------------------------
Client connecting to [server], TCP port 5001
TCP window size: 64.0 KByte
------------------------------------------------------------
[1884] local [client] port 4885 connected with [server] port 5001
[ ID] Interval Transfer Bandwidth
[1884] 0.0-60.0 sec 5.17 GBytes 740 Mbits/sec

Bigger windows than that don't improve performance on the LAN (I'm testing between two Intel PRO-1000 equipped Windows boxes, over a cheapo Cnet Gigabit switch; standard 1500 byte frames).

Interestingly enough, if I use the UDP incantation per Muppet's post, I get:

C:\iperf>iperf -c [server] -u -w2m -b400M -t30
------------------------------------------------------------
Client connecting to [server] UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 2.00 MByte
------------------------------------------------------------
[1884] local [client] port 4943 connected with [server] port 5001
[ ID] Interval Transfer Bandwidth
[1884] 0.0-30.0 sec 480 MBytes 134 Mbits/sec
[1884] Server Report: Jitter Lost/Total datagrams
[1884] 0.0-30.0 sec 480 MBytes 134 Mbits/sec 0.917 ms 0/342713 (0%)
[1884] Sent 342713 datagrams




muppet
2297 posts

Uber Geek

Trusted

  #58444 21-Jan-2007 16:53
Send private message

Strange that you get such a variance in performance UDP vs TCP.

I must admit that most of my testing has been on Linux boxes, so maybe the windows boxes perform a little differently.

juha
1319 posts

Uber Geek

Trusted

  #58445 21-Jan-2007 17:01
Send private message

If I send UDP from FreeBSD 6.2->Windows Server 2003, I get the same speed as with TCP (510Mbit/s, suspect the bge driver isn't working too good at the moment). XP to Windows Server is really slow for UDP. Hmm.




muppet
2297 posts

Uber Geek

Trusted

  #58454 21-Jan-2007 19:32
Send private message

Give them (or it) a reboot.

I remember now seeing some very funky stuff, but once rebooted things settled down. Then a few weeks later, we'd have to reboot again.

juha
1319 posts

Uber Geek

Trusted

  #58457 21-Jan-2007 19:51
Send private message

d:\iperf>iperf -c [server] -u -b1000m -w2m -i1s
------------------------------------------------------------
Client connecting to [server], UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 2.00 MByte
------------------------------------------------------------
[304] local [client] port 51375 connected with [server] port 5001
[ ID] Interval Transfer Bandwidth
[304] 0.0- 1.0 sec 16.6 MBytes 139 Mbits/sec
[304] 1.0- 2.0 sec 5.71 MBytes 47.9 Mbits/sec
[304] 2.0- 3.0 sec 5.70 MBytes 47.8 Mbits/sec
[304] 3.0- 4.0 sec 5.71 MBytes 47.9 Mbits/sec
[304] 4.0- 5.0 sec 5.70 MBytes 47.8 Mbits/sec
[304] 5.0- 6.0 sec 5.70 MBytes 47.8 Mbits/sec
[304] 6.0- 7.0 sec 5.70 MBytes 47.8 Mbits/sec
[304] 7.0- 8.0 sec 5.70 MBytes 47.9 Mbits/sec
[304] 8.0- 9.0 sec 5.69 MBytes 47.8 Mbits/sec
[304] 9.0-10.0 sec 5.70 MBytes 47.9 Mbits/sec
[304] 0.0-10.0 sec 67.9 MBytes 57.0 Mbits/sec
[304] Server Report:
[304] 0.0-10.0 sec 67.9 MBytes 57.0 Mbits/sec 0.904 ms 0/48440 (0%)
[304] Sent 48440 datagrams

This is with Vista; setting the -b paramater to 400M produces the same result.




 
 
 
 


Fraktul
836 posts

Ultimate Geek

Trusted

  #58479 22-Jan-2007 12:02
Send private message

If the NIC's support jumbo frames you should also try using them. This should increase performance if the drivers are up to spec but as Juha points out your HDD is most likely the limiting factor for file transfers.

Iperf should yeild the best theoretical results as it shouldnt be access your HDD.

Also there is a java gui front end to iperf fyi Juha, produces some pretty graphs etc.

Filterer

489 posts

Ultimate Geek


  #58489 22-Jan-2007 16:25
Send private message

Thanks for the answers guys, I still haven't had a chance to have a good play with it, if memory serves me right I had already tried jumbo frames.

At the current time I don't think my HDD is the limiting factor as I can write from my USB 2.0 harddrive a lot quicker then from the network




pɐǝɥ sıɥ uo ƃuıpuɐʇs

mojo
13 posts

Geek


  #58747 24-Jan-2007 17:24
Send private message

I'm also noticing a huge discrepancy in windows vs. linux.

Firstly, for some reason when linux is the server, I can't get above 100 Mbits/s using UDP, I tried iperf 2.0 and I can't get above 1 Mbit/s using UDP and linux as the server. That I accept as either a bug in the program or some quirk of my hardware, not a big deal.

The interesting part is the results I get using TCP and switching which box is the client/server.

With linux as the server, I can do around 780 Mbits/s, and with windows only about 350 Mbits/s.

Windows pegs both of its cores while being a server, and as a client pegs one and the other is about 60% in use.

Linux uses about 10% as a client and 25% as a server.

Hardware is as follows.

Windows:
AthlonX2 4600, socket AM2 (2x 2.4Ghz, 512K L2 cache each core)
2 GB DDR2-800
nForce 570 SLI chipset, using the integrated nVidia gigabit nic

Linux:
AthlonXP 2500 (barton core), socket A (1.83 Ghz, 515K L2 cache)
768MB DDR 400
Intel Pro 1000 MT gigabit nic

Is linux just that much more efficient or is the intel nic making all the difference?

muppet
2297 posts

Uber Geek

Trusted

  #58748 24-Jan-2007 17:27
Send private message

I'd say your Intel nic is doing a lot of work in the hardware (checksums etc) while your NVIDIA probably does a lot of it in the software driver.

Try tuning your Windows box as well with something like The TCP Optimizer and see if it makes a difference. Backup your settings first of all if you're worried about using the program (though don't be, works fine for me and everyone else)

mojo
13 posts

Geek


  #58750 24-Jan-2007 17:51
Send private message

I used the optimtimizer and my speeds went up by maybe 1%, I really wasn't expecting much. I would be quite interested though in someone doing these tests in various configurations, like comparing how much of a difference there is between windows and linux with equal hardware, and how much of a difference a quality nic makes vs. something onboard. My onboard nic is supposed to be completely amazing if you buy into nVidia's marketing hype, good thing I don't.

juha
1319 posts

Uber Geek

Trusted

  #58753 24-Jan-2007 18:38
Send private message

How are you testing with iperf though? Are you bumping up the TCP send/receive buffers? I've found that on a gigabit LAN, you need around 64kbytes for full speed.




mojo
13 posts

Geek


  #58756 24-Jan-2007 19:09
Send private message

I tried various values up to 2 MB, didn't really make a difference. Considering the CPU usage difference between the 2 boxes, I'd say the intel nic is making most of the difference. It's often said that linux is far more efficient at network operations, but I don't think it's THAT much better (pegged dual core vs. fairly old single core not breaking a sweat).

Filterer

489 posts

Ultimate Geek


  #59114 29-Jan-2007 11:15
Send private message

Well the problem seems to be two fold.

1st of all, which I hadn't mentioned earlier the I have to force both cards onto 1000Mb/s mode, under auto-negotiation mode they always default back to 100 Mb/s, so I am wondering if the two are really compatible.

Secondly when using iperf in tcp mode, it starts out at around 80Mb/s, but then settles out at around 60Mb/s. On my AMD Athalon 2500+ with 512 Ram and a "Realtek RTL8169/810 Family Gigabit Ethernet NIC" whitch is integrated into the motherboard I am lucky to break 20% cpu usage, normally sitting at about 10%.

On my other box with is a file/print/adsl/ server which is a p3 800 with 240MB ram running a TP-LINK TG-3269 Gigabit Ethernet Adapter" internal PCI card I immediately get 100% cpu usage, So I assume that it is a crappy card and not doing any of the checksumming even though in the networking settings tcp offload is set to true.

Any further suggestions or is it time for a better NIC in my server, as I doubt the difference is just due to the cpu speeds ?




pɐǝɥ sıɥ uo ƃuıpuɐʇs

 1 | 2 | 3
View this topic in a long page with up to 500 replies per page Create new topic





News »

Nanoleaf enhances lighting line with launch of Triangles and Mini Triangles
Posted 17-Oct-2020 20:18


Synology unveils DS1621+ 
Posted 17-Oct-2020 20:12


Ingram Micro introduces FootfallCam to New Zealand channel
Posted 17-Oct-2020 20:06


Dropbox adopts Virtual First working policy
Posted 17-Oct-2020 19:47


OPPO announces Reno4 Series 5G line-up in NZ
Posted 16-Oct-2020 08:52


Microsoft Highway to a Hundred expands to Asia Pacific
Posted 14-Oct-2020 09:34


Spark turns on 5G in Auckland
Posted 14-Oct-2020 09:29


AMD Launches AMD Ryzen 5000 Series Desktop Processors
Posted 9-Oct-2020 10:13


Teletrac Navman launches integrated multi-camera solution for transport and logistics industry
Posted 8-Oct-2020 10:57


Farmside hits 10,000 RBI customers
Posted 7-Oct-2020 15:32


NordVPN starts deploying colocated servers
Posted 7-Oct-2020 09:00


Google introduces Nest Wifi routers in New Zealand
Posted 7-Oct-2020 05:00


Orcon to bundle Google Nest Wifi router with new accounts
Posted 7-Oct-2020 05:00


Epay and Centrapay partner to create digital gift cards
Posted 2-Oct-2020 17:34


Inseego launches 5G MiFi M2000 mobile hotspot
Posted 2-Oct-2020 14:53









Geekzone Live »

Try automatic live updates from Geekzone directly in your browser, without refreshing the page, with Geekzone Live now.


Support Geekzone »

Our community of supporters help make Geekzone possible. Click the button below to join them.

Support Geezone on PressPatron



Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly to your computer or smartphone by using a feed reader.

Alternatively, you can receive a daily email with Geekzone updates.