Batch file with built-in stopwatch?

mavalpha

[H]F Junkie
Joined
Jan 3, 2005
Messages
10,448
Need to set up an experiment for my Stats class, I've decided I'll compare the real-world differences between 802.11b, 802.11g and 802.11n (as well as perhaps a wired connection at 10mbps, 10/100 and gigabit, maybe even addressing the difference between half- and full-duplex). The only changes will be made in the network hardware settings- it's the same computers, the same NICs, and the same routers/switches/access points in all cases, with firmware enabling and disabling the different modes.

The plan is to copy the same files over the network multiples times (both large and small files), comparing average bandwidth for the duration of the copy, as well as network-related latency. I know that C++ has a header file (ctime.h?) with a stopwatch function, but I'd prefer to stick to a batch file for the sake of giving my professor an easy-to-follow printout of the source code.

Any help is greatly appreciated, can probably even throw a few bucks via PayPal at a clean implementation.
 
"Help" is one thing, which is what can be offered here. But the "throw a few bucks via PayPal" comment just smells of requesting someone to do your project for you.

Putting the Paypal comment aside, we're probably going to need some info. Disregarding the mention of anything language specific, thoughts like this come to mind:
- Custom app, batch, script, etc.?
- User operated stopwatch while copy/paste files between two machines
- Questions about what operating system(s) would be used
- Transfer protocol needed/required
- What you can create within the allotted time-frame for the project

Alot of this comes down to spec documentation. Which is not only important for creating this, but also for others to have a clear set of instructions to reproduce your work. I think you'll get some worthwhile suggestions as soon as you post your spec documentation.
 
-Windows 7 x64 on my desktop, Vista (probably x86) on the "server."
-Ideal interface is minimal. Literally, "point target folder containing file(s) at app, point app at network destination." Output doesn't need to be much, at most a per-file log of latency in initializing copy, byte-size of file, and average bandwidth throughout transfer process.
-Language can be anything. I'd prefer BATCH files for easy explanation to the professor, but I know enough C++ and VB that I could decipher almost anything else; I just can't write my own in those languages.
-Transfer protocol is standard Windows File Explorer navigation- don't know what specific protocols that entails. :shrug: Entire network is in my house (obviously), so there is no tunneling or additional routing involved. For the sake of the experiment, I may just connect one server and one desktop, and remove everything else from the equation- dedicated network connection between the two, no internet access, nothing else.
What other specs need to be clarified?

The project is to conduct a statistically reproducible experiment, and turn it into an analysis. Some people in the class chose plant growth and measurement, others chose cooking. I decided to stick to computers, but don't have the knowledge to program the functions myself. (Job and college don't leave me enough time to figure it out on my own right now.)
 
I'd suggest keeping your testing procedure simple. A digital stopwatch and a little reading through mapping drives/folders (along with permissions) would allow you to better spend your time running tests.
 
That's a little bit limited, because it doesn't cover (a) latency or (b) transfer speed of small files. A stopwatch won't detect the difference between a 4KB and a 16KB file, because both will be done in the time it takes me to push the button. However, I will keep it in mind as a last resort.
In DOS, I may be able to use the TIME function (piped to a text file) as a rudimentary comparison, like TIME>>log.txt, FILESIZE>>log.txt, TIME>>log.txt and subtract the two times for a calculation. This may be good enough for bandwidth, but it still leaves me with latency considerations.
 
Ah... not sure how I missed the latency and bandwidth comment of the first post.

You're probably better searching for some pre-built application. Some Google searches turned up this application (among many others). The specific detail I saw on that previous link was this. That app alone might not have all that you're looking for, but at least shows one option available.


Edit: Found one more useful link.
 
Last edited:
Looking through the second link now, thanks. I'm not sure I understand what a lot of them do, but I have a couple of weeks to figure it out. :)
 
You can use ROBOCOPY, which reports time and bit rate. You can use TimeIt from the Windows Resource Kit to do more detailed timings.

Don't forget to find a way to remove the effects of network collisions, jitter, and cache from your measurements. (Or, document your measurement of those phenomena.)
 
You can use ROBOCOPY, which reports time and bit rate. You can use TimeIt from the Windows Resource Kit to do more detailed timings.

Don't forget to find a way to remove the effects of network collisions, jitter, and cache from your measurements. (Or, document your measurement of those phenomena.)
Wow, I'm not too proud to admit that that's way over my head. Cache will obviously be a consideration since it'll be the same files time and again, but will the other factors still present themselves when I'm doing a one-way-at-a-time copy over a dedicated one-computer-to-another network?
 
Yes, there will be other traffic and jitter on the network even if there are only two computers on it. It's up to you to decide if it will be statistically significant or not.
 
Will either of the utilities report these obstructions as well, or will I need to find another test to measure them separately?
 
That's up to you to decide, unless you've changed your mind about having someone else do the project for you.
 
Well, as I said- the project is for Statistics, not programming/networking. So from that perspective, I'm asking for help with the setup of the experiment, not someone to conduct the experiment for me or even help design it. But as you've already highlighted some variances that I overlooked, I can agree that anything beyond this point would be crossing into the actual Stats portion of the project.

Thanks for the help, both of you! :)
 
I completely disagree. Statistics are numbers that describe something. If what the statistics describe can't can'accurately be defined, the statistics aren't useful. I think this is the first thing you'd want to learn in a course on statistics: knowing what to measure and what the measurements mean is far more important than aggregating or summarizing the measurements themselves.
 
Agreed, except that I think that for the sake of thoroughness, Round 1 would actually be record everything, then start ruling out insignificant figures. You can't determine which numbers are meaningless until you've actually evaluated their impact on the final process. So while I'm reasonably sure that jitter would be insignificant in a bandwidth calculation, I can't make the same assumption about latency until I've run a few instances where jitter was factored in as well. The converse is likely to hold true for packet collisions.
 
Back
Top