Hello! > For netdev: I'm more and more thinking we should just avoid the problem > completely and switch to "true end2end" timestamps. This means don't > time stamp when a packet is received, but only when it is delivered > to a socket.
This will work. >From viewpoint of existing uses of timestamp by packet socket this time is not worse. The only danger is violation of casuality (when forwarded packet or reply packet gets timestamp earlier than original packet). This pathology was main reason why timestamp is recorded early, before packet is demultiplexed in netif_receive_skb(). But it is not a practical problem: delivery to packet/raw sockets is occasionally placed _before_ delivery to real protocol handlers. > handler runs. Then the problem above would completely disappear. Well, not completely. Too slow clock source remains too slow clock source. If it is so slow, that it results in "performance degradation", it just should not be used at all, even such pariah as tcpdump wants to be fast. Actually, I have a question. Why the subject is "Network performance degradation from 2.6.11.12 to 2.6.16.20"? I do not see beginning of the thread and cannot guess why clock source degraded. :-) Alexey - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
