Yes, you found right place, thank you for investigations!Quote:
Originally Posted by ecaddict
Tell me your opinion - 32K will be enough?
Printable View
Yes, you found right place, thank you for investigations!Quote:
Originally Posted by ecaddict
Tell me your opinion - 32K will be enough?
Yes, for UDP 32K is OK, but for (because of) TCP 64K is preferred.Quote:
Originally Posted by lly
Well, I will do like:Quote:
Originally Posted by ecaddict
128M RAM - 64K
32M RAM - 32K (like in 2.4 based FW)
OK, thanks.Quote:
Originally Posted by lly
Please try r1633Quote:
Originally Posted by ecaddict
It works, thank you for the good correction.Quote:
Originally Posted by lly
I've measured NFS copy speed with 32K block size (USB HDD using ext3 filesystem).
This is at 480 MHz.
Attachment 6526
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...
I have the E3000 GPL sources, so maybe we have better drivers now:DQuote:
Originally Posted by ecaddict
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 :D
now lets hope these drivers work for our router as well... even when the E3000 has a 5GHz radio as well
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:
Attachment 6568
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):
Attachment 6569
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.
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)Quote:
Originally Posted by ecaddict
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.
Unfortunately not my Linux version that I regularly use (I've posted captures already that show that every second packet is acknowledged).Quote:
Originally Posted by wpte
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).Quote:
Originally Posted by wpte
Well it should have that...Quote:
Originally Posted by ecaddict
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.Quote:
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:p
Furthermore I have an nvidia gigabit ethernet card (which is quite high performance:))
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.Quote:
Originally Posted by wpte
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.
So you want to make the router to force the ACK to be send less frequent?Quote:
Originally Posted by ecaddict
Samba performs really bad with the delayed Ack... under 100KB/s.Quote:
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?:confused:
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).Quote:
Originally Posted by wpte
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.
Anyone ever had the problem that the wifi goes down?
It happened to me twice now.
once it kept broadcasting but didn't respond to any connection requests.
the second time right now it didn't broadcasted at all, while according to the router, the network was up.
I did wl down and wl up, after that it worked again:confused:
What is your firmware version?
1.9.2.7-rtn-r1633Quote:
Originally Posted by necrolatry
my friend has similair problems since R1484
http://code.google.com/p/wl500g/source/detail?r=1484
it's not that frequent, but now and then, it just stops working:confused:
I don't observe such behavior on my RT-N16, probably I never load WiFi as much as you. Anyway, WiFi driver itself wasn't modified, only many patches against kernel.
It will be best, if you can trace starting on which revision problem appears.
I know only the settings changed, and it does deliver a slightly better performance, at least better compatibility with older wifi products:pQuote:
Originally Posted by lly
I do have a wireless ethernet bridge (my old wl500w) which does try to keep the link alive, but it's nothing like a high load.
As I said, its since that revision I had those problems, just like a friend of mine:confused:
I'm not sure... can you advice me some commands I should run when it happens? to check the status etc? "wl status" probably, but maybe some advanced things I'm not aware of:p
In other words, you want to say me that r1478 is OK, and r1484 has problems?
sorry to disappoint you, but yes, I guess so:oQuote:
Originally Posted by lly
I Hate to bring things up like that:p
I mean, I don't think I configured it wrong: just everything on auto basicly, 40mhz, wpa-personal aes and wmm enabled.
I enabled wmm since it tripled the max speed on my wireless ethernet bridge:)
Maybe it's better to analyze it before jumping into actions? lly, what would you like to know when wifi stops working?:p
I will agree with you, in case of I have some debugging instruments.Quote:
Originally Posted by wpte
Unfortunately, we can use only ioctl calls (wl binary).
First of all, check that are nas + eapd processes are in memory. Second, issue "wl status" - maybe is shows something. Also try to set wl0_obss_coex=0 - it is major change in r1484 commit
it just happened again this morning.Quote:
Originally Posted by lly
wl status:
eapd and nas are running.Code:SSID: "*******"
Mode: Managed RSSI: 0 dBm noise: -76 dBm Channel: 4
BSSID: *************** Capability: ESS ShortSlot
Supported Rates: [ 1(b) 2(b) 5.5(b) 6 9 11(b) 12 18 24 36 48 54 ]
802.11N Capable:
Chanspec: 2.4GHz channel 4 40MHz (0x2e04)
Control channel: 6
802.11N Capabilities:
Supported MCS : [ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 32 ]
wlan led is on, but doesn't blink when I try to connect.
seems to be happening overnight all the time:confused:
Unfortunately wl diagnostic is very poor, I apologize that "wl isup" also will return 1. In case of we suspect r1484 commit, can you revert it on your side for tests?Quote:
Originally Posted by wpte
I haven't tried "wl0_obss_coex=0" yet, but that's pretty much the same as R1448 I guess.Quote:
Originally Posted by lly
Anyway, my router was running for over 9 days, so maybe I need to wait that long again before it happens:p
I have an active laptop cooler under my router, so everything of this shouldn't happen because of the overheating in the summer
I wanted to try out of switching on GSO has some good impact to TCP performance but noticed that ethtool does not exist for the router. Is it really so?
So my plan was something like:
I've checked in include/linux/netdevice.h that GSO flag exists (NETIF_F_GSO):Code:ethtool -K eth0 gso on
and this should work without ethernet driver/HW support.Code:/* Net device features */
unsigned long features;
#define NETIF_F_SG 1 /* Scatter/gather IO. */
#define NETIF_F_IP_CSUM 2 /* Can checksum only TCP/UDP over IPv4. */
#define NETIF_F_NO_CSUM 4 /* Does not require checksum. F.e. loopack. */
#define NETIF_F_HW_CSUM 8 /* Can checksum all the packets. */
#define NETIF_F_HIGHDMA 32 /* Can DMA to high memory. */
#define NETIF_F_FRAGLIST 64 /* Scatter/gather IO. */
#define NETIF_F_HW_VLAN_TX 128 /* Transmit VLAN hw acceleration */
#define NETIF_F_HW_VLAN_RX 256 /* Receive VLAN hw acceleration */
#define NETIF_F_HW_VLAN_FILTER 512 /* Receive filtering on VLAN */
#define NETIF_F_VLAN_CHALLENGED 1024 /* Device cannot handle VLAN packets */
#define NETIF_F_GSO 2048 /* Enable software GSO. */
#define NETIF_F_LLTX 4096 /* LockLess TX */
Also ethtool_set_gso function exists in net/core/ethtool.c
Is there any way to switch it on without writing code for ioctl call?
It (ethtool) simply don't included into bundle yet. You can compile it yourself at this time, with toolchain published. Or wait some time, we will include it in future.Quote:
Originally Posted by ecaddict
Seems like ethtool 2.6.34 doesn't work on rt-n16Quote:
Originally Posted by lly
it works only for br0Code:[admin@router-n /tmp]$ ./ethtool -K eth0 gso on
Cannot set device generic segmentation offload settings: Invalid argument
[admin@router-n /tmp]$ ./ethtool -K vlan2 gso on
Cannot set device generic segmentation offload settings: Invalid argument
[admin@router-n /tmp]$ ./ethtool -k vlan2
Offload parameters for vlan2:
Cannot get device rx csum settings: Invalid argument
Cannot get device tx csum settings: Invalid argument
Cannot get device scatter-gather settings: Invalid argument
Cannot get device tcp segmentation offload settings: Invalid argument
Cannot get device udp large send offload settings: Invalid argument
Cannot get device generic segmentation offload settings: Invalid argument
Cannot get device flags: Invalid argument
Cannot get device GRO settings: Invalid argument
no offload info available
so, ethtool doesn't support broadcom eth devicesCode:[admin@router-n /tmp]$ ./ethtool -K br0 gso on
[admin@router-n /tmp]$ ./ethtool -k br0
Offload parameters for br0:
Cannot get device rx csum settings: Operation not supported
Cannot get device udp large send offload settings: Operation not supported
Cannot get device flags: Operation not supported
Cannot get device GRO settings: Operation not supported
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off
ntuple-filters: off
receive-hashing: off
Seems to be, et driver missing most modern ethtool ioctl's :(Quote:
Originally Posted by theMIROn
Well, I'll try to add support for et driver/Quote:
Originally Posted by lly
UPD: et driver exports tcp segmentation, udp large send and scatter-gather offloads...
maybe too modern ethtool I've used
Currently, et driver supports only commands below:Quote:
Originally Posted by theMIROn
Moreover, it uses an old 2.4 syntax rather than SET_ETHTOOL_OPS() macros, even turned off by default in Broadcom SDK.Code:ETHTOOL_GSET
ETHTOOL_SSET
ETHTOOL_GDRVINFO
P.S. If you done it, you can sell code back to Broadcom :D
Yep, funny.Quote:
Originally Posted by lly
So, there're no ways to manipulate offload for now.
As far as I know GSO should not depend on the ethernet driver. The basic idea is that protocol layers don't handle segments (and memory buffers) separately (it's just SW side improvement). When 10K segments needs to be handled per second (due to 1500 bytes MTU) even that matters a lot (if it can be reduced a bit). I don't know if Broadcom managed to break that.Quote:
Originally Posted by theMIROn
The most important question related to the ethernet driver if it has so poor support for various offload features because of the old kernel version or because of the HW's inability. Too bad that there is no documentation for this...
It's a bit weird that Broadcom produced a driver for a kernel version that pre-dates the announcement of the chip-set by one year and has not released anything new since that. Is it really so?
Sorry, I have to read documentation much deeper to agree or disagree with you.Quote:
Originally Posted by ecaddict
Unfortunately, Broadcom tries to support single SDK for both 2.4.20 & 2.6.22 kernel versions. Due to very limited features of both obsolete kernels and since Broadcom don't want (as I can understand) to migrate to newer kernels :mad:, they simply don't implement future features.Quote:
It's a bit weird that Broadcom produced a driver for a kernel version that pre-dates the announcement of the chip-set by one year and has not released anything new since that. Is it really so?
P.S. I suspect, that due to "crisis" in top managers brains, SDK development was moved to cheaper place with cheaper programmers. As result, quality of code ...
It seems that /net/core/dev.c has code for this in dev_hard_start_xmit()/dev_queue_xmit(). Having driver support would/could though probably save some copying.
I wonder if it can be cheaper than Linux community maintaining the drivers' code for free. Of course it would need a bit broader opening towards Linux than just releasing the code/doc. of a few selected drivers.Quote:
Originally Posted by lly
that is probably the best investment a company can ever do...Quote:
Originally Posted by ecaddict
the only problem is: other people will get to know how a specific technology works, and protecting those technologies... well, they've probably spend a lot of money on that already:rolleyes:
In the end, it's pretty much the same as the movie "the italian job", the mini's (the car) where not sponsored by BMC (the manufacturer), since they didn't understand what a great marketing it would be.
nowadays a lot of cars get sponsored by the companies that produce them, like in the movie "I robot" with the audi.
I hope a similar shift will happen in computer land soon, and that other companies will open up their code a bit.
it's inevitable that linux will grow bigger:)
Hey everyone.
I'm linux noobie and need some help. :)
Is it possible to mount a NTFS partition with write support? If it's possible, how? System log tells me that NTFS partition is mounted read-only.
My harddisk has 4 different partitions: optware (ext3), swap, data (ext3) and data (ntfs).
The second question is that how can I enable swap? or is it even needed (will the router benefit from it)?
If anyone is kind enough to help me, I really need clear instructions what to do.
Thank's for great FW. I think it's a best of all. Before I was using Tomato from Teddy bear, but p2p download was allways too slow. Now, with this FW, DL is allways at full speed. Thank's again and keep on good work.
Can anyone confirmed, that WPA2 does not working yet. Because I think it is working for me correctly or it is some mistake.