Netdrive Testing

[Jon Pederson]

The netdrive caching looks like a really cool idea.  I wanted to test with an 86Box DOS VM but am struggling with capturing the results.  I came up with the following but it just loops.  I am more than just rusty using DOS batch files and could use some help (unlces there is a better way to capture the results).  

@echo off
cls
echo ===============================
echo mTCP NetDrive Benchmark Suite
echo ===============================

set LOG=C:\BENCH\LOGS\RESULT.TXT

echo. >> %LOG%
echo ===== TEST RUN %DATE% %TIME% ===== >> %LOG%

echo Running tests...

call TESTDL.BAT 1MB TEST1M.BIN
call TESTDL.BAT 10MB TEST10M.BIN
call TESTDL.BAT 100MB TEST100M.BIN

call TESTUL.BAT 1MB TEST1M.BIN
call TESTUL.BAT 10MB TEST10M.BIN
call TESTUL.BAT 100MB TEST100M.BIN

echo Tests complete.
echo Results saved to %LOG%
___
TESTDL.BAT (Download Test)

@echo off
set SIZE=%1
set FILE=%2
set LOG=C:\BENCH\LOGS\RESULT.TXT

echo.
echo Download Test %SIZE%

echo DL %SIZE% START %TIME% >> %LOG%
copy X:\FILES%FILE% C:\BENCH\TEMP.BIN > nul
echo DL %SIZE% END %TIME% >> %LOG%

del C:\BENCH\TEMP.BIN
___

TESTUL.BAT (Upload Test)

@echo off
set SIZE=%1
set FILE=%2
set LOG=C:\BENCH\LOGS\RESULT.TXT

echo.
echo Upload Test %SIZE%

echo UL %SIZE% START %TIME% >> %LOG%
copy C:\BENCH\FILES%FILE% X:\TEMP.BIN > nul
echo UL %SIZE% END %TIME% >> %LOG%

del X:\TEMP.BIN

____________

I can probably capture data on Windows host with Wireshark but wanted to also pull from the DOS side.  If this complicates things, please ignore.

Thanks,

Jon

[Michael Brutman]

Hi Jon,

I've used batch files to test it before, but DOS batch files are just kind of terrible to work with.

One big problem you are going to have there is that on a slower machine (80386 or slower) you are going to possibly see some inaccurate timing from DOS.  Heavy network traffic can cause the BIOS to miss the timer tick interrupt, thus making DOS time advance slower than it should.  It makes the benchmarks look faster.

I have a simple streaming read/write benchmark that gets around this by using the CMOS time; I'll try to get it posted in the next few days.  I also have a correctness test which opens a file and starts writing random blocks in the file.  But it also tracks the last thing written to each block so that it can do a verification pass at the end.  Timing doesn't matter on that test.

What I would recommend for now is just correctness testing.  Try copying files around from place to place, but do a comparison (COMP or FC) step afterwards to ensure the file copied correctly.  You can also add the /V switch to the copy command to test the write-with-verify option too.  Also, trying on a variety of machines is helpful.  I try to "mix it up" here but it is a large universe out there.  Testing against my server at brutman.com too helps, as the remote aspect introduces timing delays and packet drops that you might not get locally.

If you want to do performance testing, you'll need a utility that gets the time from the CMOS clock, or use a stopwatch for XT class machines.  The CMOS clock only has one second granularity so you have to do things like spin and wait for the second mark to change before starting a test, and then try to detect when the elapsed time as passed as quickly as possible to avoid running too long.  The code I'll post has all of that logic in it.

Mike

--
You received this message because you are subscribed to the Google Groups "mTCP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mtcp+uns...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mtcp/1bd631ed-4089-4c19-8aab-6f8d34911497n%40googlegroups.com.