Differences between version 4 and predecessor to the previous major change of IPSecBenchmarks.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 4 | Last edited on Thursday, April 24, 2003 3:01:57 am | by JeeKay | Revert |
| Older page: | version 3 | Last edited on Wednesday, April 23, 2003 12:50:25 pm | by JeeKay | Revert |
@@ -10,4 +10,11 @@
I'm slightly at a loss as to why the load was so consistantly high but I guess that's the price you pay to have a process constantly wanting disk access.
You can see that enabling IP compression on the IPSec tunnel can lead to a dramatic speedup in transfer rates, at the cost of about 50% extra CPU cycles. Still - it was transferring at over twice what it would have been in clear text. This is probably almost entirely explained by the fact that the file I was transferring consisted entirely of zeroes. I will try with a more realistic file at some point.
+
+More realistic file stats, transfering 3DMark2001SE_330.exe between the same hosts:
+|<__Config__ |__Transfer Rate__|__CPU__|__Load__
+|<__IPSec__ |>778.30 kB/s |>25% | 0.3
+|<__IPSec Compress__ |>766.67 kB/S |>30% | 0.3
+
+The load has definitely decreased since I did the original numbers. I guess something else must have been doing something. We can also see that using a real file (ie one that isnt made up exclusively of zeros) takes a massive cut out of the compressed performance - in fairness, the .exe is already packed pretty tightly so there is probably nothing the IPSec compression could really do. If you have a lot of uncompressed traffic floating around (telnet, web, whatever) then it might help. For file transfers where the targets are usually already compressed, it makes no real difference and can actually negate any advantage, as has happened here.
