Setup a Win95 Network with just TCP/IP?

I am wanting to try converting a Windows 95 network currently using NetBEUI as its protocol as I have been told that it will speed up the access on the 100mb network. I cannot seem to find a simple help file or anyone at the moment to give simple setps how to change over and set this up or where to look to find these sets?

I will also need to still be able to use dial up networking after this also.

You don't need all this stuff, as if you don't have connection to the internet, just remove the NetBEUI protocol, and add the tcp-ip, with a 10.0.0.x ip for any workstation (replace x with a number unique to any workstation, from 1 to 254).
But as a network administrator, I found tcp-ip really not improving speed, and sometimes (most of the times) decreasing it, unless you have a really big network with a lot of data running on wan links with routers. It is not intended for lans with one or two hubs...
Also, the microsoft tcp-ip protcol provided by windows 95 was written for dail up connections (yes guys, i know that its mtu is optimized for lan, no need to comment), but not so fast when you go to such speeds (100mbps). Also, win 95 networking is optimized for netbeui, so I don't believe you will ever be able to gain speed increase using it... Also, this will require more resources on the workstations.
My advice - don't use tcp-ip on your lan if you don't really need it for web servers or so, and if you do, still use netbeui (if you use microsoft network) for the main files transfer, but for the apps that need tcp-ip.

Well it seems that not everyone agrees with how to speed up a network under Windows 95.

The site has 13 computers with an Access 97 database being written by a programmer with the run time version. We have tried using different CPU's and Ultra DMA hard drives and even a server with a PII 233 and a fast SCSI hard drive, with very little improvement in performance. We are really at a loss as to what else we can do (if anything) to improve the time of transfer.

The client does not want a dedicated NTserver yet and changing to 1 100mbps from a 10mbps did improve a lot.

We have had the thought of using a RAM drive for the local Database that is attached to the table database, but are concerned about crashes as Access really makes a mess of a table if it open when an attached db crashes.

If your question is how to improve performace, you can ask, and there are a lot of ways you can use... But if you think that tcp-ip is faster on microsoft networks, you are WRONG. You can check, for example, if the bottleneck is the net card at the server, maybe the hub, maybe the cpu. You can check all this stuff by looking system monitor, and see if maybe the ram is 100% utilized, maybe the cpu, maybe the nic... But changing protocol to tcp-ip is NOT the answer.

You are already using the best protocol for the job Netbeui is the fastest protocol that you can get when running only a small network.
TCP/IP is a larger protocol and is not as fast as Netbeui.

(NOTE TO STEVEMILLER)
You do NOT need a DNS server to setup TCP/IP in a network it's only used for name resolution to the Internet. TCP/IP will broadcasts instead and use lmhosts and hosts files instead. however since all the computers are on a the same LAN broadcasting is the easist and cheapist solution.
See Avi_shava answer it's the right one.

I will check out the sites you suggested if we decide that that is the way to go, but if avi_shava is correct I am wasting my time. I did ask how in the original question, but I also indicated that I was trying to do this to increase speed, so even though I appreciate the answer that you gave stevemiller I will need avi_shava to answer the question to award the points to please. But thanks again...I am still coming to grips with the system used here for responses etc...

In further to Avi_shava's last comment run system moniter on the PC used to store the database and also on a couple of the Workstations. All through you have given the specs of the server PC you have not mentioned any of the system specs of the clients which could be the cause of the database running slow.

I too agree with the others that the current protocol you are using is faster than TCP/IP--

but the other experts should know that the reason the previous answer was rejected was not because the content was incorrect, but that it did not technically ANSWER the question. the question was asking for advice on how to setup a TCPIP network-- not whether or not it is faster-- get it???

Therefore, if Andy wishes to edit the question to state whether TCPIP is faster, Avi should get credit as he would answer that correctly.

I was only giving information about TCPIP networks if he is still interested in doing this task and doing so-- validly answers the question. I didn't post it as an answer, because Andy might want more info and I prefer to wait for the person to REQUEST that I post the answer. That makes the PAQ official and with valid info.

