Network slowing down

I've got a DOS Clipper application running since 1995.
Network is created by Win95-DOS (but without GUI) i.e. NET START WORKSTATION
etc..
This is with binding the NETBEUI protocol interface.
There are 5 PC's in this small network.

On 1 PC I have no other option then to bind only NETBEUI.

On another PC (the "dataserver"), NETBEUI and TCP-IP are activated, to give
access to the data to others (W2000 etc) in the network.

I tried to combine the other PC's with TCP-IP, but this results in a
dramically slowing down network performance after some time.
Seems now that the TCP-IP protocol binding is causing the slowing down
problem.

I already have the section in protocol.ini
[MS$NETBEUI]
NETBIOSRETRIES=4
NETBIOSTIMEOUT=1500

I wonder if:
- anyone has seen this before or if this is a known issue
- I can achieve a stable network combined with the TCP-IP protocol through
network settings or so.
- Is there a TCP-IP.VXD that can be used instead of the NETBEUI.VXD
somewhere ???

I read about the opportunistic locking etc, but did not change any settings
about that.

TIA

Herman

"Herman Groenewegen" <hgA@Temka.nl> wrote:

> I've got a DOS Clipper application running since 1995.
> Network is created by Win95-DOS (but without GUI) i.e. NET START WORKSTATI
ON
> etc..
> This is with binding the NETBEUI protocol interface.
> There are 5 PC's in this small network.
>
> On 1 PC I have no other option then to bind only NETBEUI.
>
> On another PC (the "dataserver"), NETBEUI and TCP-IP are activated, to giv
e
> access to the data to others (W2000 etc) in the network.
>
> I tried to combine the other PC's with TCP-IP, but this results in a
> dramically slowing down network performance after some time.
> Seems now that the TCP-IP protocol binding is causing the slowing down
> problem.

AIUI, NetBleuigh was designed for tiny, local, peer-to-peer networks,
and therefore assumes perfect connections (on a small local network,
warranted 99% of the time, and the other 1%, just change the damn
cable), as well as perfectly cooperative clients (with M$ OSes, not so
very warranted), and no slow links (again, on a small local network,
this tends to be true).
TCP/IP is much more reliable in the long term, for larger and more
heterogeneous networks, and especially for distributed networks such as
the 'net, but this does mean that it needs to spend time checking for
errors.
So yes, for a five-computer network under your total control, NetBleuigh
(and others such as IPX/SPX) is likely to be faster than TCP/IP. Just
don't complain if it all breaks down when a single link starts to
misbehave.

Richard

Richard,

Thanks for your quick reply.

consider this:
I'm not talking about slower performance, but i mean really slow..
What about a "loop" time of more then 10 seconds, before results are shown
EACH single time..

When I restart the NETBEUI only PC, it runs quick again, after some time
(few hours), it slows down dramatically again.

That's not what You ment I think, any other suggestions are really
appreciated

Herman

On Tue, 16 Mar 2004 10:16:40 +0100, "Herman Groenewegen"
<hgA@Temka.nl> wrote:

>Richard,
>
>Thanks for your quick reply.
>
>consider this:
>I'm not talking about slower performance, but i mean really slow..
>What about a "loop" time of more then 10 seconds, before results are shown
>EACH single time..
>
>When I restart the NETBEUI only PC, it runs quick again, after some time
>(few hours), it slows down dramatically again.
>

NETBEUI is a horribly broken protocol - M$ never really got it working
properly & ditched it after they discovered the internet.

>That's not what You ment I think, any other suggestions are really
>appreciated
>

OK, I'll bite ;-)

Ditch 95 & use an OS that works - Linux would seem to be a good fit.
You could simply re-use your existing hardware & have Linux up &
running in an hour.

For a fuss-free install, look at something like SME Server at:

<URL:http://www.contribs.org/>

Install that in "server only" mode & enjoy a "real" server.

Xref: kermit comp.lang.clipper:60563

"Herman Groenewegen" <hgA@Temka.nl> wrote in message
news:4056c3f7$0$41763$5fc3050@dreader2.news.tiscali.nl...
> Richard,
>
> Thanks for your quick reply.
>
> consider this:
> I'm not talking about slower performance, but i mean really slow..
> What about a "loop" time of more then 10 seconds, before results are shown
> EACH single time..
>
> When I restart the NETBEUI only PC, it runs quick again, after some time
> (few hours), it slows down dramatically again.
>
> That's not what You ment I think, any other suggestions are really
> appreciated
>


just for more info:
what is exactly slowing down: netbeui pc or tcp/ip pc?
on what way is network cabling realised? is it utp, with hub or with switch?
when encountering slowdown (after few hours) what happens when you
simply doisconnect some pc from network (just plugg out, not restart)?

"Herman Groenewegen" <hgA@Temka.nl> wrote:

> consider this:
> I'm not talking about slower performance, but i mean really slow..
> What about a "loop" time of more then 10 seconds, before results are shown
> EACH single time..

No, that doesn't sound like simple network drag.

> When I restart the NETBEUI only PC, it runs quick again, after some time
> (few hours), it slows down dramatically again.

Only on the NetBeui PC? In that case, it sounds like something on that
PC, not necessarily your program, is leaking memory or processes. If the
NetBeui PC slows down the entire network, it sounds like something on
that PC is flooding the network.

Richard

Gabor, let me explain:

This section is still on coax (don't laugh please), 2 cables connected with
1 repeater.
(There is a coax-utp converter to connect the office, but we did disconnect
it already -no improvement-.)

1 PC (acts as dataserver) Win95 has netbeui and tcp-ip, so it can be
accessed from other PC's too (in the office)

The other 4 PC's only have Win95-DOS (without GUI) with netbeui.

1 of these 4 PC's has an application that loops every 2 seconds and
reads/writes to databases (DbfNtx) on the dataserver,
on this one the slowing down is obviously monitored best-> the
application loop takes longer and longer.
shutting down this PC and restart it, will result in "normal" loop
times, but after time it slows down again.

3 of these 4 PC's are use incidentically, just to read/write on the
dataserver.

Herman

"gabor salai" <gaborDOTsalai@euroherc.hr> schreef in bericht
news:c36ust$9qk$1@ls219.htnet.hr...
> "Herman Groenewegen" <hgA@Temka.nl> wrote in message
> news:4056c3f7$0$41763$5fc3050@dreader2.news.tiscali.nl...
>
> just for more info:
> what is exactly slowing down: netbeui pc or tcp/ip pc?
> on what way is network cabling realised? is it utp, with hub or with
switch?
> when encountering slowdown (after few hours) what happens when you
> simply doisconnect some pc from network (just plugg out, not restart)?

Nick,

Linux is not an option, as:
- There are typical windows-apps involved,
- I am not familiar with Linux (but interested),

You're right, M$-W95 is not the state of the art any more, but i'm trying to
get the cause after 9 years without problems.

Thanks anyway.

Herman.

Richard,

You maybe right, but...
On that (netbeui only) PC, the memory amounts are displayed with the clipper
Memory() functions,
they do not change very much and show no low memory, so I think it's not
likely a memory problem.

Only 1 PC (Win95) that stores the databases, has Netbeui and TCP-IP
installed.

Just restarting the netbeui only pc will end the problem though, you're
right about that.

Network datatransfer is not much and with the windows system monitor there
is no much network activity (stable and about 5%).

I'm about to cut parts of the network / shutting down the other PC's to see
if any improvement is shown.

Any comments are welcome.

Herman

Based on your description of what's going on, I'd be looking at your
application for uncommitted record locks that should be released when done.
Many older applications relied on Clipper's implicit record unlock when then
record pointer is moved and an implicit unlock when a DBF is closed.  In my
experience you always need to release file and record locks explicitly.
Over time, if the number of open locks is increasing, NETBUI will soon gag
trying to keep track of all of them.

The real issue is what has changed recently?  If this has been working OK
for a number of years, it would seem that something recent is causing the
problems.  My guess is that the "other" PC's - you only mentioned 4 using
NETBUI only - that connect to your "server" via TCP/IP are newer
winnt/win2k/winxp systems with different levels of service patches.



"Herman Groenewegen" <hgA@Temka.nl> wrote in message
news:4057206d$0$41760$5fc3050@dreader2.news.tiscali.nl...
> Richard,
>
> You maybe right, but...
> On that (netbeui only) PC, the memory amounts are displayed with the
clipper
> Memory() functions,
>    they do not change very much and show no low memory, so I think it's
not
> likely a memory problem.
>
> Only 1 PC (Win95) that stores the databases, has Netbeui and TCP-IP
> installed.
>
> Just restarting the netbeui only pc will end the problem though, you're
> right about that.
>
> Network datatransfer is not much and with the windows system monitor there
> is no much network activity (stable and about 5%).
>
> I'm about to cut parts of the network / shutting down the other PC's to
see
> if any improvement is shown.
>
> Any comments are welcome.
>
> Herman
>
>