SoftEther Client Performance on MIPS

[dniasoff]

Hi,

I have compiled SoftEther from source to run on a ubiquiti edgerouter lite (running a custom version of Vyatta/Debian Squeeze).

It comes with Dual-Core 500 MHz, MIPS64 & 512 MB Ram.

I am trying to benchmark performance to see what the maximum speed I can get out of this hardware.

Using the traffic test tool I am seeing
Average Throughput in Download Direction | 41,905,631 bps| 41.91 Mbps
Average Throughput in Upload Direction | 6,143,261 bps| 6.14 Mbps
Total Average Throughput | 48,048,892 bps| 48.05 Mbps

which mirrors what I am seeing in real life.

Here is what I am getting without going through the VPN.

Average Throughput in Download Direction | 72,846,813 bps| 72.85 Mbps
Average Throughput in Upload Direction | 16,304,005 bps| 16.30 Mbps
Total Average Throughput | 89,150,818 bps| 89.15 Mbp

So VPN slows down performance to around 50% of actual throughput (I guess due to CPU limitations?)

I have disabled encryption and have configured 8 sessions otherwise all is default.

Can I tweak it get any better performance? I see that it only seems to be using 1 core and this is a dual core device.

For the record OpenVpn gets around 20MB on the same device using a similar setup.

Thanks

Daniel

[dniasoff]

Would bridge mode be more efficient as it doesn't have to read/alter packet headers?

[thisjun]

How did you test?
Did you use SoftEther VPN Server ? Client?
Please tell me your network environment etc.

> Would bridge mode be more efficient as it doesn't have to read/alter packet headers?

Reason is wrong. However, a bridge is faster than a client.

[dniasoff]

I used both SoftEther client and server.

Server is on a fast multi-core Intel processor and able to cope with high throughput.

Client is on mips router and the client's throughput is slow due to 500 Mhz processor

Using native SoftEther protocol with encryption disabled.

Thanks

Daniel

[jassing]

I, too, experience about 50% reduction in simple thruput; with disabled encryption, otherwise, all default settings. Often times, dropping near dial up speeds....

[thisjun]

MIPS and SoftEther have bad chemistry.
SoftEther is slowdown when use with MIPS. I don't know why.....

[colapig]

Which kind of CPU would be better for softether?

[BoredAus]

I had a look back at what the OP said, some of the issues are pretty evident.

dniasoff wrote:
> I have compiled SoftEther from source to run on a ubiquiti edgerouter lite (running
> a custom version of Vyatta/Debian Squeeze).
>
> It comes with Dual-Core 500 MHz, MIPS64 & 512 MB Ram.
>

At this point in time, running linux one can easily pipe up the likes of 'top' to see the load on the processor as well as seeing if perhaps a software is either single threaded or multi-threaded.

dniasoff wrote:
> So VPN slows down performance to around 50% of actual throughput (I guess due to
> CPU limitations?)
>
> I have disabled encryption and have configured 8 sessions otherwise all is default.
>
> Can I tweak it get any better performance? I see that it only seems to be using 1
> core and this is a dual core device.
>

Here the case in the last paragraph is evident, if say 'top' revealed that the total amount of CPU usage is around 50%, that is probably why you are getting half the performance output. This may mean that either the program is incapable of being multi-threaded or is built to be single threaded. There are a fair amount of programs in general for instance whom are built single threaded as multi threading was either un-necessary or difficult to create. The old trick was to overclock CPU so that more performance from single threaded programs could be yielded. In the case of embedded appliances like routers, overclocking is probably not feasible neither is it ideal.

You need to find out how many instances of that SoftEther VPN is running on the Edgerouter lite. If there is only one instance during heavy network activity and when top reveals 50% usage that usually means single threading. A more fancier program 'htop' can also reveal single threaded programs when they are under load, usually you would see a core/CPU be used up to 100% then it would alternate between cores (at least for newer linux kernels).

Theoretically, you should be able to squeeze out up to 100% of the actual throughput provided that the program is actually multi-threaded and that CPU loads indicate 100% usage during heavy network activity. Otherwise, for programs that are capable of running only in single threaded mode are determined usually by the speed of the processor. That is, the faster the CPU (> 500MHz) the more actual throughput could be achieved in theory.

dniasoff wrote:
> For the record OpenVpn gets around 20MB on the same device using a similar setup.
>

I haven't thoroughly tested out OpenVPN though it is granted that OpenVPN has been around for awhile and has seen many more contributions/ports compared to SoftEther VPN. It is basically a given that OpenVPN would outperform in scenarios such as running on some fancy CPU architecture. Also at that chances are that OpenVPN in that case would be multi-threaded if it is capable of using all the CPU% under heavy network usage.

Given the fact that SoftEther VPN was primarily built for windows users, their CPU are generally more capable of reaching faster throughput speeds as system requirements for windows OS are generally high. I personally believe this is not really the issue with using MIPS architecture in this case but that the program is not multi-threaded and it is more of a speed issue on the CPU itself that is inhibiting the performance. Besides, fundamental differences between CPU architecture is evident, Intel processors being CISC versus the likes of MIPS being RISC. A RISC processor has been proven time and time again (e.g. in the case of smartphones) that they can compete almost on the same level as a CISC processor that is powering desktops/laptops/nettops/etc even though they generally have a much lower clock rate. Case in point here is that the software is optimised to use the set of CPU flags that the CPU is capable of using without having to emulate it. RISC has less cflags but that is why it is generally faster provided that the software is optimised for it.

Ultimately I could be wrong here, though ideally there needs to be more programmers that are contributing to this project - specifically porting it to other platforms.

[thisjun]

I recommend an Intel CPU with rich cache memory. ARM is also acceptable.