dfoxfra...@gmail.com said: > Setting aside any countervailing considerations concerning dependencies and > binary footprint, yes. MAC computation lives in the real-time critical > section where speed means precision so any optimization we can get here is a > win.
Just to make sure we are all on the same wavelength... I don't think the MAC computation is a serious problem. At least not yet. It is on the critical path since we have to put the transmit time into the packet before we can compute the MAC. But nobody has complained yet, perhaps only because nobody has looked hard enough. That would be a good project: See if you can measure the offset due to crypto. Two systems with two ethernets would be a nice setup. If that isn't available, try IPv4 and IPv6 over the same link. Put crypto on one, collect data, then move the crypto to the other. Or run both without crypto to see if you can notice any difference between IPv4 and IPv6. If the time for the MAC computation does become a problem, I think we can work around it. The idea is for initialization to measure the time it takes, then run-time would adjust the transmit time in the packet to allow for the MAC computation. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
