On 15/09/15 01:01, Digimer wrote: > On 14/09/15 10:46 AM, Noel Kuntze wrote: >> >> Hello Christine, >> >> I googled a bit and some doc[1] says that TC_PRIO_INTERACTIVE maps to value >> 6, whatever that is. >> Assuming that value of 6 is the same as the "priority value", Corosync >> traffic should go into band 0, because >> TOS values of 0x10 and 0x14 have "priority value" 6, too. The page[2] on >> lartc.org says that, too. >> >> That means that at least when pfifo_fast is used, there's no need for >> iptables rules or tc filters to prioritize Corosync traffic manually. >> >> [1] http://linux-tc-notes.sourceforge.net/tc/doc/priority.txt >> [2] http://lartc.org/howto/lartc.qdisc.classless.html#AEN658 >
Thank you for checking this. I remember I did that code years ago for cman in rhel4 but have since forgotten the exact detail of what was going on. > So what's the final verdict on this? I followed your back and forth, and > it sounds like corosync uses 0, so nothing else is to be done? > > I'm also fully willing to admit that something else triggered the fault > detection. It happened during a long live migration (actually, several > servers back to back), so I *assumed* that was the cause. Given it was a > cut-over weekend though, I made a mental note and went back to work. Bad > choice... I should have snagged the logs for later investigation. =/ There are other networking scheduling algorithms, I think. Though I haven't looked at them in detail for years now. Maybe we should investigate and see if there is one that might be more appropriate? Chrissie _______________________________________________ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
