let's see if I can help you out with your questions.
The rates on the imq0 and imq1 should be the ones provided by your ISP line minus an estimated 20% overhead. You this even though your physical connection (I'm guessing ethernet (100Mbit) or usb2 (450Mbit)) to the internet can probably output far greater. This is done so that you don't overqueue the modem in any instance.
That would mean:
tc qdisc add dev imq0 root handle 1:0 htb default 30
tc class add dev imq0 parent 1:0 classid 1:1 htb rate 19200kbit burst 10k
tc qdisc add dev imq1 root handle 1:0 htb default 30
tc class add dev imq1 parent 1:0 classid 1:1 htb rate 6400kbit burst 10k
to begin with.
Now with the classes you have to really think about what you want to prioritize and how. Remember that in HTB the "rate" is the guaranteed bandwidth that you will assign the traffic in that class even when the link is full. This would mean that the sum of all rates in each class should equal or less than the rate of the parent class.
If you miscalculate that, you will start obtaining inconsistent results, especially if you push to saturate your link.
The problems with your stable ping are common and unfortunately not entirely fixable. The thing is that P2P in general creates tons of connections which will make the class in which you put it into ask for a lot more transmission time than the other classes.
The best example I can come up with is a bittorrent while playing an online game. A standard bittorrent will at least create 10 connections while games in general need only one. Then there is also the issue that the 10 Bittorrent connections are TCP based so they actually have a state, whereas a game is usually UDP. This will mean that the 10 Bittorrent connections will constantly ask to transmit (and will heavily do so) whereas the game, even on highest priority will have to take away the transmission token from the bittorrent class (which takes time) transmit and then the tranmission token will probably pass back to the bittorrent class until someone else with a higher priority comes along to take away the transmission token.
If you have the bittorrent traffic in with the game, the problem then comes again in the SFQ or PFIFO where basically the excess P2P traffic will ask more transmission time than the game.
That said, the only way to fix the stable ping problem is to do what you have done. You could also change the queuing discipline in a particular class to a PFIFO instead of SFQ and divide the bittorrent class into the lowest priority class and with a low rate, while maintaining the ceil at the connection speed. You should also put all non-prioritized traffic into that same class, say the HTB default 30 in your example.
The HTB has been fully tested and works extremely well. The problem you seem to be having is the classification of the packets. Also I noticed that by default things go to the HTB 20 class, so I think it should go in the 30.
Depending on how you prioritize the traffic if ICMP is on the lowest class and you have bittorrent on a higher class, then the ICMP should have a biggish delay, like you said.
I hope this helps.