Userbase

Hoi,

Heb een python applicatie die module time.time() gebruikt om tijd tussen 2 bep events te meten.
Die Python 2.7 draait op een debian 9 x86 vm op vmware workstation 15.
Hierop wordt het correcte verschil in tijd weergegeven.

Als ik de vm move naar vmware esxi 6.7 klopt de gemeten tijd totaal niet meer.
Krijg een waarde meer dan 6000 keer groter.

Iemand enig idee waar de oorzaak kan liggen.

thx!

't Is blijkbaar een functie die "seconds since epoch" weergeeft, dus kijk eens wat de systeem datum is op beide OS'en, en welke epoch datum ieder OS gebruikt. (zie "Notable epoch dates" in deze link).

het is beide keren exact zelfde os. (1 op 1 copy)
Enige verschil is onderliggende virtualisatie en onderliggende hardware.

Ik bedoelde eigenlijk de systeem tijd in iedere 'virtual machine'. (en welke datum je krijgt bij 0 ticks)

de code berekent het tijdsverschil tussen 2 timestamps.
Of de datum/uur juist staat of niet is niet relevant voor de berekening.

Dan zoek je misschien beter of de 'tickrate' verschilt (door hardware virtualization, bijvoorbeeld), of een verschil in de berekening van floats (gezien time.time() dat type gebruikt)?

Toevallig geen time verschil dat (via NTP) heel zachtjesaan bijgewerkt wordt?

Werkt time.time() op basis van clockspeed of op basis van clock?

Teun schreef:Werkt time.time() op basis van clockspeed of op basis van clock?

Op basis van de system clock (geleverd door de kernel).

Het is volgens mij geen python probleem; als ik even google op "linux clock skew vmware" kom ik heel wat resultaten tegen. Deze lijkt me interessant.

Oorzaak gevonden.
Vmware workstation installatie had maar 1 NIC.
Vmware esxi 2 Nics.
De events die getimed worden, komen via multicast toe.
Vmware esxi pikt die multicast blijkbaar 2 keer op vanwege 2 nics.
Het verschil werd dus gemeten tussen 1 zelfde pakket dat 2 keer toe komt ipv tussen 2 verschillende pakketten.
Voorlopig nog 1 NIC aangesloten, eens kijken of het opgelost is door lacp te configureren.