latest max speed with Gigabit switch!

  • Thread starter Thread starter Geoff
  • Start date Start date
The part with the Pulse brand name on it, is the transformers chip.
Ethernet is AC coupled, and a transformer is used for galvanic
isolation. There is no DC path between computers, due to
transformers being on either end. "Pulse" is a popular brand
name for those.

A GbE NIC transformer package, has twice as many coils inside it,
as the one shown in this diagram. Two of the coils are chokes,
while the other two function as transformers. The turns ratio
on the transformer, can be used to boost the voltage level if
necessary.

http://www.coolcomponents.co.uk/catalog/resources/CS8900A/cs8900a-sch.gif

*******

I tried your file sharing test here, just for fun.

I installed the Cenatek RAMDisk program on two computers. Each
computer has a GbE NIC on it. I connected them to my Netgear
gigabit switch (which very likely uses the same silicon chip
as yours does, because everyone likes to use the cheapest chip
possible). I probably paid twice as much as you did for your
TPLink, and all I got was a nice plastic casing :-)

With a 1GB sized RAM disk running on each computer, I could store
the source file on one end, and using file sharing, copy the
file into a RAMDisk at the other end. The RAMDisk removes the
disk as a limiting factor in terms of performance.

When I ran the transfer test, I got an average of 55MB/sec. The
CPU on the laptop was flat out at 100%, while I think my desktop
wasn't quite as heavily loaded. It might have gone faster, if
the CPU clock rate was higher.

Paul
Click to expand...


Paul

I have just tried the RAMDisk software and now removed it !

It seemed to install OK with XP Pro but with Windows could not get it
working until I went right down to 50MB. Then it was like wading
through treacle to do anything on the PC...

Back to normal now!

Cheers

Geoff
 
Paul said:
When I ran the transfer test, I got an average of 55MB/sec. The
CPU on the laptop was flat out at 100%, while I think my desktop
wasn't quite as heavily loaded. It might have gone faster, if
the CPU clock rate was higher.
Click to expand...

Which reminds me that one of the properties of the NIC device in Device
Manager is whether to optimize it for throughput or CPU usage. As I
recall when changing any properties for the NIC, you have to reboot for
them to be effected. When I changed the optimize property, my NIC
stopped working and I had to reboot. From what little I found online,
you set "optimize for throughput" if you mostly download and "optimize
for CPU" if you are running a server app on your host. Yet I also see
comments that it won't much affect network performance for home users
and only makes some difference on servers under heavy loads. With heavy
loads, you don't want the NIC to take a backseat to the CPU.

http://www.pcwintech.com/increase-network-performance

The article notes the "Optimize For" might be just an nVidia NIC
property. That's what I have and it defaulted to CPU for optimize. If
the optimize property is there for your NIC, you could try testing with
it set to Throughput instead of CPU.

Tweak #3 reminds me of something different in Windows Vista/7 regarding
TCP properties but damn if I can remember it now. I think it was called
something like "TCP Receive Window Auto-Tuning Level".

http://ttcshelbyville.wordpress.com/2009/12/20/slow-network-windows/
http://support.microsoft.com/kb/935400
http://support.microsoft.com/kb/947239
 
VanguardLH said:
Which reminds me that one of the properties of the NIC device in Device
Manager is whether to optimize it for throughput or CPU usage. As I
recall when changing any properties for the NIC, you have to reboot for
them to be effected. When I changed the optimize property, my NIC
stopped working and I had to reboot. From what little I found online,
you set "optimize for throughput" if you mostly download and "optimize
for CPU" if you are running a server app on your host. Yet I also see
comments that it won't much affect network performance for home users
and only makes some difference on servers under heavy loads. With heavy
loads, you don't want the NIC to take a backseat to the CPU.

http://www.pcwintech.com/increase-network-performance

The article notes the "Optimize For" might be just an nVidia NIC
property. That's what I have and it defaulted to CPU for optimize. If
the optimize property is there for your NIC, you could try testing with
it set to Throughput instead of CPU.

Tweak #3 reminds me of something different in Windows Vista/7 regarding
TCP properties but damn if I can remember it now. I think it was called
something like "TCP Receive Window Auto-Tuning Level".

