[LARTC] icmp latency question

[LARTC] icmp latency question

[the sew]

Hi,

Our company's main line is quite busy the whole day and my shaping is
working perfect, however even if I give icmp priority the pings still
jump around quite a bit.

We do have a backup line which hardly get used only if the main line
drops. I've set ip rule to route all icmp through that and now the
pings are perfect.

Will this make a difference for the game players etc, with this low
ping? or does the lagg on the game get effected by the throughput?

Thanks

Sew
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] icmp latency question

[Sebastian Bork]

the sew wrote:
> Our company's main line is quite busy the whole day and my shaping is
> working perfect, however even if I give icmp priority the pings still
> jump around quite a bit.
> 
> We do have a backup line which hardly get used only if the main line
> drops. I've set ip rule to route all icmp through that and now the
> pings are perfect.
> 
> Will this make a difference for the game players etc, with this low
> ping? or does the lagg on the game get effected by the throughput?

Sorry, I don't want to offend you, but your mail has been the cause for
the first good laugh of the day.

To get good results for online gaming, the roundtrip time of the packets
to and from the game servers needs to be good, and it should be fairly
constant, without sudden increases in the "lag time". To test this RTT,
most people use ping, as ICMP echo requests/replies are the perfect tool
for measuring this.

What you did was not to improve the RTT of the packets in the data
stream to and from game servers, but to falsify the results of RTT tests
done with ICMP. Now your measurements look perfect, without any change
to the real lag your gamers will experience.

You should not take "you need a good ping for gaming" literally. Really,
games do *not* use ICMP to connect to the servers. ;o)

I begin to doubt the wisdom of including rules for ICMP priorisation in
the many tc examples out there. Really, it does not make sense to send
out the packets used to test the average and best/worst case RTT of a
network as fast as the link allows at the cost of letting other traffic
wait, because then the result of a ping will have nothing to do with
what the sender of that ping wanted to know.

Just my € 0.02,
		Sebi

-- 
Sebastian Bork <sebi@sebi.org>         ("`-''-/").___..--''"`-._
                                        `6_ 6  )   `-.  (     ).`-.__.`)
Untere Karlsstr. 16, 34117 Kassel       (_Y_.)'  ._   )  `._ `. ``-..-`
 Cellular phone: +49 163 6780023      _..`--'_..-_/  /--'_.' ,'
_____________________________________(il),-''  (li),'  ((!.-'   **meow**

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] icmp latency question

[Andrew Beverley]

 >> Our company's main line is quite busy the whole day and my shaping is
 >> working perfect, however even if I give icmp priority the pings still
 >> jump around quite a bit.

 > Sorry, I don't want to offend you, but your mail has been the cause for
 > the first good laugh of the day.

It may have been a stupid question, but it does raise an issue I have noticed. Even if I 
give maximum priority to SSH/ICMP, I notice that the latency does still jump around. Is 
this because I've not set up the queueing discipline very well?

For SSH I have:
tc class add dev imq0 parent 1:1 classid 1:10 htb rate 50kbit ceil 800kbit prio 1
tc qdisc add dev imq0 parent 1:10 handle 10: sfq perturb 10
tc filter add dev imq0 parent 1:0 prio 0 protocol ip handle 10 fw flowid 1:10

For other traffic I increase prio number and flowid. e.g:
tc class add dev imq0 parent 1:1 classid 1:40 htb rate 90kbit ceil 600kbit prio 4
tc qdisc add dev imq0 parent 1:40 handle 40: sfq perturb 10
tc filter add dev imq0 parent 1:0 prio 0 protocol ip handle 40 fw flowid 1:40

The parent is:
tc qdisc add dev imq0 root handle 1: htb default 40
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] icmp latency question

[Jason Boxman]

Andrew Beverley wrote:
<snip>
> For SSH I have:
> tc class add dev imq0 parent 1:1 classid 1:10 htb rate 50kbit ceil 800kbit
> prio 1
> tc qdisc add dev imq0 parent 1:10 handle 10: sfq perturb 10
> tc filter add dev imq0 parent 1:0 prio 0 protocol ip handle 10 fw flowid
> 1:10

sfq's default queue of 128 may cause you some pain.  You could try a pfifo
10 or recompile after modifying sch_sfq.c in your kernel tree.  Also, using
the prio parameter with htb may not do what you expect when you exceed your
specified rate.  The htb documentation explains the effects in detail.

You could also get spikes from running over an ATM link where your specified
rate and the actual ATM link utilization will likely differ.



_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] icmp latency question

[Sebastian Bork]

Andrew Beverley wrote:
> It may have been a stupid question, but it does raise an issue I have 
> noticed. Even if I give maximum priority to SSH/ICMP, I notice that the 
> latency does still jump around. Is this because I've not set up the 
> queueing discipline very well?

Did you shorten the queue on the network interface? If there are already
some packets which the kernel dequeued to the interface, your ICMP
packet will have to wait until they have been sent. The only longer
queue should be the one in the kernel, because only there the high
priority traffic gets queued before the already waiting packets, all
hardware queues are FIFOs.

 > For SSH I have:
 > tc qdisc add dev imq0 parent 1:10 handle 10: sfq perturb 10

You should not use sfq for high priority traffic, it is only useful for 
bulk traffic - there should never be as much high priority traffic as to 
make sfq needed to stop one flow from starving another, and if you use 
it, your latency will rise.

-- 
Sebastian Bork <sebi@sebi.org>         ("`-''-/").___..--''"`-._
                                         `6_ 6  )   `-.  (     ).`-.__.`)
Untere Karlsstr. 16, 34117 Kassel       (_Y_.)'  ._   )  `._ `. ``-..-`
  Cellular phone: +49 163 6780023      _..`--'_..-_/  /--'_.' ,'
_____________________________________(il),-''  (li),'  ((!.-'   **meow**

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] icmp latency question

[Andrew Beverley]

Many thanks for the reply.

> sfq's default queue of 128 may cause you some pain.  You could try a pfifo
> 10 or recompile after modifying sch_sfq.c in your kernel tree.

I tried the above (modifying to 10) but didn't notice much difference.

> Also, using
> the prio parameter with htb may not do what you expect when you exceed your
> specified rate.  The htb documentation explains the effects in detail.

I couldn't access the website at luxik.cdi.cz/~devik/qos/htb/. Is it 
documented
elsewhere?

> You could also get spikes from running over an ATM link where your specified
> rate and the actual ATM link utilization will likely differ.

Possibly may be the case.

As suggested in the 'Practical Guide to Linux Traffic Control' I also tried
setting HTB_HYSTERESIS to zero in sch_htb.c but again didn't notice much
difference.

Anyway, this is currently the least of my worries, see my new thread!

Andy

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc