Makes sense.
Impact of FD/HD is negligible given you are mostly transferring data in one way only.
Without bus master DMA, it will likely only use native DMA which will likely slow down performance roughly to the levels you see it (upper limit is about 1.6MB/S on systems with 16bit ISA). In fact it could be slightly faster if you don't set DMA channel and use a simple PIO (not sure if the Linux driver supports that).
wrote:Impact of FD/HD is negligible given you are mostly transferring data in one way only.
With TCP (and any protocol on top of TCP) the impact is noticable - ACK packets need some bandwidth in the opposite direction.
With 100 Mbps Fast Ethernet cards, and fast enough rest of the system, FTP transfer should be 11+ MB/s
With 10 Mbps Ethernet cards, FTP transfer should be 1.1+ MB/s, but... it's usually something like 900..1000 KB/s
Why?
Because 10 Mbps cards - even those that support FD, eg. 3C509B - lack NWay, so they can't auto-negotiate FD with the switch.
So, to get FD working, it's necessary to manually enable it on both the card and the switch - and the latter requires a managed switch.
Nie tylko, jak widzicie, w tym trudność, że nie zdołacie wejść na moją górę, lecz i w tym, że ja do was cały zejść nie mogę, gdyż schodząc, gubię po drodze to, co miałem donieść.
TCP ACK is like 40 bytes per every 1500 bytes of data in the worst case. Furthermore the TCP window size will grow up to 65,535 bytes so there will be very few ACKs unless there are transmission errors.
Since you likely use a cross-over cable or a switch there are will be no ethernet collisions. Thus the FD/HD should hardly change things especially as your bottleneck is in the host bus speed and not the link speed. It should only improve things if you have a mixed inbound/outbound traffic in a much faster system.
wrote:It should only improve things if you have a mixed inbound/outbound traffic in a much faster system.
TCP is mixed inbound/outbound, FTP - probably even more so.
Just did a few quick "wget -O /dev/null ftp://..." tests, this time with a Davicom 9102, ie. PCI, 100 Mbps, supporting NWay - so by default it auto-negotiates 100baseTx-FD:
10.60 MB/s
mii-tool -A 100baseTx-HD eth0
8.97 MB/s
mii-tool -A 10baseT-FD eth0
1.12 MB/s
mii-tool -A 10baseT-HD eth0
781 KB/s
So, the difference is far from negligible, and in case of 10baseT-FD vs. HD it's even greater than I expected, must be something wrong with this card/driver, as 3C509B in 10baseT-HD achieved 891 KB/s
Nie tylko, jak widzicie, w tym trudność, że nie zdołacie wejść na moją górę, lecz i w tym, że ja do was cały zejść nie mogę, gdyż schodząc, gubię po drodze to, co miałem donieść.
I wouldn't expect such difference.
Could be a result of TX/RX errors /buffer overruns which then cause retransmissions and avoid growing of TCP window size.
