Link to home
Start Free TrialLog in
Avatar of ElmerFud
ElmerFud

asked on

Network Speed

I've noticed something and it really has me wondering some things.

I administer a 10BaseT Network.  Just straight 10BaseT, not 100BaseT.  I'm running Windows NT Server 5.0 SP5 and Windows 95B (ORS2).  I run only NetBIOS over TCP/IP.

I setup computers for the company.  I make my own rescue CDs.  I use a nameless software to make images of harddrives then I burn them to CD.

The software I use is a DOS program.  I'm running this software in a DOS window on Windows 95.  This is very important.  IT'S NOT DOS MODE.  ITS A DOS WINDOW.  WINDOWS 95 SITS IN THE BACKGROUND WHILE THE IMAGE IS MADE.

While doing this, I brought up perfmon (the performace monitor that comes with Windows NT).  I checked out the speed at which the image was being put on the sever.  I was blown away.  700000 bytes per second!!!!  I have used perfmon several times.  Using the windows 95 copy functions that are built into the shell, I've reached speeds of only 300000 to 400000 bytes per second.

I can copy the same exact image file to the server via Windows 95 copy commands at only 300000 bytes per second.  If I were using the software in DOS mode, I could see why, but I'm not.  If a program running in a dos window under Windows 95 can copy information at 700,000 bytes per second, there is no reason Windows 95 can't copy information at 700000 bytes per second as well.

I looking for a very educated explanation of why this happens.  
Anyone that offers a tweak that can make Windows 95 copy at 700000 bytes per second will get double the points.

I WILL EXCEPT ONLY COMMENTS AS ANSWERS!
Avatar of ElmerFud
ElmerFud

ASKER

Intersting piece of information:

Just as a test, I setup an FTP server on my NT machine and did an FTP transfer over my LAN.  Look at the results:

Transferred: cc32e45.exe 14,961,296 bytes in 00:33 (442.75 KB/sec)

This is FTP over TCP/IP this takes NetBIOS out of the loop.  I can't get 700 KB/sec even with FTP.  The developers this software must be doing something tricky.
ASKER CERTIFIED SOLUTION
Avatar of mikecpayne
mikecpayne

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
The "nameless" copy program must be using NetBIOS over TCP right?  Because you just specify a drive letter and path as a destination right?  Some optimization comes from squeezing all of the filenames into one file - copying many small files takes longer that copying one file of the same size.  

While doing the copy open up another DOS window and try the following two commands...

netstat -n

Is the copy using port 139?

nbtstat -s

Does there seem to be less chatter during an image copy versus a file copy. (Input versus Output ratio)?
I'm doing a ghost image today.  (Ghost is the program I use.  Just didn't want to give Symantec a plug.)  I will check see what nbtstat has to say.

I will also give robocopy a shot after I make the image.

With out testing it, my gut tells me that this is the case -- copy verification.  If this is the case, then why can't I FTP at 700000 bytes per second?  I know that TCP checks for errors, but this would also be the case for ghost which is running on top of NetBIOS which runs ontop of TCP/IP.  NetBIOS/TCP/IP should be the same as FTP/TCP/IP.

At this point it looks like I will accept  mikecpayne's comment as the answer.  I will post agin with my results.
I feel silly.  I just now copied a ghost image from a '95 machine to the NT server.  I got 700 K/sec sometimes and 300K/sec others.  Out of curiousity, I added more NBT connections (connections I though might be using bandwidth).  Come to find out, I get 300K/sec when another user is using the server.  I get 700K/sec when It's the only mahcine transfering.  It was coincidence that I was using ghost when I saw the 700K/sec.

Mike did tell me about robocopy.  That's why I'm giving him the credit.  He also gave his comment first.  Thanks for the info.
Just looked at the white papers for Ghost.  There was no mention of disabling error checking.  In fact it permorms CRC checking.