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
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**
Glad I could have been some entertainment, Thanks for clearing that up. Sorry about the stupid question, at least I know now Sew On 4/30/06, Sebastian Bork <sebi@sebi.org> wrote:> 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** > >
>> 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
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:10sfq''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.
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**
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