Testing needed bandwidth on Windows 2000 network

Fellow Experts...

I have a legacy database that runs on a windows 2000 member server.  The database is all on the server, and the client has a terminal type window to it.  This is not like using access and SQL were some of the processing is done on the client.  This is all done on the back end.

We want to set up a laptop at an offsite location to access this database, but dial up is absolutely ludacris.  The local cable company can offer us either a 128k or 256k line.  I need to justify if either would be appropriate.

So I set up a systems monitor to monitor the "bytes total", "bytes sent", and "bytes rec'd" for the NIC of this server.  So far the avg total is around 30,000 bytes or 30K.  Did I do this properly, am I right in deciding that the 128k line should be enough for this one laptop.  Granted it does not have to have the error checking that the POTS lines would.  I know one other person who uses ISDN (both channels) and says that it is fine.

I just want to know if I'm leaving anything out.  I know there is the whole bits bytes deal where the leased line would be kilobits, not bytes...

Any help is appreciated,

Yours,
Scott
LVL 5
scottman29Asked:
Who is Participating?
 
ee_ai_constructConnect With a Mentor Commented:
Question answered by asker or dialog valuable.
Closed, 200 points refunded.
ee_ai_construct (replacement part #xm34)
Community Support Admin
0
 
EricIT ManagerCommented:
assuming the line has low latency you should be fine with that.
56k dialup with citrix works ok.   windows terminal is not quite as effeciant though.
the provider should give you a guarenteed throughput  etc...
so assuming its a good service, you should be fine... the latency on cable is usually really good compaired to dialup.
the latency is more anoying than the throughput for terminal sessions IMO
0
 
scottman29Author Commented:
Well, the resolution I've come up with has worked.  I used performance monitor (sysmon in w2k) and monitored the NIC on the server, bytes total, bytes sent, and bytes rec'd.  Then I calculated the difference between bytes to bits and took it from there.  The other resolution, is that the cable company discontinuted their old services and only offeres 384k lines instead of the 128 or 256.  So I'll have plenty of bandwith.

ESCzone, I appreciate the answer, but it really didn't help me diagnose or predict my throughput issue.

Thanks!
Scott
0
 
EricIT ManagerCommented:
I was just trying to give you a real world idea.   For example on your network you may not have near as many dropped backets or CRC errors as over the internet... making it hard to calculate straight up like that.  Also throughput takes a backseat to latency for Remote Terminal applications... atleast good ones.
0
All Courses

From novice to tech pro — start learning today.