Please try r1633Originally Posted by ecaddict
Forum Guru
Please try r1633
Member
It works, thank you for the good correction.
Member
I've measured NFS copy speed with 32K block size (USB HDD using ext3 filesystem).
This is at 480 MHz.
More than 13.5 MB/s, slightly more than I've expected...
When clock is changed to 533, it has gone a bit above 14 MB/s.
If TCP speed could be fixed somehow...
Student Computer Engineer
I have the E3000 GPL sources, so maybe we have better drivers now
update: they are most certainly differen tho!
I did some md5sums on sources and wlan drivers, and a lot of files are not the same
now lets hope these drivers work for our router as well... even when the E3000 has a 5GHz radio as well
Last edited by wpte; 02-06-2010 at 20:05.
Member
I've made a new test with TCP (actually FTP). Normally for every second packet there is an acknowledgement (this is what I felt excessive). This can be however changed in Windows XP quite easily.
So I've booted Windows XP and connected to the router (at 480MHz). PC was not a very powerful, however with gigabit ethernet. Result of 640 MByte file transfer:
Too bad, especially compared with NFS.
Then I've changed TCP ACK frequency based on MS description:
http://support.microsoft.com/kb/328890
The most important point:
Subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters\Interfaces\<Interface GUID>
Entry: TcpAckFrequency
Value Type: REG_DWORD, number
Valid Range: 0-255
Default: 2
I've set it to 18 (hex 12). XP rebooted, otherwise nothing changed.
Repeated test (I've monitored the traffic during the transfer as usual):
Close to 50% increase! This indicates that the per-packet overhead of bulk transfer is quite significant. This fits to the general trend that using modern processors the per-packet overhead is more significant than the per-byte.
A very good paper on this:
http://infoscience.epfl.ch/record/11...iles/paper.pdf
This brings the question, if there is some enhancement related to this issue in recent kernels?
Due to sub millisecond difference between the packets, aggregation could gain a lot and bring TCP performance closer to UDP.
Student Computer Engineer
TcpAckFrequency is something the linux kernels automatically calculates... as in: the kernel detects whether or not the frequency should be changed. (as far as I know)
Windows on the other hand does not include this functionality and requires a manual change in the registry (as you've done).
it is said that the linux implementation is better. Also you can't directly manually change the tcpackfrequency as far as I know.
the odd thing is, that this setting did not had a positive effect for me (on samba), that's why I didn't mentioned it earlier since I'm known with this windows feature.
you have some good results tho
For FTP it works great, 11MB/s with ease.
btw, try winscp for FTP client instead of the windows one, sometimes it's just a little faster.
Last edited by wpte; 05-06-2010 at 22:34.
Member
Unfortunately not my Linux version that I regularly use (I've posted captures already that show that every second packet is acknowledged).
uname -r gives
2.6.32.12-115.fc12.i686.PAE
OK, not the latest Linux kernel but still not that old.
Because this "ACK for every second segment" comes from RFC1122, do you have some link where this is discussed in the context of Linux?
Btw, in some environments this ACK for every second segment does not make sense and indeed something more flexible would be needed. I just did not follow this kind of development (if any) so if someone has some concrete information that could help.
What OS/SW do you use? Was it with a big file (like in my case it was 640MB).
Posting Permissions
