Yes, for UDP 32K is OK, but for (because of) TCP 64K is preferred.Originally Posted by lly
Forum Guru
Yes, you found right place, thank you for investigations!
Tell me your opinion - 32K will be enough?
Last edited by lly; 31-05-2010 at 19:13.
Member
Yes, for UDP 32K is OK, but for (because of) TCP 64K is preferred.
Forum Guru
Well, I will do like:
128M RAM - 64K
32M RAM - 32K (like in 2.4 based FW)
Member
OK, thanks.
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).
Student Computer Engineer
Well it should have that...
linky linky: http://wiki.hsc.com/wiki/Main/InsideLinuxTCPDelayedAck
http://www.cs.helsinki.fi/research/i...s/linuxtcp.pdf
what about that?
Also I believe that linux has a static or dynamic setting, which can be changed in the sources... the static is standard 10ms I believe.
Windows 7 ultimate 64bit and winscp as FTP client as I said.What OS/SW do you use? Was it with a big file (like in my case it was 640MB).
I used to use filezilla, but it's always slow on my pc... just 2,5MB/s even on proper FTP servers with powerfull cpu's
Furthermore I have an nvidia gigabit ethernet card (which is quite high performance)
Member
Not sending ACK for every segment is already called delayed ACK. However what I've done for the sake of the test was forcing that ACK was sent even less frequent.
The trouble with searching a solution in non-router side is that:
1. Requires capable TCP stacks/OSs and e.g. the Linux version that I'm using does not work out of the box in that way and there is no information how to achieve that (the links don't have that)
Other boxes like media players are even less likely to support that kind of improvements.
2. For some protocols specialized programs (like winscp) may provide a bit of improvement, however that's not an option for Samba and for the rest of the protocols that use TCP (maybe in another Linux box).
Also my Linux PC (with a decent CPU/HDD) when doing a similar FTP copy test was only a bit faster, not reaching the 9 MB/s. So it's not just XP and the FTP that comes with it, but also other OSs have performance issue with TCP.
Student Computer Engineer
So you want to make the router to force the ACK to be send less frequent?
Samba performs really bad with the delayed Ack... under 100KB/s.2. For some protocols specialized programs (like winscp) may provide a bit of improvement, however that's not an option for Samba and for the rest of the protocols that use TCP (maybe in another Linux box).
Also my Linux PC (with a decent CPU/HDD) when doing a similar FTP copy test was only a bit faster, not reaching the 9 MB/s. So it's not just XP and the FTP that comes with it, but also other OSs have performance issue with TCP.
When I used ubuntu on 2 machines I was capable of reaching over 110MB/s with FTP and samba. I made 2 RAM disks (which is fairly easy in linux) on each pc to make sure that no read/write file delay was bottlenecking the benchmark.
Are you sure both systems had 1GB connections?
Member
No, the router has to live with what the remote end supports (and that's typically sending ACK for every second segment that is basic delayed ACK).
Where the router could be improved is reducing the per-packet overhead. It's bad that a few more ACKs (nothing but TCP header) can so badly ruin the TCP performance.
This would be quite big work if there is no kernel support already for it. However as this is the general trend because of CPU architectural changes how memory is accessed (like described in the paper I've linked earlier), there maybe such support or that kind of support can be expected sometime.
Something like LRO, but generalized to include also the ACK (LRO seems to be part of the 2.6.24 kernel, however due to binary Broadcom drivers that is missed with 2.6.22 kernel...).
Btw I'm sure that gigabit was used. NFS could not reach close to ~14MB/s otherwise.
Posting Permissions
