Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - ipconfigrenew

Pages: [1]
General Discussion / Re: Express version limitations
« on: February 09, 2017, 09:38:11 PM »
Oh, okay I guess I was really confused, but that finally cleared things up. Thank you.

General Discussion / Re: Express version limitations
« on: February 09, 2017, 07:05:55 PM »
Okay, I figured it out finally. The thing that confused me was there was apparently a difference in throughput between Express Free Unlicensed and Express Free Trial, even though there's no mention of this anywhere that I could find. Apparently unlicenced it is limited to 1/10 Up/Down and the trial is limited to 2/20 Up/Down.

General Discussion / Re: Express version limitations
« on: February 09, 2017, 04:27:50 PM »
I guess the main issue is the Up/Down throughput limit, which is only mentioned on the products page:

On that page it says the throughput limit is "Free up to 2/20". However, when I download and use the Free version, it says the throughput limit is "1/10" Up/Down.

The only mention of the throughput limit on the FAQ page just refers you to the products page, so it seems like the products page is where it needs to be corrected (or it means I'm not using the Free version correctly).

General Discussion / Express version limitations
« on: February 09, 2017, 03:06:38 PM »
There's conflicting information on the limitations of the Express version of Wanos. For starters I can't find detailed list anywhere, just bits of information scattered around. The closest I could find is the products page which just lists it's support for PtP only and 2/20 Up/Down speed limit:

However, when I try to use the Express version it's saying the limit is 1/10 Up/Down (v3.2.2 64-bit Express 1/10, ubuntu).

Can you confirm which is correct or if I'm missing something?

Deployment / Re: Hyper-V Replica
« on: April 09, 2015, 06:33:16 AM »
So I got the PLR status to come up, but as soon as I start a transfer of any kind it drops the PLR status.

Thu Apr  9 06:28:38 2015 : rsp_peer0 - State set to CLOSED
Thu Apr  9 06:28:38 2015 : rsp_peer0 - State set to SYN_SENT
Thu Apr  9 06:28:38 2015 : rsp_peer0 - State set to OPEN
Thu Apr  9 06:28:38 2015 : comp0 WComp Info - Clearing force stateless.
Thu Apr  9 06:29:17 2015 : rsp_peer0 RSP WARNING - Maximum retransmits reached, changing mode to server.
Thu Apr  9 06:29:17 2015 : hard setting force
Thu Apr  9 06:29:17 2015 : rsp_peer0 - State set to LISTEN

Deployment / Re: Hyper-V Replica
« on: April 08, 2015, 07:01:38 PM »
I didn't record the exact stats from WANOS wan0, but did glance at them at the time and they were in the similar (minus the overhead from the VPN, but that's been fairly consistent). I would redo the test, but this has actually been going on for days (did the uncompressed test before I actually posted the original question) and it would take a while to reproduce the exact test again.

I'm setting up a new lab environment to test this further in a more scientific approach. Going to take the VPN and routers out of the equation, and also going to make sure there is no other traffic besides the replica traffic.

As for PLR, my understanding was that it only helps in scenarios where there is packet loss, which as best I can tell there was none (and the WAN in this case was just a 100Mbps network connection between routers so I was in full control of that). Does PLR provide additional compression/dedup benefits? If so, how do I enable it?

I'm already liking this product so it won't be long before I pitch getting plus licenses, but for now I'll just stick with express for the experiments (I can always put a limiter at the Hyper-V level to keep the flow of traffic the same between all tests).

Troubleshooting / WANOS OVA/VHD differences
« on: April 08, 2015, 06:24:49 PM »
Been using WANOS 2.0.5 on ESXi and Hyper-V using the OVA and VHD downloads.

I noticed there are a significant number of differences between these images.
OVA Image:
Core 5.3
kernel 3.8.13-tinycore #2511 SMP Fri Oct 18 14:41:41 UTC 2013 i686 GNU/Linux
Max memory: 3113688 (~3,041MB)
Includes modules:
- vmxnet3/vmw_pvscsi (VMware drivers)
- hv_netvsc/hv_storvsc (Hyper-V drivers)

VHD Image:
Core 4.7.7
kernel 3.0.21-tinycore #3021 SMP Sat Feb 18 11:54:11 EET 2012 i686 GNU/Linux
Max memory: 4009116KB (~3,915MB)
Includes modules:
- vmxnet3/vmw_pvscsi (VMware drivers)
Does NOT include:
hv_netvsc/hv_storvsc (Hyper-V drivers)

So the VHD image seems very out of date, at least relative to the OVA image. It seems especially strange that the Hyper-V drivers are included in the OVA image but not in the VHD image (where it would actually be used). I'm going to try converting the OVA image to a VHD and running it on Hyper-V, but before I tried that I wanted to know if there was a specific reason for the differences.

Deployment / Re: Hyper-V Replica
« on: April 08, 2015, 04:54:03 PM »
Well, my tests so far have been inconclusive.

Obviously the optimization ratio is significantly better when compression is disabled on Hyper-V replication.

WANOS Optimization ratio:
Hyper-V Compression Disabled: 80-90%
Hyper-V Compression Enabled: 5-10%

However, the total WAN utilization (as in the amount data that was seen on WAN connection from beginning to end) seems to be slightly less with compression enabled in Hyper-V.

WAN usage (as reported by pfSense):
Hyper-V Compression Disabled: 25.9GB
Hyper-V Compression Enabled: 23.6GB

So far I've just been doing tests comparing the initial replication task (i.e. the first transfer). I've also been zeroing out the dedup datastore before starting the task to make sure it wasn't effecting the transfer. The transfer is over 40GB raw (it's a Linux Webserver VM that has a mix of compressible and incompressible data) so the datastore is reseeded well before it gets even halfway through the transfer. I'm now going to try and set up a good experiment for daily average usage and see what things look like after some simulated "days".

Also, the "responsiveness" seems better with Hyper-V compress enabled - this is hard to quantify, but the server seems to behave better. My guess is this has to do with the CPU utilization on the WANOS VM being lower when there is less data moving through it.

FYI, my setup:

Hyper-V source server <-> WANOS <-> pfSense <-> Router <-> Router <-> pfSense <-> WANOS <-> Hyper-V destination server

WANOS 2.0.5 (Hyper-V VHD image - 4vCPUs / 4GB memory)
pfSense 2.2.1 (Hyper-V VM - 1vCPU / 512MB memory)
OpenVPN site-to-site L3 routed tunnel (AES-128 / Adaptive compression Enabled)

Deployment / Hyper-V Replica
« on: April 07, 2015, 07:36:04 PM »
Been experimenting with WANOS and Hyper-V replica. Wanted to know if there is any standard guidance on whether or not to enable compression in the Hyper-V replica settings, or if it's better to disable compression in Hyper-V and let WANOS do all the compression.

Pages: [1]