Issue: Full data transfer rate is only achieved with manipulation.

Server 1 is scheduled nightly to wol Server 2, transfer files and then hibernate Server 2
The NeoRouter GUI is not used.
The sequence of events and outcomes:


* A script stops/starts NRClientService on Server 1
* Server 1 sends a wake-on-lan request (through a Python script) to server 2
* Server 2 wakes up and a script stops/starts NRClientService on Server 2 because sleeping seems to disrupt the connection
* Server 1 starts to transfer files to server 2
* Transfer rate is 25% to 29% of the 1Mbps connection potential

* Stopping then starting NRClientService on Server 1 causes 100% utilization of the 1mb connection potential.
* Stopping then starting NRClientService on Server 2 has no effect on the 1mb connection potential.
* NRClient must be stopped and then restarted after the data transfer has begun or it won't change the transfer rate.

That 100% utilization stays until Server 2 goes to sleep.

I put Server 2 to sleep because it only runs for about 5 hours on an average day. It is a backup server.

NeoRouter Free Version 1.3.0.2526 [1] for clients
NeoRouter Free Server for Tomato Firmware Version: 1.3.0 Build: 2526 on Linksys WRT54G/GS/GL
Server 1 is SBS2003 SP2, and Server 2 is Server2003 S2.
Server 1 is a primary server, Server 2 is a remote backup server updated nightly.

Thank you for your great work.

Hi OregonJohn,

If you are concerned about the bandwidth usage, I'd suggest you to investigate the data sent/received to/from server1 while nrservice stop/start.

I have some thoughts coming in my mind and hope it helps.

1.The latest version of NR client does not support traffic control. It means that it tries to use as much bandwidth as possible, like any tcp/ip application, while trasfering data. It also means that NR client shares the bandwidth with other network applications and won't take them all.

2.It may be related to the machine speed and network bandwidth. If your computer is fast, it may process packages easily and tries to send more data. The rate will become to a proper value under the tcp/ip protocol control.

3.It may be realted to the total volumn of the data, that the machine tries to send. Basically, when nrservice started, a new virtual adapter gets activated. At this moment, a lot of broadcast packets will be sent out over the virtual network. For example, NetBIOS/SMB, IPV6 and so on. After a while, it goes back to normal. As your server1 is a primary server, it may send a lot.

4.It may be related to how many NR clients connected to server1. When a connection between two NR clients gets broken, NR client won't re-build the connection until need.

5.It may be related to the application you use to transfer data and how do you transfer data (files sent from server1 to server2). Generally the upstream rate would be different from (less than) downstream rate, though your provider says your network is 1mb.

And there are several workaround.
1.Use a third party traffic control software to shape traffic and limit the transfer rate
2.With NR Pro, you can choose to drop the useless packages, such as broadcast packets, as you just want to transfer files.
3.Choose an efficient file transfer software, such as ftp.

Thanks,
KevinZ - NeoRouter team

Thanks for the reply KevinZ, but that didn't address the problem I was having.

I did solve my problem with a scripted work-around. Here's what I did and maybe you can identify where the issue is from my work-around.

Basic issue: I'm using Rsync to backup to a remote copy of our server. I have a script that runs the various routines for Rsync, but first it makes sure there is an existing NeoRouter connection to the remote server. That script also runs a hibernate script when it is done with the backup. I wasn't getting my full 1Mbps transfer rate after returning from hibernation.

This is my solution:

First I edited my "hibernate.bat" for server 1 that starts hibernating the remote server 2 so hibernation now waits 60 seconds so the script can stop the NRClientService on server 2. This requires Sysinternal's psshutdown and psexec http://technet.microsoft.com/en-us/sysinternals/bb842062

hibernate.bat
=========
REM hibernate remote server after 60 seconds and stop NRClientService
REM script continues to work on remote server even though
REM NRClientService is no longer working

psshutdown.exe \\10.0.0.2 -h -t 60
psexec.exe \\10.0.0.2 cmd /c "net stop NRClientService"

REM end of hibernate.bat
=========

Then for server 2 I created an AutoIt3 script, compiled to be an executable and scheduled to run at system start up, that determines if server 2 has been asleep (script continues through hibernation and sees that there is a significant time difference from having been asleep) and if so then the script starts NRClientServer. This requires AutoIt3 which is best edited with SciTE4AutoIt3 which is also available at http://www.autoitscript.com/site/autoit/

Within 30 seconds of server 2 coming out of hibernation NRClientService gets started. Remember that NRClientService was stopped just before hibernation.

restart_neorouter.au3 (built to restart_neorouter.exe)
=========
; AutoIT3 script scheduled to run at system startup
; Check if computer has been asleep
; Start NRClient service if so

While 1

$begin = TimerInit()
sleep(30000)
$dif = TimerDiff($begin)
If $dif > 30000 Then
RunWait ('net start "NRClientService"',"", @SW_HIDE)
EndIf

WEnd

; End of restart_neorouter.au3
=========

It might be made simpler, but this works perfectly. For several days now I've had a full 1Mbps transfer during my backup routine. Before I was only getting approx. 250Mbps because something happens to NRClientService when it returns from hibernation.

Strangely, just stopping and restarting NRClientService on the hibernated computer won't solve the problem. Stopping and restarting NRClientService on server 1 while a file transfer was taking place did work. I experimented and found that stopping it on server 1 before hibernation then restarting once out of hibernation did work, so I wrote the scripts to make that happen.

Thanks. Sorry if it's all a bit long-winded.