Я работаю над обновлениями программного обеспечения для моделирования пакетов, которое наша команда поддерживает и использует для тестирования других приложений, над которыми мы работаем.Два поля, которые хранятся в этих смоделированных пакетах, - это время Unix (секунды) и наносекунды.Это время, прошедшее в секундах и наносекундах с 1, 1, 1970 года. Мы используем c # для этого конкретного приложения и получаем истекшее время, используя объект TimeSpan как таковой.
TimeSpan ts = (DateTime.UtcNow - new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);
packet.SetTimeSeconds(Convert.ToUInt64(ts.Totalseconds));
packet.SetTimeNanoseconds(Convert.ToUInt64(1e6 * ts.Milliseconds));
Когда пакеты захваченыпри его назначении и отображении содержимого кажется, что значение секунд значительно отстает от значения наносекунд.Значение наносекунды поднимется до порогового значения, перевернется и снова начнет расти, но значение секунд требует несколько пакетов для пролонгации.Я проверил, обновляется ли значение секунд после установки в другом месте кода, но это не так.Остальные значения пакета устанавливаются после приведенного выше фрагмента, а затем пакет отправляется в пункт назначения с помощью сокета.
Я понимаю, что время для одного такта составляет 16 мс, и обновление может упасть между двумя пакетами.,Это может привести к их несогласованности на мгновение.В этом случае я бы ожидал, что они не будут соответствовать одному пакету максимум из-за частоты тиков.В моей ситуации это несоответствие происходит для 3 или 4 пакетов до обновления значения секунд при создании данных каждые 100 мс.
Важно отметить, что из-за рабочей среды я по закону не могу выложить полный исходный код онлайнтак что не спрашивай.Также я проверил всю логику после того, как время установлено в пакете, чтобы убедиться, что ничего не перезаписывается.Мой главный вопрос: если это просто проблема с DateTime.UtcNow или возможно получение точного истекшего времени с TimeSpan.Это не проблема создания или разрушения, поскольку это всего лишь симулятор, но было бы неплохо иметь точное смоделированное время в наших тестовых пакетах.
РЕДАКТИРОВАТЬ:
Для дополнительной информации проблемаЭто происходит даже тогда, когда я не использую свою структуру пакетов и не отправляю значения получателю.Я написал следующий цикл для проверки значений TimeSpan / DateTime без возможности использования другой логики.
for (int i = 0; i < 150; i++)
{
TimeSpan temp = (DateTime.UtcNow - new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);
Console.WriteLine("The seconds elapsed is: " + Convert.ToUInt64(temp.TotalSeconds) + " The nanoseconds portion: " + Convert.ToUInt64(1e6 * temp.Milliseconds);
}
Имейте в виду, что следующий цикл будет распечатывать несколько экземпляров одинаковых значений, посколькупроцессор может повторять цикл несколько раз между тактами (каждый такт занимает 16 мс).Если вы запустите цикл, вы увидите, что значение наносекунд увеличивается, как и ожидалось, до 999000000, а затем переворачивается, чтобы начать заново, когда достигается новая секунда.Когда вы увидите, что пролонгирование проверьте значение секунд, и вы заметите, что оно не обновилось.Я бы опубликовал распечатку, но моя машина с подключением к Интернету не имеет IDE.
Решение:
Как указывает принятый ниже ответ, я использовал convert.ToUInt64 для приведения значения TotalSeconds (двойной) Улонг.Это было сделано для удовлетворения наших внутренних библиотечных функций.Это приведение округляет значение секунд, в результате чего значение представляется неточным.В итоге я использовал функцию Math.Floor (double), чтобы убрать фрактальную часть секунд до приведения, и все осталось в синхронизации.Мой обновленный код указан ниже.
TimeSpan ts = (DateTime.UtcNow - новый DateTime (1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);
packet.SetTimeSeconds(Convert.ToUInt64(Math.Floor(ts.Totalseconds)));
packet.SetTimeNanoseconds(Convert.ToUInt64(1e6 * ts.Milliseconds));