Andy, check out those links and if you need more info-- I have tons of books on the subject. The place where I work has over 40,000 employees and we use ALL of the protocols for various purposes.

I will in a few days as it is a long weekend here and will not have access for that time.

We have 32MB RAM in all the systems using the database and 32MB in the server. Most of the work still seems to be in the local work stations as we have found that some of the reports do go faster if we have a PII as a work station (that's the accountants) but most of the others are much the same speed not matter what the processor??

Thanks Steve.... As I said I am new to this type of discussion I should have been more specific that I was told that TCP/IP is the best way and so I wanted to try it out. Instead I was really after if it will speed up the transfer and if so how do I do it, but as I said I did have it in the original question.

As to gpipes comment I have mostly P133 and P166 clients and all have 32Mb of RAM and 1.2Gb or larger HDD's with the Access97 run time on each. The hub is a 100mbps switching type to minimise collisions.

I seem to have stirred up a bit of a discussion with this, but I would like to sign off soon as it is very late here in Australia...

Thanks so far I will comment back later on some of the tests suggested avi and gpipes.

I think we know what's the problem already... the amount of ram on the nt server - 32Mb!!!!!! upgrade to 64 as soon as possible. Nt works very slowly with 32mb, using a lot swap file. this cost about 60$ (here in israel), and you will benefit more than any other kind of upgrade. Belive me, using nt server with less than 64mb is MADNESS.

As you have probably found out by now, the problem probably has to do with network bandwidth problems more than any other factor. Just consider this:

Your network is 100Mbps. That is fast as far as networks go, but it still is not very fast for large data transfers. As a rule of thumb you always estimate 33% of your bandwidth is lost in overhead for managing data transfers (packet headers, handshakes, etc.) so you are now reduced to 67 Megabits per second effective data transfer. That translates to about 8.4 Megabytes per second. You will never reach that figure however since you will start to experience some collisions at 50% to 60% of network utilization. The higher your network utilization, the more collisions you are likely to have. I have read research papers that indicate under normal circumstances, the maximum throughput of Fast Ethernet is really only about 6 Megabytes per second. That is about half the speed of an EIDE hard disk.

Did you try running the application with only one client computer accessing the database (shut down all of the others)? How does it perform as you add access by additional clients?

You may find that performance is poor with even one system online. If you check the network utilization during database access from this client do still get over 70% network utilization for extended periods with only one machine online?

These are important questions to answer because they may indicate that the APPLICATION is actually the problem. Is it designed for client-server database access or are you using the network server simply to share the database among multiple users? If the database in only shared then you must transfer the ENTIRE contents of any table in a query, EVERY TIME THE QUERY IS RUN. This will result in a tremendous strain on the network even with only a few users performing queries. As far as I know, Access will not perform as a true application server. THAT MEANS THAT YOU MUST BE SHARING THE DATABASE. Oops, bummer, guaranteed slow performance!

It is true that NetBEUI is a faster protocol in a small network (very small). There are two problems with NetBEUI.

1) It cannot be routed because is contains no internetwork address scheme.

2) It sends a LOT of broadcasts in order to perform name and address resolution.

These two factors conspire to reduce the speed of NetBEUI as you add more stations to the network. That is why it is not recommended for networks over 20 or so nodes. At some point the broadcast overhead becomes prohibitive and TCP/IP actually becomes faster.

When you install a TCP/IP network under Windows NT you should install a WINS server on the NT server to reduce the broadcasts that are generated by resolving NetBIOS (computer)names. When WINS is installed you can specify that the client operates as an h-node (hybrid) rather than a b-node (broadcast) node. This will lower the number of broadcast messages generated.

As the question stated and re-stated in the discussion, the network has a Win95 server not an NT server so you current answer is not applicable, but I think I will close this discussion for now and run the tests that have been suggested.

Most we have done and not has yet been achieved. I feel that the answer is with the database server application as it grows

Windows 10 is mostly good. However the one thing that annoys me is how many clicks you have to do to dial a VPN connection. You have to go to settings from the start menu, (2 clicks), Network and Internet (1 click), Click VPN (another click) then fi…