Page 9 of 19 FirstFirst ... 7891011 ... LastLast
Results 121 to 135 of 283

Thread: alpha rt-n firmware releases

  1. #121
    Join Date
    Nov 2006
    Location
    Russia, Moscow
    Posts
    3,640
    Quote Originally Posted by ecaddict View Post
    I've checked this NFS max block size issue a bit more and maybe I've found the cause of why 16K block size is used.
    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 20:13.

  2. #122
    Quote Originally Posted by lly View Post
    Tell me your opinion - 32K will be enough?
    Yes, for UDP 32K is OK, but for (because of) TCP 64K is preferred.

  3. #123
    Join Date
    Nov 2006
    Location
    Russia, Moscow
    Posts
    3,640
    Quote Originally Posted by ecaddict View Post
    Yes, for UDP 32K is OK, but for (because of) TCP 64K is preferred.
    Well, I will do like:
    128M RAM - 64K
    32M RAM - 32K (like in 2.4 based FW)

  4. #124
    Quote Originally Posted by lly View Post
    Well, I will do like:
    128M RAM - 64K
    32M RAM - 32K (like in 2.4 based FW)
    OK, thanks.

  5. #125
    Join Date
    Nov 2006
    Location
    Russia, Moscow
    Posts
    3,640
    Quote Originally Posted by ecaddict View Post
    OK, thanks.
    Please try r1633

  6. #126
    Quote Originally Posted by lly View Post
    Please try r1633
    It works, thank you for the good correction.

  7. #127
    I've measured NFS copy speed with 32K block size (USB HDD using ext3 filesystem).
    This is at 480 MHz.
    Name:  NFS_480.jpg
Views: 657
Size:  135.8 KB

    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...

  8. #128
    Join Date
    Dec 2007
    Location
    The Netherlands - Eindhoven
    Posts
    1,767
    Quote Originally Posted by ecaddict View Post
    If TCP speed could be fixed somehow...
    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 21:05.

  9. #129

    TCP performance - high per-packet overhead

    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:
    Name:  AckFreq2.jpg
Views: 637
Size:  64.5 KB

    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):
    Name:  AckFreq18.jpg
Views: 619
Size:  73.5 KB

    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.

  10. #130
    Join Date
    Dec 2007
    Location
    The Netherlands - Eindhoven
    Posts
    1,767
    Quote Originally Posted by ecaddict View Post
    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.
    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 23:34.

  11. #131
    Quote Originally Posted by wpte View Post
    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)
    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.

    Quote Originally Posted by wpte View Post
    For FTP it works great, 11MB/s with ease.
    What OS/SW do you use? Was it with a big file (like in my case it was 640MB).

  12. #132
    Join Date
    Dec 2007
    Location
    The Netherlands - Eindhoven
    Posts
    1,767
    Quote Originally Posted by ecaddict View Post
    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?
    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.

    What OS/SW do you use? Was it with a big file (like in my case it was 640MB).
    Windows 7 ultimate 64bit and winscp as FTP client as I said.
    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)

  13. #133
    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.

  14. #134
    Join Date
    Dec 2007
    Location
    The Netherlands - Eindhoven
    Posts
    1,767
    Quote Originally Posted by ecaddict View Post
    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.
    So you want to make the router to force the ACK to be send less frequent?


    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.
    Samba performs really bad with the delayed Ack... under 100KB/s.
    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?

  15. #135
    Quote Originally Posted by wpte View Post
    So you want to make the router to force the ACK to be send less frequent?
    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.

Page 9 of 19 FirstFirst ... 7891011 ... LastLast

Similar Threads

  1. Essential Firmware Questions
    By vladk2k in forum WL-500gP Firmware Discussion
    Replies: 9
    Last Post: 14-10-2009, 12:10
  2. wl500gP v1 not booting after successfull flash of custom firmware
    By nocturne.op.15 in forum WL-500gP Firmware Discussion
    Replies: 6
    Last Post: 13-07-2008, 02:28
  3. New Oleg firmware 1.9.2.7-9 problems?
    By wpte in forum WL-500gP Firmware Discussion
    Replies: 11
    Last Post: 18-04-2008, 00:34
  4. Visit WL-500g Firmware Releases forum
    By Oleg in forum WL-550gE Firmware Discussion
    Replies: 7
    Last Post: 18-09-2006, 11:22
  5. Flashing Oleg's Firmware in WL HDD
    By hugo in forum WL-HDD Custom Development
    Replies: 29
    Last Post: 21-10-2004, 15:55

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •