Slow connection between XP Prof.Client and SCO OS 5.0.5
Michael.Jeschak
Dear Sirs,
I've the following problem with my customer:
A Software running on SCO OS 5.0.5 connected via ISP German Telekom
over ADSL 1500/192 by Bintec X1200/X2300i VPN to local Win XP Prof.
Clients thru Eskers TUN Emul sometimes runs extremly slow. Means,
Screenoutput stops f.e. in the middle of the screen for 2 ... 10
seconds an then runs on.
German Telekom has checkes - all o.k.
Bintec (X1200/X2300i Routers) has checked - all o.k.
On MS Groups nothing related to find ...
On SCO Groups nothing related to find ...
On SCO-Server checkes: netstat, ifconfig, rout, ...
On Win XP Client checked 'only' config of network ...
Filetransfer between the (five) clients works fine.
Filetransfer between XP-Clients and SCO is relative slow ...
Thanks for an idea ...
With best regards ...
Michael Jeschak
Nachman Yaakov Ziskind
Have a look at this:
http://www.briansbuzz.com/w/030619/
(short answer: buy a switch.)
NYZ
--
_________________________________________
Nachman Yaakov Ziskind, EA, LLM aw...@egps.com
Attorney and Counselor-at-Law http://yankel.com
Economic Group Pension Services http://egps.com
Actuaries and Employee Benefit Consultants
Michael.Jeschak
> Michael.Jeschak wrote (on Thu, Jun 19, 2003 at 01:58:46PM -0700):
> > Slow communication between XP Prof. and SCO 5.0.5
> >
> > Dear Sirs,
> >
> > I've the following problem with my customer:
> > A Software running on SCO OS 5.0.5 connected via ISP German Telekom
> > over ADSL 1500/192 by Bintec X1200/X2300i VPN to local Win XP Prof.
> > Clients thru Eskers TUN Emul sometimes runs extremly slow. Means,
> > Screenoutput stops f.e. in the middle of the screen for 2 ... 10
> > seconds an then runs on.
> >
> > German Telekom has checkes - all o.k.
> > Bintec (X1200/X2300i Routers) has checked - all o.k.
>
> Have a look at this:
>
> http://www.briansbuzz.com/w/030619/
>
> (short answer: buy a switch.)
>
> NYZ
server-site there is a Level One Switch, 10/100, 10-Port.
Thanks
Michael Jeschak
Nachman Yaakov Ziskind
Next suggestion: install a packet sniffer, and observe what's
going on.
Jeff Liebermann
wrote:
>Michael.Jeschak wrote (on Fri, Jun 20, 2003 at 01:29:33AM -0700):
>> On the client-site there is a KTI switch 10/100, 16-Port, on
>> the server-site there is a Level One Switch, 10/100, 10-Port.
>Next suggestion: install a packet sniffer, and observe what's
>going on.
Ummm, how duz one install a packet sniffer (3rd computah) on a
switched port? Some of the more complexicated switches have options
to select a sniffer port (i.e my Cisco 1900 switch), but most do not.
One of several sniffing FAQ's:
http://www.robertgraham.com/pubs/sniffing-faq.html
The way I troubleshoot such problems is to intruduce a tie breaker.
Add a 3rd computah into the system and use it to test performance.
Usually, it's my ancient laptop, which has a known performance level.
I test for traffic to and from *BOTH* the server and the XP client.
That will determine which machine or lan segment is at fault.
The last time I did the above, it was an XP box full of spyware that
was seriously trashing performance. Sniffing would not have shown
anything other than long delays between bursts of traffic.
The time before, it was Symantec NetDetect running with a screwed up
configuration that was trying to connect to the internet for updates
via a non-existant connection. When this happened, the XP IP stack
decided to cleverly re-route ALL the traffic (includeing the stuff
that normally would go to the default route) to the non-existant
route. Eventually, it would realize it's mistake and recover. I
think this was fixed in XP SP1. Sniffing would have shown anything.
--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831.336.2558 voice http://www.LearnByDestroying.com
# je...@comix.santa-cruz.ca.us
# 831.421.6491 digital_pager je...@cruzio.com AE6KS
Nachman Yaakov Ziskind
> On 20 Jun 2003 10:56:40 -0400, Nachman Yaakov Ziskind <aw...@egps.com>
> wrote:
>
> >Michael.Jeschak wrote (on Fri, Jun 20, 2003 at 01:29:33AM -0700):
> >> On the client-site there is a KTI switch 10/100, 16-Port, on
> >> the server-site there is a Level One Switch, 10/100, 10-Port.
>
> >Next suggestion: install a packet sniffer, and observe what's
> >going on.
>
> Ummm, how duz one install a packet sniffer (3rd computah) on a
> switched port? Some of the more complexicated switches have options
> to select a sniffer port (i.e my Cisco 1900 switch), but most do not.
Ummm, like this: download Ethereal and WinPcap, and load them on the XP
box. Ok, you won't see (or maybe you will: switches can be good, bad, or ugly)
traffic on other machines, but you *will* see things as XP sees it, and isn't
that a start?
> One of several sniffing FAQ's:
> http://www.robertgraham.com/pubs/sniffing-faq.html
>
> The way I troubleshoot such problems is to intruduce a tie breaker.
> Add a 3rd computah into the system and use it to test performance.
> Usually, it's my ancient laptop, which has a known performance level.
> I test for traffic to and from *BOTH* the server and the XP client.
> That will determine which machine or lan segment is at fault.
>
> The last time I did the above, it was an XP box full of spyware that
> was seriously trashing performance. Sniffing would not have shown
> anything other than long delays between bursts of traffic.
But wouldn't it narrow things down, to know, e.g., that at the physical layer
something|nothing abnormal is going on? You have to start somewhere.
> The time before, it was Symantec NetDetect running with a screwed up
> configuration that was trying to connect to the internet for updates
> via a non-existant connection. When this happened, the XP IP stack
> decided to cleverly re-route ALL the traffic (includeing the stuff
> that normally would go to the default route) to the non-existant
> route. Eventually, it would realize it's mistake and recover. I
> think this was fixed in XP SP1. Sniffing would have shown anything.
--
Mike Brown
Try pinging from the XP to SCO with large packet sizes, say 1430
to 1480 bytes to see if there is a problem with large packets.
If you see an issue with speed or dropped packets, reduce the MTU
on the SCO system.
ifconfig net0 mtu 1430
You can check the current net number and settings with
ifconfig -a
Mike
--
Michael Brown
The Kingsway Group
Michael.Jeschak
> "Michael.Jeschak" wrote:
---cut ------
>
> Try pinging from the XP to SCO with large packet sizes, say 1430
> to 1480 bytes to see if there is a problem with large packets.
> If you see an issue with speed or dropped packets, reduce the MTU
> on the SCO system.
>
> ifconfig net0 mtu 1430
>
> You can check the current net number and settings with
>
> ifconfig -a
>
> Mike
Thanks! Will try ...
Michael.Jeschak
... hmmm ...
thanks to both ... Nachman Yaakov Ziskind and Jeff Liebermann ...
but on client side there are 5 machines having all the same problem.
The PC's are not really work around the clock. Sometimes 1/2 hour
nothing happens and than a bill is written, sometimes the screen
freeze - and sometimes not. I've worked on 2 of 5 maschines with IE/NS
on internet - nothing happens ... I copied files between the (local)
PC's nothing happens.
On server (central-) side running 12-15 workstations with 2 sessions
on 'PizzaBox' and 2 PC's with TUN Emul and Win2K, like the
filiale-side, but there nothing happens. The server IP-range is
192.168.100.x, the outside clients 192.168.10.x. XP has SP 1
installed, no other software is running as TUN-Emul, no
internet-access is done. KTI technican means the bandwith may be to
narrow - but allgeier, the software-vendor (http://www.allgeier.com/),
and german telecom means it's enough for a plain terminal application
(no X-Windows). I suggest it may be the SCO, which is supported by the
software-vendor ... but have now get a small idea where to look ... At
first it seems to be importend what happens copying between XP and
SCO, between W2K and SCO and between W2K and XP ...
I think we would hear later ... thanks ... Michael Jeschak
Jeff Liebermann
(Michael.Jeschak) wrote:
>but on client side there are 5 machines having all the same problem.
>The PC's are not really work around the clock. Sometimes 1/2 hour
>nothing happens and than a bill is written, sometimes the screen
>freeze - and sometimes not. I've worked on 2 of 5 maschines with IE/NS
>on internet - nothing happens ... I copied files between the (local)
>PC's nothing happens.
What do you mean by "nothing happens"? Duz that mean that you cannot
copy files between machines? Or, duz that mean that the Windoze
machine talk to each other normally.
Do *NOT* use the application the is causing a "screen freeze" for
testing. Use the tools the SCO and MS supplied with their systems.
Use ftp for copying files between systems. Both will give you
performance transfer speeds. The idea is to simpilfy the testing to
the minimum necessary hardware and software. What are the ftp speeds
in BOTH directions between server and workstations?
>On server (central-) side running 12-15 workstations with 2 sessions
>on 'PizzaBox' and 2 PC's with TUN Emul and Win2K, like the
>filiale-side, but there nothing happens.
What does "nothing happens" mean? Frozen or normal? Fast or slow?
Working or not working?
>The server IP-range is
>192.168.100.x, the outside clients 192.168.10.x. XP has SP 1
>installed, no other software is running as TUN-Emul, no
>internet-access is done. KTI technican means the bandwith may be to
>narrow - but allgeier, the software-vendor (http://www.allgeier.com/),
>and german telecom means it's enough for a plain terminal application
>(no X-Windows). I suggest it may be the SCO, which is supported by the
>software-vendor ...
The first step to solving a problem is *NOT* to randomly assign the
blame. Try to remain objective and test the various components
independently.
>but have now get a small idea where to look ... At
>first it seems to be importend what happens copying between XP and
>SCO, between W2K and SCO and between W2K and XP ...
>
>I think we would hear later ... thanks ... Michael Jeschak
--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)336-2558 home
http://www.LearnByDestroying.com AE6KS
je...@comix.santa-cruz.ca.us je...@cruzio.com
Jeff Liebermann
<je...@comix.santa-cruz.ca.us> wrote:
>On 23 Jun 2003 14:56:16 -0700, Michael...@gmx.de
>(Michael.Jeschak) wrote:
>
>>but on client side there are 5 machines having all the same problem.
>>The PC's are not really work around the clock. Sometimes 1/2 hour
>>nothing happens and than a bill is written, sometimes the screen
>>freeze - and sometimes not. I've worked on 2 of 5 maschines with IE/NS
>>on internet - nothing happens ... I copied files between the (local)
>>PC's nothing happens.
Actually, this is sounding familiar. Today, I repaired a network with
similar problems. Ping would work just fine to anywhere. However,
file transfers were slow, jerky, erratic, and would time out. Web
pages would start to appear, stall, and then finish perhaps 1-5
minutes later.
By bypassing various parts of the network (with a 500ft roll of CAT5),
I eventually isolated it to one segment. I found a wiring error in
the EIA-568B CAT5 cable. The pins 3 and 6 (GRN/WHT, WHT/GRN) were
reversed. The cable was between two Linksys switches on different
floors. The lights on the switch ports looked normal. So did my
laptop when I used it to replace one switch. Rewiring the connector
fixed the problem.
You might wanna inspect the wiring.
Bill Vermillion
Jeff Liebermann <je...@comix.santa-cruz.ca.us> wrote:
>On Mon, 23 Jun 2003 18:04:29 -0700, Jeff Liebermann
><je...@comix.santa-cruz.ca.us> wrote:
>
>>On 23 Jun 2003 14:56:16 -0700, Michael...@gmx.de
>>(Michael.Jeschak) wrote:
>>>but on client side there are 5 machines having all the same problem.
>>>The PC's are not really work around the clock. Sometimes 1/2 hour
>>>nothing happens and than a bill is written, sometimes the screen
>>>freeze - and sometimes not. I've worked on 2 of 5 maschines with IE/NS
>>>on internet - nothing happens ... I copied files between the (local)
>>>PC's nothing happens.
>Actually, this is sounding familiar. Today, I repaired a network with
>similar problems. Ping would work just fine to anywhere. However,
>file transfers were slow, jerky, erratic, and would time out. Web
>pages would start to appear, stall, and then finish perhaps 1-5
>minutes later.
When ping along works you might try increasing the ping packet size
at that will start showing up the other problems without having to
invoke the other failing protocols.
Bill
--
Bill Vermillion - bv @ wjv . com
Jeff Liebermann
wrote:
I tried larger packet sizes for ping thinking I had something in the
system that was breaking MTU discovery and negotiation. That caused
ping to start losing packets. The larger the packet, the more lost
packets.
What had my mystified was why ftp packets, should suddenly decide to
appear 1-5 minutes later. That mean't that the packets were being
received (up to the max receive window size), but the replies were
being lost. That would also explain why larger ping packets (up to
the max receive window size) would lose more packets than the more
numerous small packets. Asymmetrical path issues on LAN's are common,
but usually there's a complete failure in one direction, not a partial
one. I never realized that one can transpose two of the data wires
and still have a semi-functional ethernet connection.
I must confess that I didn't figure it out until after I discovered
the connector wiring error. I'm not sure if it was my wiring error or
someone elses as there were many cooks in this soup bowl.
Anyway, the symptoms sound similar to the original problem (slow,
jerky, erratic, time outs, etc).