http://ttcshelbyville.wordpress.com/2009/12/20/slow-network-windows/
http://support.microsoft.com/kb/935400
http://support.microsoft.com/kb/947239
Click to expand...

On some older OS, I tried tuning the receive window. But you wouldn't
think with a short cable, there'd be enough packets in flight, for
that to be necessary.

On the laptop, I'm not really sure what was using all the CPU. I had
some performance tools open, to record the bandwidth, and I hope
they weren't responsible.

In any case, my results with Win 7 to WinXP is better than when I
tried this a few years back with Win2K (which only managed 40MB/sec).

Paul
 
Geoff said:
Paul

I have just tried the RAMDisk software and now removed it !

It seemed to install OK with XP Pro but with Windows could not get it
working until I went right down to 50MB. Then it was like wading
through treacle to do anything on the PC...

Back to normal now!

Cheers

Geoff
Click to expand...

Yeah, I noticed a bit of strangeness here as well.

I set it up on Windows 7, on the laptop with 3GB of RAM.
I allocated 1GB for the RAMDisk. There was some paging,
while that was being set up (you could see the hard drive light
come on for 30 seconds or so). The RAMDisk worked fine though,
and I could do some testing with it.

Later, I decided it would be fun to set the RAMDisk to
2GB instead of 1GB. I shut the current RAMdisk down,
and it doesn't seem like it released the memory. Then
it paged for a long long time, before declaring it
couldn't set up the RAMDisk. And after exiting the
RAMDisk setup program, without succeeding at getting
the RAMdisk going again, Task Manager said all the
system memory was still in use.

That's when the testing stopped, and I shutdown the
laptop.

Paul
 
I think this is a good direction to look.

There are more properties in the NIC properties entry in Device Manager
than just the speed. It could be some kind of flow control option which
is incorrectly set.

My NIC has:

"Flow Control" (with a possible option of "Disabled")
"Jumbo Packet" (currently 1514, for compatibility)
"Receive Buffers" 256
"Transmit Buffers" 256

I also have 802.1p which is currently enabled, but could be turned off.

http://en.wikipedia.org/wiki/802.1p

Experimenting with some settings there might help.

*******

With regard to collecting information, you can use Wireshark on
both computers, and collect traces on them at the same time.

First, go to the Date and Time panel, and request NTP time synchonization.
Use the same NTP server for both computers. The intention of doing that,
is so the time stamps (displayed in hours:minute:seconds) match. Then,
when you attempt a transfer between machines, you can compare the
traces on the two machines, and see if a packet sent by one machine,
is showing up at the other machine (within the time stamp uncertainty).

I'm having trouble understanding how "duplicate ACKs" could be
showing up, when we're talking about a network connection that
only goes through a switch. That seems pretty weird.

*******

And just for fun, there is another way to analyse file copying,
thanks to Mark Russinovich.

"Inside Vista SP1 File Copy Improvements"

http://blogs.technet.com/b/markrussinovich/archive/2008/02/04/2826167.aspx

Paul
Click to expand...

Paul

I have just tried the various nic speed settings with xcopy / dos and
get the same situation, the best speeds are with setting 100Mbps/full
duplex on the nics - I then get 7MB/sec transfers.

Cheers

Geoff
 
Paul,

I have just installed and used the Realtek Daignostic Utility - ran
all its tests and nothing wrong. It indicates a low speed for transmit
with autonegociation but makes no comment!

Geoff
 
Geoff said:
Paul,

I have just installed and used the Realtek Daignostic Utility - ran
all its tests and nothing wrong. It indicates a low speed for transmit
with autonegociation but makes no comment!

Geoff
Click to expand...

You can use the Command Prompt (DOS Window) to do some testing.

If you run "ping" from one computer to the other, does a response
always come back ?

Say one computer is 192.168.0.2 and the other is 192.168.0.3. If
you are on the 192.168.0.2 computer, you'd try

ping -n 1000 192.168.0.3

to test whether packets come back or not. That would send a thousand
test packets, and note how many come back. To stop the test you
can press control-C in the command prompt window. If you don't use
the -n option, then only a small number of tests are made.

