Reply With QuoteIs there any way, via software, to have this router auto reboot at a set time each month?
Member
can confirm samba speeds... in general it seems I am achieving higher writing speeds than reading (ext3)... I have not tried NFS (never tried so don't know how) but I will test FTP speeds when at home
EDIT: FTP has the same behavior for me (proftpd, mac os x with cyberduck)
Last edited by Pedro83; 09-04-2010 at 00:01.
Junior Member
Is there any way, via software, to have this router auto reboot at a set time each month?
Last edited by rod178; 10-04-2010 at 20:04. Reason: typo
Senior Member
You can use CRONDOriginally Posted by rod178
Student Computer Engineer
quite right!You can use CROND
http://en.wikipedia.org/wiki/Cron
there is a part in wengi about cron: http://wl500g.info/showpost.php?p=60932&postcount=3
google a bit, and you'll find tons of information on how to shedule a task
Junior Member
Thanks guys. Cron it is! I remember looking at it briefly (Wengi post) a long time ago. Getting forgetful in my old age. Could not find anything doing a search on this forum. Used unsuitable key words I suppose.quite right!
http://en.wikipedia.org/wiki/Cron
there is a part in wengi about cron: http://wl500g.info/showpost.php?p=60932&postcount=3
google a bit, and you'll find tons of information on how to shedule a task
Senior Member
Can anyone connect wireless at 300MBit with OLEG FW? I only connect 130MBit and with DD-WRT i can get 300MBit.
Student Computer Engineer
you are aware that those speed indicators for wireless is usually mumbo jumbo?
Real stress tests will provide you with the real maximum bandwidth if your wlan card is fully compatible.
otherwise try playing around with these settings in the advanced wireless config:
Regulatory Mode
Enable WMM
Member
A few posts ago I've noted that NFS outperforms Samba by a factor of 2 (I can copy from the router over 12 MB/s using NFS with UDP) and writing speed is higher than reading.
Then Pedro83 described (confirmed) a similar behaviour (writing speed is higher than reading) with FTP and mac os x.
NFS is a good protocol but still it's just hard to believe that it's so much faster than other protocols.
Shortly after it occurred to me that NFS using TCP is also not performing too well.
All this points to the direction that there is some performance issue when TCP is used.
But what is it, any guesses?
I noticed using a capture that router advertises a window size of 4128 (all the time) and my PC either 1002 or 1313. Isn't that too small (for a gigabit ethernet)? Can that be the issue?
Student Computer Engineer
Samba is quite a difficult protocol, the data needs to be processed more when it's send, so the router is the bottleneck when sending.
Anyway, I've installed samba 3 which allows sometimes higher speeds compared to samba 2.
the difference between tcp and udp is small... udp is better for streaming since no check is done whether the packets have arrived for example.
At the moment the jumbo frames (the ones you're talking about) cannot be set to any other value due to the drivers
Does it matter much?
Several discussions state that bigger frames only increase something like... 5% over gigabit. but since the samba speeds don't even come close to 900Mbit/s it's quite a small change I guess
Member
I think you've missed the point. This is NOT about jumbo frame at all. I've understood from the first post from lly that there is a binary ethernet driver and anything that is forced to use that driver (basically all programs running in the router) won't use jumbo frames. This includes also NFS over whatever protocol.
However if you check my earlier post: http://wl500g.info/showpost.php?p=192140&postcount=293
when UDP is used as transport with NFS, files from USB device can be copied over 12 MB/s using NFS. It's a fact, you or anyone else can check it; all necessary information for that is in the post.
However when NFS is using TCP it does not perform so well. Samba (also using TCP) does not perform so well. FTP (also using TCP) does not perform so well.
I'm not sure if you wanted to say, that when TCP is used it performs worse than when UDP is used because of architectural reasons (beyond my competence), in that you might even be right.
Unfortunately I'm not familar enough with Samba (of for that matter even TCP), however have you ever checked this issue with tcdump or Wireshark?
I did. Samba reads 32K or 64K worth of data. In between that's pure TCP byte stream transfer.
So there is Samba read request in frame 12 in the below summary and that is acknowledged in frame 13. From that point on next frame where Samba has anything to do is frame 81/82 (Read Response and TCP ACK of that). Frame 83/84 is the next Samba Read Request.
So typically there are 45 TCP byte stream frames and 4 Samba frames (for 64K transfer). And there are around 22/23 TCP ACKs.
On a gigabit LAN having only the router and PC and no frame ever lost and retransmitted.
Based on the monitoring Samba reacts quickly; there is no time lag. TCP window size never changed.
So it's TCP that has the biggest influence to any file transfer based on TCP as transport.
So my question was pointing to TCP performance and if small window is really necessary and is ACKing of every second TCP byte stream transfer (~3K worth of data) is really needed or what is causing poor performance when TCP is used.
As if that question is answered and solution is found, both FTP and Samba file transfer may very well be over 10 MB/s (at least in the direction when USB read happens). Like NFS over UDP (which performs already now over 12 MB/s when USB is read). Without any CPU clock increase.
I may as well be wrong, and there can be indeed architectural reasons. Then this was only an interesting puzzle.
Code:1 0.000000 192.168.1.169 192.168.1.1 SMB Trans2 Request, QUERY_PATH_INFO, Query File All Info, Path: 2 0.001135 192.168.1.1 192.168.1.169 SMB Trans2 Response, QUERY_PATH_INFO 3 0.001169 192.168.1.169 192.168.1.1 TCP 59566 > microsoft-ds [ACK] Seq=81 Ack=139 Win=1002 Len=0 TSV=3124408 TSER=2722633 4 0.001700 192.168.1.169 192.168.1.1 SMB Trans2 Request, QUERY_PATH_INFO, Query File All Info, Path: 5 0.002316 192.168.1.1 192.168.1.169 SMB Trans2 Response, QUERY_PATH_INFO 6 0.004366 192.168.1.169 192.168.1.1 SMB Trans2 Request, QUERY_PATH_INFO, Query File All Info, Path: \SambaTest.img 7 0.005107 192.168.1.1 192.168.1.169 SMB Trans2 Response, QUERY_PATH_INFO 8 0.008625 192.168.1.169 192.168.1.1 SMB Trans2 Request, QUERY_PATH_INFO, Query File All Info, Path: \SambaTest.img 9 0.009401 192.168.1.1 192.168.1.169 SMB Trans2 Response, QUERY_PATH_INFO 10 0.009793 192.168.1.169 192.168.1.1 SMB Open AndX Request, Path: \SambaTest.img 11 0.011111 192.168.1.1 192.168.1.169 SMB Open AndX Response, FID: 0x2d66 12 0.012336 192.168.1.169 192.168.1.1 SMB Read AndX Request, FID: 0x2d66, 65534 bytes at offset 0 13 0.052415 192.168.1.1 192.168.1.169 TCP microsoft-ds > 59566 [ACK] Seq=674 Ack=536 Win=4128 Len=0 TSV=2722685 TSER=3124419 14 0.349123 192.168.1.1 192.168.1.169 TCP [TCP segment of a reassembled PDU] 15 0.349275 192.168.1.1 192.168.1.169 TCP [TCP segment of a reassembled PDU] 16 0.349294 192.168.1.169 192.168.1.1 TCP 59566 > microsoft-ds [ACK] Seq=536 Ack=3570 Win=1002 Len=0 TSV=3124756 TSER=2722981 17 0.349416 192.168.1.1 192.168.1.169 TCP [TCP segment of a reassembled PDU] 18 0.349773 192.168.1.1 192.168.1.169 TCP [TCP segment of a reassembled PDU] 19 0.349787 192.168.1.169 192.168.1.1 TCP 59566 > microsoft-ds [ACK] Seq=536 Ack=6466 Win=1002 Len=0 TSV=3124756 TSER=2722981 20 0.349854 192.168.1.1 192.168.1.169 TCP [TCP segment of a reassembled PDU] 21 0.349910 192.168.1.1 192.168.1.169 TCP [TCP segment of a reassembled PDU] 22 0.349923 192.168.1.169 192.168.1.1 TCP 59566 > microsoft-ds [ACK] Seq=536 Ack=9362 Win=1002 Len=0 TSV=3124756 TSER=2722982 23 0.350326 192.168.1.1 192.168.1.169 TCP [TCP segment of a reassembled PDU] 24 0.350454 192.168.1.1 192.168.1.169 TCP [TCP segment of a reassembled PDU] 25 0.350468 192.168.1.169 192.168.1.1 TCP 59566 > microsoft-ds [ACK] Seq=536 Ack=12258 Win=1002 Len=0 TSV=3124757 TSER=2722982 26 0.350523 192.168.1.1 192.168.1.169 TCP [TCP segment of a reassembled PDU] 27 0.350962 192.168.1.1 192.168.1.169 TCP [TCP segment of a reassembled PDU] 28 0.350975 192.168.1.169 192.168.1.1 TCP 59566 > microsoft-ds [ACK] Seq=536 Ack=15154 Win=1002 Len=0 TSV=3124757 TSER=2722983 29 0.351182 192.168.1.1 192.168.1.169 TCP [TCP segment of a reassembled PDU] 30 0.351301 192.168.1.1 192.168.1.169 TCP [TCP segment of a reassembled PDU] 31 0.351314 192.168.1.169 192.168.1.1 TCP 59566 > microsoft-ds [ACK] Seq=536 Ack=18050 Win=1002 Len=0 TSV=3124758 TSER=2722983 32 0.351532 192.168.1.1 192.168.1.169 TCP [TCP segment of a reassembled PDU] 33 0.351649 192.168.1.1 192.168.1.169 TCP [TCP segment of a reassembled PDU] 34 0.351662 192.168.1.169 192.168.1.1 TCP 59566 > microsoft-ds [ACK] Seq=536 Ack=20946 Win=1002 Len=0 TSV=3124758 TSER=2722983 35 0.351837 192.168.1.1 192.168.1.169 TCP [TCP segment of a reassembled PDU] 36 0.351892 192.168.1.1 192.168.1.169 TCP [TCP segment of a reassembled PDU] 37 0.351904 192.168.1.169 192.168.1.1 TCP 59566 > microsoft-ds [ACK] Seq=536 Ack=23842 Win=1002 Len=0 TSV=3124758 TSER=2722984 ... 79 0.356959 192.168.1.169 192.168.1.1 TCP 59566 > microsoft-ds [ACK] Seq=536 Ack=64386 Win=1307 Len=0 TSV=3124763 TSER=2722989 80 0.357051 192.168.1.1 192.168.1.169 TCP [TCP segment of a reassembled PDU] 81 0.357214 192.168.1.1 192.168.1.169 SMB Read AndX Response, FID: 0x2d66, 65534 bytes 82 0.357226 192.168.1.169 192.168.1.1 TCP 59566 > microsoft-ds [ACK] Seq=536 Ack=66271 Win=1313 Len=0 TSV=3124764 TSER=2722989 83 0.357654 192.168.1.169 192.168.1.1 SMB Read AndX Request, FID: 0x2d66, 32768 bytes at offset 65534 84 0.357872 192.168.1.1 192.168.1.169 TCP microsoft-ds > 59566 [ACK] Seq=66271 Ack=595 Win=4128 Len=0 TSV=2722990 TSER=3124764 85 0.358936 192.168.1.1 192.168.1.169 TCP [TCP segment of a reassembled PDU] 86 0.359053 192.168.1.1 192.168.1.169 TCP [TCP segment of a reassembled PDU] 87 0.359083 192.168.1.169 192.168.1.1 TCP 59566 > microsoft-ds [ACK] Seq=595 Ack=69167 Win=1313 Len=0 TSV=3124766 TSER=2722991 88 0.359163 192.168.1.1 192.168.1.169 TCP [TCP segment of a reassembled PDU] 89 0.359412 192.168.1.1 192.168.1.169 TCP [TCP segment of a reassembled PDU] 90 0.359441 192.168.1.169 192.168.1.1 TCP 59566 > microsoft-ds [ACK] Seq=595 Ack=72063 Win=1313 Len=0 TSV=3124766 TSER=2722991
Last edited by ecaddict; 22-04-2010 at 11:47. Reason: added Wireshark link
Senior Member
I agree with WPTE.
UDP is by definition unreliable, because it doesn't check the correct arrival of frames, but has less overhead than TCP.
Thus therefor UDP is faster.
UDP is generally good for showing video data, because it is fast and (some) frame loss is not so important.
(the video still looks good if a few details are missing)
If you use UDP for data transfer you might get corruption.
Student Computer Engineer
That's what I was trying to say yes
ah well well... ecaddict said that is not his point, yet I don't really get the point he's trying to make.
Anyway, to respond to ecaddict again: The architecture on how you send data is very important when it comes to performance.
SMB is a block protocol as the name suggests: "Server Message Block". It's like you're requesting to receive packages, and each time the mail man is bringing you these packages. Sometimes the mailman is a bit slower and the blocks keep coming in a bit slower...
Now the mailman will be slower when there is a limiting factor which causes a bottleneck... such as the slower cpu in the router!
FTP also supports block mode but is usually set to stream mode and allows the server to do nothing at all... instead the TCP protocol will do all the processing.
I'm not familiar with NFS, but I guess that's stream as well.
With samba3 I can upload sometimes up to 11MB/s so maybe it's a bit more optimized as well...
Is this more about the point you're trying to make?
Member
So are you saying that I should not use NFS over UDP because UDP is unreliable and I will get corrupted data?
Sorry, but I cannot agree on that. UDP has checksum (like TCP) and there are protocol layers above the transport that can make it reliable. After all IP does not guarantee that your packets will arrive and yet TCP is able to make it reliable. Why protocol layers above UDP (in particular NFS) could not do that?
So in my view (and experience) nothing is wrong with NFS over UDP. In the LAN environment where I use it, it works perfectly and much faster than Samba (at least in router -> PC direction).
Probably nothing is wrong with Samba either. Just there is something in the TCP stack (it may very well be configuration) that prevents TCP (or protocols using it) performing optimal.
***
Back to my capture: Checking TCP a bit more I realized that my capture is incomplete. Since the window scaling option is only in SYN message (used only at connection setup) and that's missing from the capture, I can guess only the scaling.
Having a full 10s capture (not just what I've extracted) I could find that in fact my PC changes the windows size correctly.
Also checking RFC1122, the number of ACKs may not be that excessive as I've initially thought (so delayed ACK seems to be in use, however I have not yet figured out how to reduce the number of ACKs from my Linux PC just to check what it changes).
But it's still so hard to believe (at least to me) that writing over the network to the USB HDD attached to the router is faster than reading from it and there is nothing wrong it. Writing requires extra clock cycles e.g. due to journaling.
I do understand that e.g. checksum calculation can be delegated to NIC in PC environment and that is probably not possible where everything is in a SoC. It might be that checksum calculation is heavier than checking (one possible explanation to reverse asymmetry).
But yet, can that explain that NFS over UDP outperforms other protocols (including NFS over TCP) that use TCP by almost a factor of 2?
I at least don't have any explanation.
Member
That's not true. Just as I've mentioned earlier Samba reacts quite quickly those requests. Checking a bigger chunk of the capture that I could paste here, on average it takes less than 2ms for the first frame of the requested data after the request (Read AndX Request) to appear. Thus for 64K worth of data there is only 2ms Samba overhead.It's like you're requesting to receive packages, and each time the mail man is bringing you these packages. Sometimes the mailman is a bit slower and the blocks keep coming in a bit slower...
And how long does it take for Samba/TCP to transfer the 64K data (you can check this from my earlier post)? ~8ms.
Thus Samba reaction overhead (alone) would create a ~31MB/s limit
Bulk data sending creates a ~8MB/s limit (note: this includes everything, e.g. taking data probably from cache, not just TCP so TCP bandwidth is probably better measured with some tool like iperf and I'm planning to do just that).
Do you think that it's normal that "upload" is so much faster than download even though upload requires extra disk operation (extra CPU cycles)?With samba3 I can upload sometimes up to 11MB/s so maybe it's a bit more optimized as well...
Is this more about the point you're trying to make?
Student Computer Engineer
Okey to put everything together:
UDP checksums are optional and are not always send or checked. TCP must have checksums and MUST be checked.
Furthermore, TCP sends back a response if the package actually arrived! this is very important on unstable connections.
UDP somewhat is faster than TCP, definitely when a host is very busy and does not want any responses on received packages. (that's what's make udp faster generally).
As you may, or may not know: communication via tcp or udp can be roughly separated over 2 levels: software level (like samba deamon), kernel level (drivers, tcp & udp implementations etc). Data processing on software level is rather slow compared to data processing on kernel level, which will be important in what I'm about to say.
Back to block and streams.
Yes SMB has little delay, still it's very dependent on this delay since it's block protocols. Any delay can be enough to limit the throughput... even usb chips or slow responding processes.
Also block protocols require quite a lot of processing on the sending side on software level. The bottleneck is the router, since I guess your pc is faster.
You can say it requires only a little milliseconds of time... but we computer engineers don't count in milliseconds, nano seconds more often
FTP usually uses streams (as I've told before) which doesn't need that much feedback. Also most of the data processing is done on kernel level and thus does not require much cpu and is faster. This allows the sending side a greater speed.
So yes, I think it's obvious why it's slower, even when I don't really like it
If anyone says I'm not entirely correct about all of this, it's ok, I didn't have had that much lessons on things like these, but this is all I got from it.
Posting Permissions
