Network performance testing....advice wanted

[k.jacko]

Hi all,

for ages now our network has suffered from periodical lag-outs and terminal server disconnections.
We've had a fluke test done and their is plenty of noise etc on the cat6 cabling that has flooded our building.
Quite often we get specific users complain of extreme slowness and being disconnected from the server.
So, i want to run a cat5e cable directly from their pc to one of the switches, thus bypassing the floorbox, the cat6 that runs from the floorbox to the presentation panel, which in turn goes to the switch. So i'm only dealing with the nic in the pc, the newly made cat5e cable and the switch. Then i can work backwards to see where potential problems are.

Running a server 2003 domain with xp pro workstations.

What i'm looking for is some software that will perform network benchtests between 2 points., data reading / writing / packet transfer / all that stuff really. If it can detect and report on bad transfer or errors on the line then even better.

Any macusers may be familiar with Helios LanTest. I want something similar.

Any and all help really appreciated. I have to do this over the xmas holidays

 

[raybay]

Don't know of anything good that is free.
Suggest you consider using top quality shielded plenum CAT6 cable, because noise on Cat6 is pretty rare.
Your problem is likely in the box, however, rather than in the cable. This is a time when an hour of a skilled, certified, Network tech at $85 to $140 and hour would probably pay off. He or she will have the test equipment needed.

 

[k.jacko]

Aaaa...but that's what i'm getting at.
The fluke test guys have already told us that they'd start with the simplest/cheapest method by swapping out cables by-passing certain hardware etc.
Our own network guys are pretty savvy, and we do have an OTDR somewhere in the country, so we can do it. I just want to be able to do my bit with some software tests.

 

[DelJo63]

You need to monitor:

1. packet losses
2. tcp ERRORS
3. and packet collisions

these conditions will impact the perceived performance of the network.
TCP errors are HARDWARE related!

be sure to test from a system beyond the closest router to another system under test; eg:

Point-A---router---Target-Point-B

to include issues that may be associated with that device too

 

[Nodsu]

The extremely hard to find and unknown "ping" utility?

On a proper LAN (and no firewalls), you should have zero packet loss at all payload sizes.

 

[DelJo63]

ping is almost brain dead in its usefullness here.
>fluke test guys
will have tools to test the link layer for conditions not visible by ping, tracert, or pathping

but you alread knew that too

 

[k.jacko]

lol, balls to the lot of ya....i'm confused even more now!

Whe i ran a mac studio, we used Helios Lan Test, which basically did what i am after now. It tested all sorts of read/write functions amongst others from one point to another. It wasn't that technical really, but it let me know that some nodes weren't operating at the speed i expected them to be and i managed to identify and mostly fix the problems.
As usual budget is an issue. Our network guy, who only has occasional access to the OTDR as it gets passed around the country from one site to another, reckons that the 'professionals' with the fluke tester would still have to go through a process of elimination by doing what i'm suggesting with the cat5e from node > switch. So he wants us to do that sort of thing....but try it with software testing before we call in the big boys with the fluke again.

Any of this makes sense......and is it worthwhile?

 

[Nodsu]

ping is almost brain dead in its usefullness here.

Oh please do explain how ping is braindead and useless. And do not paste some random irrelevant crap from some book you don't understand.

If you have real network problems, then they manifest themselves as packet loss or slow transmission. If you lose a ping packet, you know that you have a problem. If you do not lose any ping packets, then you do not lose any other types of packets either. If you get long ping times, then it obviously takes a long time to transfer data so you have speed issues.

 

[DelJo63]

sorry to have offended you. While ping provides some data, the windows pathping will provide the location of lost packets, not just the raw timing data.

on some systems, collision and error data is available (eg Solaris) which helps
immensely. Collisions cause retries and thus *may* indicate overloaded subnets. Errors on the other hand, are indications of hardware/wiring problems.

feel free to flame me via Private Messages anytime.

 

[Nodsu]

Please do explain how collisions happen in modern twisted pair ethernet

And seems that only flaming makes you provide useful information (like that about pathping) instead of useless and expensive advice (them FLUKE guys).

What's the point of recommending super-expensive and complicated diagnostics when the user can do the preliminary testing and fixing for free in 10 minutes?

 

[DelJo63]

Please do explain how collisions happen in modern twisted pair ethernet

Ethernet is a contention network, ie: unmoderated outbound communications.
The point of origin issues a WRITE to the media without inspecting to see if there
is traffic already present. This works well ~70% of the time and then COLLISIONS start to occur.
This results to two losses, the original traffic gets garbled and the rude interruption
output gets lost too -- forcing BOTH to retransmit at a later time.

Collisions are a way of life for Ethernet; they are controlled by subdividing the network into smaller segments.

{You're sand bagging here as you already knew the answer; you easliy could have taken a leadership role here }

And seems that only flaming makes you provide useful information (like that about pathping)
instead of useless and expensive advice (them FLUKE guys).

What's the point of recommending super-expensive and complicated diagnostics when the user can do the preliminary testing and fixing for free in 10 minutes?

the original post cited the >fluke guys< and it read as if there was a hardware analyzer
on site (or at least at the company somewhere).
These hardware analyzers are very effective in problem solving --
especially when they've already been purchased

My real point on ping was it is a sample at a point in time, not even averaged.
At least pathping will run many samples AND show where the losses are occuring.

 

[Nodsu]

Ethernet is a contention network, ie: unmoderated outbound communications.
The point of origin issues a WRITE to the media without inspecting to see if there
is traffic already present. This works well ~70% of the time and then COLLISIONS start to occur.
This results to two losses, the original traffic gets garbled and the rude interruption
output gets lost too -- forcing BOTH to retransmit at a later time.

Collisions are a way of life for Ethernet; they are controlled by subdividing the network into smaller segments.

You are still living in the 20th century.. Please. http://www.cisco.com/univercd/cc/td/doc/cisintwk/itg_v1/tr1904.htm

Full-duplex mode expects links to be point-to-point links. There are also no collisions in full-duplex mode, so CSMA/CD is not needed.