In this example, you can see one ping attempt failed with a
request timed out.

http://www.fa1nt.net/pavlov_connection_issues_template_files/image006.jpg

Paul
 
You can use the Command Prompt (DOS Window) to do some testing.

If you run "ping" from one computer to the other, does a response
always come back ?

Say one computer is 192.168.0.2 and the other is 192.168.0.3. If
you are on the 192.168.0.2 computer, you'd try

ping -n 1000 192.168.0.3

to test whether packets come back or not. That would send a thousand
test packets, and note how many come back. To stop the test you
can press control-C in the command prompt window. If you don't use
the -n option, then only a small number of tests are made.

In this example, you can see one ping attempt failed with a
request timed out.

http://www.fa1nt.net/pavlov_connection_issues_template_files/image006.jpg

Paul
Click to expand...

Paul I tried the ping -n 1000 with both 100Mbps/full duplex and
autonegociation and got 0% loss for both...

I will speak to ADDON Tech Support tomorrow and who knows ....

I will let you know what they say.

Cheers

Geoff
 
Can you borrow stuff and switch out? Possible culprits: NICs, cables,
switch, Win7.

If you haven't already, try this:

http://answers.microsoft.com/en-us/...fer-slow/45bd0354-8ae1-4057-aa43-13f5a16b802d

More answers here:
http://www.google.com/search?q=slow+file+copy+windows+7&ie=utf-8&oe=utf-8&aq

and here:
http://www.google.com/search?hl=en&...nswers.microsoft.com+slow+file+copy+windows+7
Click to expand...

Mike

Thanks for the links - no luck so far!

I have emailed a full description of the case to ADDON's Tech Support
and wait for their thoughts!

Geoff
 
Geoff said:
Mike

Thanks for the links - no luck so far!

I have emailed a full description of the case to ADDON's Tech Support
and wait for their thoughts!

Geoff
Click to expand...

Oops. Previous post got away on me :-)

I've been testing my gigabit setup here again today, and my results
are all over the place. I got as low as perhaps 15MB/sec and as high
as 70MB/sec. I'm getting better results using File Sharing, than
with FTP, which doesn't make sense to me. In some cases, I had
high CPU utilization. In other cases, low CPU utilization. I even
tried switching on Jumbo Packets, and it actually ran *slower*.
What a mess...

In terms of Jumbo Packets, I learned that my RealTek RTL8169
based (PCI) NIC, has a Jumbo limit of around 7000 bytes or so.
It actually can't do the 9000 number that my other NIC can do.
I used Wireshark, to verify it was actually sending a big packet,
and one in three data packets was close to the 7000 limit. But
even so, performance wasn't very good.

Today, I was testing with Ubuntu on one end, instead of Windows,
to see how much of a difference that would make. Right now, neither
OS really has me impressed. It almost feels like this stuff never
got tested or something. I don't think I'm ever going to see
"wire speed transfer" with the way things have gone so far.

Paul
 
Oops. Previous post got away on me :-)

I've been testing my gigabit setup here again today, and my results
are all over the place. I got as low as perhaps 15MB/sec and as high
as 70MB/sec. I'm getting better results using File Sharing, than
with FTP, which doesn't make sense to me. In some cases, I had
high CPU utilization. In other cases, low CPU utilization. I even
tried switching on Jumbo Packets, and it actually ran *slower*.
What a mess...

In terms of Jumbo Packets, I learned that my RealTek RTL8169
based (PCI) NIC, has a Jumbo limit of around 7000 bytes or so.
It actually can't do the 9000 number that my other NIC can do.
I used Wireshark, to verify it was actually sending a big packet,
and one in three data packets was close to the 7000 limit. But
even so, performance wasn't very good.

Today, I was testing with Ubuntu on one end, instead of Windows,
to see how much of a difference that would make. Right now, neither
OS really has me impressed. It almost feels like this stuff never
got tested or something. I don't think I'm ever going to see
"wire speed transfer" with the way things have gone so far.

Paul
Click to expand...


Paul,

I did speak to ADDON Tech Support today, who have an office in the UK,
but my request for help has been forwarded to head office - in Taiwan?

