Hi,
it is a bit more than running a "one off" test..
Take the example of networking sites together - where audio flows
between them on udp packets,
and it was all good on installation - everything was good..
The customer rings up a month later, and is quite unhappy about
voice quality. Seems that UDP packets have gone missing..
After some investigation, turns out the customer has just switched to a
wireless service provider, who promised 54 Mbits/sec.
The customer does not mention this in his problem report - he thought it
was not relevant. So you look at the performance
graphs - which contain the loss rate (measured every minute) on the
links. Turns out that during the day - there is a high
loss rate - and it is all good at night. Having a running record of the
last 2 days of performance is helpful, as it means there is no delay
in telling the customer what is wrong - they don't have to wait while
you set up "mrtg" or equivalent..
When you get to tell the customer that he "failed", by installing the
wireless link, and that the packet loss is all his fault,
you have just experienced one of those very rare (and very nice) moments
in IT support..
In other words, 'one of tests' on bandwidth are of indication value only
- they are part of the picture.
it is helpful to implement some kind of stun test to test that the
relevant ports of the firewall/NAT etc are open.
>>Recommendation, use a tool that tests what you're flying. UDP packets.
yes - build that tool into your program - so the results are graphed.
I was hoping for some comments (in this thread) that might suggest other
things to measure and record.
So far, I have (cpu run queue length, cpu busy, response time between
browser and server, loss on links,
count of instances of every class, threads in the program) - I
think the list is covered.
Cheers,
Derek.
On 01/02/12 12:30, John Carter wrote:
Hmm. Some sods think... aha, udp, no one cares if we drop those,
better never than late and all that... so those sometimes get dropped
preferentially.
Some sods configure routers to hate ICMP, so ping is no longer very
reliable.
Recommendation, use a tool that tests what you're flying. UDP packets.
ie. Use tracepath
On Wed, Jan 18, 2012 at 2:37 PM, Derek Smithies
<[email protected] <mailto:[email protected]>> wrote:
Hi,
I have a linux box in a data centre, somewhere in the US..
This box runs a program which talks voip (lots of udp packets, a
few tcp packets)
with other boxes.
Being performance conscious, things like packet loss are
monitored, and there are packets being dropped.
An identical box, with the same settings for firewall etc, with
the same program, but in a totally different place,
reports no loss.
ok. run
ping -q -A -c 200 4.2.2.2
and the loss rate may be anything from 0 to 8% (on some runs it is
perfect, on others it is bad)
the data centre network operators claim it is not them, and that
their centre is fine. I don't know if the
data centre is running traffic shapers, bandwidth throttling, or
what..
iptables -L reports no drop rules.
Conclusion: it is not the firewall settings that is dropping packets.
Don't think it is hardware, but I did remember hearing something
about full & half duplex
However, one can use the command:
>>mii-tool eth0
eth0: 10 Mbit, full duplex, link ok
(ethtool appears to be the newer tool, but ethtool fails on operations
I found a tool on the network called shaperprobe, that
(apparently) works out if there is any traffic shaping going on.
This tool reports no shaping..
Is it the hardware on the box? I don't think so. - it is a new
box. Is it my software - no - ping reports similar answers.
is the box heavily loaded - no. the load average is 0.00
Question:
is there a software tool to analyse network traffic and work out
where the packets are being lost (tcptrace?) and
say why they are being lost?
--
Derek J Smithies Ph.D.
Christchurch,
New Zealand
-- "How did you make it work??" "the usual, got everything right"
_______________________________________________
Linux-users mailing list
[email protected]
http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
