Also, you want to be certain all NICs are configured the same whether you set
any for Full Duplex, they won't mix well with NICs that don't support duplex.
Also, inexplicably, I didn't get a good mix between Kingston 10/100 card and
others in Duplex mode(oddly, it was only apparent in RBase Dos).
I nixed the Kingstons and all was well after.. Go Figure.
Currently sticking to Intel Pro series.
----- Original Message -----
From: "Lawrence Lustig" <[EMAIL PROTECTED]>
To: "RBG7-L Mailing List" <[EMAIL PROTECTED]>
Sent: Tuesday, September 14, 2004 12:44 PM
Subject: [RBG7-L] - RE: slow computer
> > I will try your suggestion
> > with rbase.dat startup file. I also should mention that I use other
> > applications on the network like MAS90 accounting and it is not slow at
> > all.
>
> Mark, you need to take a step back and find out whether your problem is R:Base
> related or not. The easiest way to do this is to try a test copying a large
> file from the network to your local workstation and then back again. If the
> copy is very slow in either direction, you have a problem that has no
> connection to R:Base.
>
> Here's a VB script I have been using at a client recently (watch out for
> wrapping, you may have to unwrap lines):
>
> ' CopyTest.VBS: Tests network speed by copying file.
> ' Displays time to copy file down to local computer,
> ' time to copy file back up to network, and
> ' megabytes per second when copying up to network.
> ' Must be run from network directory, must have file
> ' DISKTEST.OUT in the working directory.
>
> Dim oFileSystem
> Dim oFile
> Dim iFileSize
>
> Set oFileSystem = CreateObject("Scripting.fileSystemObject")
> Set oFile = oFileSystem.GetFile("DiskTest.OUT")
> iFileSize = oFile.Size
> Set oFile = Nothing
>
> MsgBox "Network throughput test should take between " + _
> FormatNumber(iFileSize/(1024*1024), 0) + " and " + _
> FormatNumber(((iFileSize/(1024*1024)) * 100), 0) + _
> " seconds, depending on throughput."
>
> Dim tStart
> Dim tCopiedDown
> Dim tCopiedUp
>
> tStart = timer()
> oFileSystem.CopyFile "DiskTest.OUT", "C:\", TRUE
> tCopiedDown = timer()
> oFileSystem.CopyFile "C:\DiskTest.OUT", ".\", TRUE
> tCopiedUp = timer()
>
> MsgBox "Done: Down = " + FormatNumber(tCopiedDown-tStart, 2) + _
> ", Up = " + FormatNumber(tCopiedUp-tCopiedDown, 2) + CHR(10) + _
> "MB/Second = " +
> FormatNumber(iFileSize/(1024*1024*(TCopiedUp-tCopiedDown)), 4) + _
> " (should be 1.0 or higher)"
>
> WScript.Quit(0)
>
> To use this script, cut and paste it in notepad, and save the file on a
network
> folder with the name COPYTEST.VBS. In the same directory, put a large file (I
> use a 10 megabyte file). Then run COPYTEST.VBS from the command line or
> Windows Explorer.
>
> It will copy the file to your local hard disk and then back up to the network
> and report a crude throughput in megabytes per second for each direction.
>
> At my client some workstations were really slow. Using this routine I was
able
> to demonstrate that some workstations gave a throughput of 6 or 7 megabytes
per
> second and some gave .03 megabytes per second (a factor of 200 time slower!!).
> Because my test did not involve R:Base I was able to eliminate the "it's the
> database's fault" argument -- I showed that you couldn't even copy files
around
> on the network.
>
> In this case, the client was able to work around the problem by using
different
> switch ports for the machines running R:Base. I still don't know exactly what
> the problem was.
>
> Interestingly enough, there were some machines that would change from about
7mb
> to .03mb throughput by changing the switch they used. There was another class
> of machine that had a throughput of about 1mb per second no matter what port
> they were plugged in to.
>
> Anyway, I hope this VBS will be of some use to you.
> --
> Larry
>