The reply will take 2/3 days.

Incidentally I have lashed out on ordering 2 TP-Link 1Gbps NICs - £6
each. I thought worth trying as they are the same make as the 1Gbps
switch!

Cheers

Geoff
 
Paul

'just to say that I had a reply from ADDON but they so far have only
given me links to drivers which I have already downloaded from the
realtek site .. I have used them but cannot get better than the
100Mbps setting ..

Cheers

Geoff
 
Geoff said:
Paul

'just to say that I had a reply from ADDON but they so far have only
given me links to drivers which I have already downloaded from the
realtek site .. I have used them but cannot get better than the
100Mbps setting ..

Cheers

Geoff
Click to expand...

I've done some more testing, just to see what my hardware was capable of.

I have three brands of NICs, a Marvell, a Broadcom, and a RealTek.

If the RealTek is involved, I can transfer at 70MB/sec.

If the RealTek is not being used, I can achieve over 100MB/sec.

The program I used for test, was two Ubuntu LiveCDs and the
"rcp" command, which copies files to remote computer hard
drives. When using that command, my CPU utilization was around
10% (except for the laptop, which ran at 30% for at least
part of the transfer). The two Core2 computers would run at
around 10% during the transfer.

I got those results, without needing Jumbo packets.

The RealTek chip is sitting on the PCI bus, which isn't a good
choice, and I knew I could not get a super-high numbers that
way. But I should have been able to get a little over 100MB/sec if
the chip had been a good design.

The RealTek chip (RTL8169SC) is on a TPLink card I bought some months ago.
The other two example chips, are soldered to the motherboard.

When using other protocols, I can see between 15MB/sec and 70MB/sec
when the RealTek is being used. I can get a result as low as 3MB/sec,
if using SAMBA file sharing on Linux, but that is a SAMBA/SMB issue.
The 15MB/sec might be considered a realistic (low) scenario. I managed
to get 70MB/sec with pure Windows file sharing. But in terms of
CPU utilization, the "rcp" command seemed to be doing a
pretty good job. In Linux, while I was testing, the test file
was stored in RAM, in the /tmp directory. And the same, 1GB
sized file was used, as had been used in the previous
Windows+RAMDisk tests.

*******

Now, I haven't tested this yet, but there is a program here
that can be used for transfer rate tests. Since it doesn't write
the data to disk, this should be more of a pure network test.
You start a copy in receive mode on one machine, then start
another copy on a second machine in transmit mode. And then
the benchmark runs.

http://en.wikipedia.org/wiki/Ttcp

http://www.pcausa.com/Utilities/pcattcp.htm

You may also be able to boot up some Linux LiveCDs, and run
copies of the Linux version from there.

Paul
 
I've done some more testing, just to see what my hardware was capable of.

I have three brands of NICs, a Marvell, a Broadcom, and a RealTek.

If the RealTek is involved, I can transfer at 70MB/sec.

If the RealTek is not being used, I can achieve over 100MB/sec.

The program I used for test, was two Ubuntu LiveCDs and the
"rcp" command, which copies files to remote computer hard
drives. When using that command, my CPU utilization was around
10% (except for the laptop, which ran at 30% for at least
part of the transfer). The two Core2 computers would run at
around 10% during the transfer.

I got those results, without needing Jumbo packets.

The RealTek chip is sitting on the PCI bus, which isn't a good
choice, and I knew I could not get a super-high numbers that
way. But I should have been able to get a little over 100MB/sec if
the chip had been a good design.

The RealTek chip (RTL8169SC) is on a TPLink card I bought some months ago.
The other two example chips, are soldered to the motherboard.

When using other protocols, I can see between 15MB/sec and 70MB/sec
when the RealTek is being used. I can get a result as low as 3MB/sec,
if using SAMBA file sharing on Linux, but that is a SAMBA/SMB issue.
The 15MB/sec might be considered a realistic (low) scenario. I managed
to get 70MB/sec with pure Windows file sharing. But in terms of
CPU utilization, the "rcp" command seemed to be doing a
pretty good job. In Linux, while I was testing, the test file
was stored in RAM, in the /tmp directory. And the same, 1GB
sized file was used, as had been used in the previous
Windows+RAMDisk tests.

*******

Now, I haven't tested this yet, but there is a program here
that can be used for transfer rate tests. Since it doesn't write
the data to disk, this should be more of a pure network test.
You start a copy in receive mode on one machine, then start
another copy on a second machine in transmit mode. And then
the benchmark runs.

http://en.wikipedia.org/wiki/Ttcp

http://www.pcausa.com/Utilities/pcattcp.htm

You may also be able to boot up some Linux LiveCDs, and run
copies of the Linux version from there.

Paul
Click to expand...


Paul,

I have made 2 Ubuntu LiveCDs and have tried using them - without
installing ubuntu.

Both my PCs get their IPs from the router and on each PC I can ping
both PCs and the router.

But! When I try to see the PCs on the network I see Windows Network
but cannot use that to see the other PC.

How do I make both PCs visible on the network?

Cheers

Geoff
 
Geoff said:
Paul,

I have made 2 Ubuntu LiveCDs and have tried using them - without
installing ubuntu.

Both my PCs get their IPs from the router and on each PC I can ping
both PCs and the router.

But! When I try to see the PCs on the network I see Windows Network
but cannot use that to see the other PC.

How do I make both PCs visible on the network?

Cheers

Geoff
Click to expand...

Click the Google video link on this page.

http://screencasts.ubuntu.com/SAMBA_Filesharing

The first part of the video, shows how to use your Linux box as a client
of other computers which are sharing their files.

The second part of the video, shows how to set up the Linux box so it
shares files via SMB, with other Windows computers.

I've had occasional problems with getting sharing to work,
and sometimes if I'm using the Linux client to reach
a Windows box, the Windows box simple refuses to show up.
It seems to be related a bit, to the order the boxes
are booted in. So if the Windows box is already running
and serving files, and then you boot the Linux box,
that improves the odds that the PC will show up.

When things don't work on Linux, it can be things like a
firewall stopping it, but the firewall is turned off by
default. Things can also fail for a variety of
authentication issues. And getting usable documentation
on all the issues, isn't exactly easy.

When I tried to test Linux versus Windows, using SAMBA,
I didn't get very fast results.

*******

For todays results, I brought another computer out of
storage, as it has a good Ethernet interface. The CMOS
battery was flat, so I had to enter the BIOS settings
again, but at least the thing still works. I booted
Ubuntu, and stupid Ubuntu didn't autonegotiate to GbE
rates. I had to force it to 1Gigabit with ethtool.
That seems to be a long-standing bug.

From my Core2 machine, to either of the other good
machines, it runs 112.2MB/sec. From the other machines,
towards my Core2 (the one I'm typing on), then the rate
is 117MB/sec. I expect at that point, the rest of the
bandwidth is for the packet headers (ratio of packet
header to payload). So I'm not expecting to see 125MB/sec,
since the 125MB/sec is for the whole packet, which is
header plus payload data.

The test method was rcp or remote copy. For example,
this would send the test file from the local machine,
to machine "111". In Ubuntu, you install "rsh-client"
and "rsh-server" packages, as well as set up
~/.rhosts file with the IP address of the other
machine (part of authentication). rcp is not
considered a secure protocol, but is fine
in a LAN environment. It's only dangerous, if
third parties can "sniff" the traffic.

rcp /tmp/test.bin 192.168.123.111:/tmp/test.bin

I'm using the /tmp directory, because it's mounted on
RAM. But you have to be careful, not to send too large
a file, because the file transfer doesn't immediately stop
if /tmp runs out of room. I actually managed to
trigger the OOM killer on that Linux box that ran
out of RAM, and then had a mess to clean up. Using the
"top" command, "vmstat", or the system monitor from the
menus, you can get some ideas on memory usage. For some
reason, if you use "df" to check the max size of /tmp,
the value is larger than the actual RAM it is mounted
on top of, which seems a bit bizarre.

My guess at the moment is, that 117MB/sec user data,
is all I'm going to get. The rest could well be
overhead bytes. And that is using the rcp protocol.
I don't think FTP worked that well...

Paul
 
Back
Top